[perl #50448] [Memory Leak] IMCC Can Leak Lexer Data on Exception

Christoph Otto via RT parrotbug-followup at parrotcode.org
Sun Mar 22 04:38:10 UTC 2009


On Fri Feb 01 00:02:26 2008, chromatic at wgz.org wrote:
> When an exception occurs and exits Parrot, some of the memory
allocated by 
> IMCC can go unfreed.  Here's the Valgrind report for 
> t/pmc/object-meths_41.pir:
> 
> ==9158== 4 bytes in 1 blocks are still reachable in loss record 1 of 2
> ==9158==    at 0x4006765: malloc (vg_replace_malloc.c:149)
> ==9158==    by 0x43756BC: yyalloc (imclexer.c:5241)
> ==9158==    by 0x4374C9B: yyensure_buffer_stack (imclexer.c:4796)
> ==9158==    by 0x436FA7A: yylex (imclexer.c:3034)
> ==9158==    by 0x436B814: yyparse (imcparser.c:2597)
> ==9158==    by 0x4378D86: compile_to_bytecode (main.c:951)
> ==9158==    by 0x4379115: imcc_run (main.c:1051)
> ==9158==    by 0x80488EF: main (main.c:56)
> ==9158== 
> ==9158== 
> ==9158== 92 bytes in 1 blocks are still reachable in loss record 2 of 2
> ==9158==    at 0x4006765: malloc (vg_replace_malloc.c:149)
> ==9158==    by 0x43756BC: yyalloc (imclexer.c:5241)
> ==9158==    by 0x4375497: yylex_init (imclexer.c:5139)
> ==9158==    by 0x438A26C: do_yylex_init (parser_util.c:760)
> ==9158==    by 0x43786BF: imcc_initialize (main.c:740)
> ==9158==    by 0x804889F: main (main.c:48)
> ==9158== 
> ==9158== LEAK SUMMARY:
> ==9158==    definitely lost: 0 bytes in 0 blocks.
> ==9158==      possibly lost: 0 bytes in 0 blocks.
> ==9158==    still reachable: 96 bytes in 2 blocks.
> ==9158==         suppressed: 0 bytes in 0 blocks.
> 
> I'm not sure what the right solution is, but I suspect that something
isn't 
> freeing IMCC's yylex pointer at the right time.
> 
> -- c

This still appears to be an issue, although the test ("method called on
non-object (RT #50440)") has a different number (37) and imcc now leaks
6 blocks instead of 2.

Since imcc is going the way of the dodo in favor of pirc, it seems like
the best use of our resources to reject this ticket and focus on bugs in
parts of Parrot that won't be deprecated ASAP.  Rejecting.


More information about the parrot-dev mailing list