<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Pascal,<br>
You confuse me.<br>
<br>
I did not "write the code to get this behaviour" - I used "catch"
to let the process live on. Which is something I'd typically do if
I had one long-lived process which were to parse a lot of XML
documents, which makes this bug even worse.<br>
I certainly did not write the code such in order to get a leaked
table.<br>
(Which is to say: yes, in this case I did - in order to
demonstrate the bug...)<br>
There is no reason to *not* destroy the table, given that its
handle is lost.<br>
<br>
I'm aware that if I didn't handle the exception any place, and let
the process die, then I wouldn't have a leak problem.<br>
However,<br>
- the table is a resource;<br>
- the library which creates it is responsible for cleaning it up;<br>
- it should do so even in the case of exceptions;<br>
- it is *quite common* to catch exceptions, especially in input
validation related error handling such as this;<br>
- the calling code *cannot* (without very ugly hacks such as using
ets:all()) destroy the table on behalf of the library.<br>
<br>
Regards,<br>
Erik<br>
<br>
On 06-06-2013 14:32, Pascal Chapier wrote:<br>
</div>
<blockquote
cite="mid:CABz5kDOQmvX_jTVe7B4K1XmUXCven=WeU59=Twxg4G_f5pvGEQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>Hi Erik,<br>
</div>
In my opinion, when you do your test you execute the
xmerl_scan:string("") inside a catch from shell, the process
which create the table - the shell - does not die, so, there
is no reason to destroy the ets table, consideringing that
you wrote the code to get this behaviour.<br>
<br>
</div>
Best regards,<br>
<br>
</div>
Pascal<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2013/6/6 Erik Søe Sørensen <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:ess@trifork.com" target="_blank">ess@trifork.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Hi there -<br>
When parsing a string, xmerl_scan creates an ets table
which it doesn't delete again in the case of exceptions.<br>
<br>
Demo:<br>
<blockquote>Erlang R16B (erts-5.10.1) [source] [64-bit]
[smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]<br>
<br>
Eshell V5.10.1 (abort with ^G)<br>
1> length(ets:all()). <br>
16<br>
2> <br>
2> catch xmerl_scan:string("").<br>
3900- fatal: expected_element_start_tag<br>
{'EXIT',<br>
{fatal,<br>
{expected_element_start_tag,<br>
{file,file_name_unknown},<br>
{line,1},<br>
{col,1}}}}<br>
3> length(ets:all()). <br>
17<br>
</blockquote>
(I just re-discovered this bug; I apologize for having
neglected to report it earlier, considering that I've
noticed it before some years ago.)<br>
<br>
From a brief inspection at the code, I think the place to
ensure table deletion would be to add a "try...after" in
scan_document. Alternatively, it could be done in
int_string/4 and int_string_decl/4, where the cleanup can
mirror the calls to initial_state0()->initial_state()
where the ets table is created.<br>
<br>
Regards,<br>
Erik Søe Sørensen<span class="HOEnZb"><font
color="#888888"><br>
<br>
<div>-- <br>
<div style="text-align:center"> <span>Mobile: + 45
26 36 17 55</span> <span> </span> <span
style="">| Skype: eriksoesorensen</span> <span> </span>
<span style="">| Twitter: @eriksoe</span> </div>
<div style="text-align:center;color:gray"> <span>Trifork
A/S | Margrethepladsen 4 | DK-8000 Aarhus
C | </span> <a moz-do-not-send="true"
href="http://www.trifork.com/" target="_blank"><span
style="text-decoration:underline;color:gray">www.trifork.com</span></a>
</div>
</div>
</font></span></div>
<br>
_______________________________________________<br>
erlang-bugs mailing list<br>
<a moz-do-not-send="true"
href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
<a moz-do-not-send="true"
href="http://erlang.org/mailman/listinfo/erlang-bugs"
target="_blank">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<div style="color: black; text-align: center;"> <span>Mobile: +
45 26 36 17 55</span> <span> </span> <span style="color:
black; ">| Skype: eriksoesorensen</span> <span> </span> <span
style="color: black; ">| Twitter: @eriksoe</span>
</div>
<div style="text-align: center; color: gray;"> <span>Trifork A/S
| Margrethepladsen 4 | DK-8000 Aarhus C | </span> <a
href="http://www.trifork.com/"><span style="text-decoration:
underline; color: gray;">www.trifork.com</span></a>
</div>
</div>
</body>
</html>