On Fri Feb 01 00:02:26 2008, [email protected] 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.
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
