[erlang-bugs] xmerl_scan leaks ets table
Erik Søe Sørensen
Fri Jun 7 10:33:12 CEST 2013
You confuse me.
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.
I certainly did not write the code such in order to get a leaked table.
(Which is to say: yes, in this case I did - in order to demonstrate the
There is no reason to *not* destroy the table, given that its handle is
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.
- the table is a resource;
- the library which creates it is responsible for cleaning it up;
- it should do so even in the case of exceptions;
- it is *quite common* to catch exceptions, especially in input
validation related error handling such as this;
- the calling code *cannot* (without very ugly hacks such as using
ets:all()) destroy the table on behalf of the library.
On 06-06-2013 14:32, Pascal Chapier wrote:
> Hi Erik,
> 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.
> Best regards,
> 2013/6/6 Erik Søe Sørensen < <mailto:>>
> Hi there -
> When parsing a string, xmerl_scan creates an ets table which it
> doesn't delete again in the case of exceptions.
> Erlang R16B (erts-5.10.1) [source] [64-bit] [smp:8:8]
> [async-threads:10] [hipe] [kernel-poll:false]
> Eshell V5.10.1 (abort with ^G)
> 1> length(ets:all()).
> 2> catch xmerl_scan:string("").
> 3900- fatal: expected_element_start_tag
> 3> length(ets:all()).
> (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.)
> 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.
> Erik Søe Sørensen
> Mobile: + 45 26 36 17 55 | Skype: eriksoesorensen | Twitter: @eriksoe
> Trifork A/S | Margrethepladsen 4 | DK-8000 Aarhus C |
> www.trifork.com <http://www.trifork.com/>
> erlang-bugs mailing list
Mobile: + 45 26 36 17 55 | Skype: eriksoesorensen | Twitter: @eriksoe
Trifork A/S | Margrethepladsen 4 | DK-8000 Aarhus C |
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-bugs