Ticket #1765 (reopened bug)

Opened 11 years ago

Last modified 10 years ago

Memory leak in allocate_interpreter

Reported by: nwellnhof Owned by: bluescreen
Priority: normal Milestone:
Component: core Version: trunk
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:

Description (last modified by nwellnhof) (diff)

$ valgrind --leak-check=full ./parrot --leak-test t/op/interp_2.pir
[...]
==4748== 131,364 (216 direct, 131,148 indirect) bytes in 1 blocks are definitely lost in loss record 184 of 184
==4748==    at 0x402328F: calloc (vg_replace_malloc.c:467)
==4748==    by 0x40F262B: mem_sys_allocate_zeroed (alloc_memory.c:82)
==4748==    by 0x4108184: allocate_interpreter (inter_create.c:123)
==4748==    by 0x410813A: make_interpreter (inter_create.c:91)
==4748==    by 0x416FFED: create_interp (parrotinterpreter.pmc:182)
==4748==    by 0x41708C8: Parrot_ParrotInterpreter_init (parrotinterpreter.pmc:251)
==4748==    by 0x413BCAB: Parrot_pmc_new (pmc.c:163)
==4748==    by 0x40B8F13: Parrot_new_p_sc (core_ops.c:20494)
==4748==    by 0x413E780: runops_slow_core (cores.c:646)
==4748==    by 0x413D7F9: runops_int (main.c:218)
==4748==    by 0x41098EE: runops (ops.c:126)
==4748==    by 0x4103CCA: Parrot_pcc_invoke_from_sig_object (pcc.c:323)

Attachments

tt1765.patch Download (1.3 KB) - added by bluescreen 11 years ago.
Possible patch

Change History

  Changed 11 years ago by bluescreen

  • owner set to bluescreen

Changed 11 years ago by bluescreen

Possible patch

  Changed 11 years ago by bluescreen

  • status changed from new to assigned

  Changed 11 years ago by bluescreen

after applying the patch:

==5367== LEAK SUMMARY:
==5367== definitely lost: 0 bytes in 0 blocks
==5367== indirectly lost: 0 bytes in 0 blocks
==5367== possibly lost: 464,968 bytes in 409 blocks
==5367== still reachable: 589,192 bytes in 180 blocks
==5367== suppressed: 0 bytes in 0 blocks
==5367== Reachable blocks (those to which a pointer was found) are not shown.

  Changed 11 years ago by nwellnhof

I don't see how freeing a NULL pointer could fix the memory leak. I just tested Parrot trunk without the patch and I don't see the memory leak anymore. There is another GC-related one though.

For some IRC discussion on this issue, see  http://irclog.perlgeek.de/parrot/2010-09-01#i_2773493

  Changed 11 years ago by bluescreen

I agree that freeing a null pointer doesn't give you anything. I think its the way valgrind works it just sees that you're not doing anything with a chunk of memory recently allocated - meaning not freeing it, not returning it - for the branch of (!ptr && size).

Without the patch I was able to reproduce your original report in which valgrind reported "definitely lost" blocks.

  Changed 11 years ago by bluescreen

Without the patch:

==26151== LEAK SUMMARY:
==26151== definitely lost: 112 bytes in 2 blocks
==26151== indirectly lost: 0 bytes in 0 blocks
==26151== possibly lost: 1,683,384 bytes in 1,010 blocks
==26151== still reachable: 157,448 bytes in 122 blocks
==26151== suppressed: 0 bytes in 0 blocks

  Changed 11 years ago by nwellnhof

  • status changed from assigned to closed
  • resolution set to fixed

I can't reproduce this particular leak anymore. Another one in the string GC code showed up, but that's fixed in db189b22.

follow-up: ↓ 9   Changed 11 years ago by nwellnhof

  • status changed from closed to reopened
  • resolution fixed deleted
  • description modified (diff)

The leak can be reproduced with the --leak-test option. Description updated.

in reply to: ↑ 8   Changed 10 years ago by jkeenan

Replying to nwellnhof:

The leak can be reproduced with the --leak-test option. Description updated.

Can we get an update on the status of this ticket?

Thank you very much.

kid51

Note: See TracTickets for help on using tickets.