[erlang-bugs] xmerl_scan leaks ets table

[Patrik Nyblom]

Hi!

Definitely a bug. You should definitely be able to catch an exception 
here without leaking memory!

Could you submit a patch as you suggested, or should i put it in the 
backlog for "future processing" by us?

Cheers,
Patrik
On 06/06/2013 01:48 PM, Erik Søe Sørensen wrote:
> Hi there -
> When parsing a string, xmerl_scan creates an ets table which it 
> doesn't delete again in the case of exceptions.
>
> Demo:
>
>     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()).
>     16
>     2>
>     2> catch xmerl_scan:string("").
>     3900- fatal: expected_element_start_tag
>     {'EXIT',
>         {fatal,
>             {expected_element_start_tag,
>                 {file,file_name_unknown},
>                 {line,1},
>                 {col,1}}}}
>     3> length(ets:all()).
>     17
>
> (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.
>
> Regards,
> 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
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130607/628f0118/attachment.htm>