Ticket #35 (closed bug: fixed)

Opened 6 years ago

Last modified 5 years ago

./parrot with no args leaks memory

Reported by: coke Owned by:
Priority: minor Milestone:
Component: none Version: trunk
Severity: low Keywords: leak memory
Cc: Language:
Patch status: Platform:

Description (last modified by coke) (diff)

Revision: 33777

run the newly added tools/dev/vgp with no arguments, which runs:

valgrind --suppressions=tools/dev/parrot.supp --num-callers=500 --leak-check=full --leak-resolution=high --show-reachable=yes ./parrot --leak-test

This results in the expected parrot usage message, and >20K lines of valgrind output, ending with:

==23917== LEAK SUMMARY:
==23917==    definitely lost: 0 bytes in 0 blocks.
==23917==      possibly lost: 0 bytes in 0 blocks.
==23917==    still reachable: 947,176 bytes in 1,952 blocks.
==23917==         suppressed: 0 bytes in 0 blocks.

Change History

Changed 6 years ago by coke

  • description modified (diff)

Changed 6 years ago by coke

Slight improvement at r38859.

==25391== LEAK SUMMARY:
==25391==    definitely lost: 0 bytes in 0 blocks.
==25391==      possibly lost: 0 bytes in 0 blocks.
==25391==    still reachable: 817,080 bytes in 2,430 blocks.
==25391==         suppressed: 0 bytes in 0 blocks.

Changed 5 years ago by whiteknight

So can we get confirmation that this is still an issue after all the leak-plugging that has gone on in the past month?

The leak reports presented don't look to me like a problem at all. Parrot purposefully does not explicitly free all it's internal structures at exit time, there is a command-line option somewhere to change that setting if you want (I have to look it up).

With that information in mind, and the fact that 0 bytes are "definitely lost" or "possibly lost", can we close this ticket?

Changed 5 years ago by coke

tools/dev/vgp runs parrot with --leak-test, the option that you're referring to, so any thing that is still reachable at this point is an issue.

However, if we assume that resources not released when we're generating the usage message are ignorable, and instead only want to check the smallest PIR program we can run, we can try with the PIR:

.sub n
noop
.end

tools/dev/vgp reports:

==13509== 8 bytes in 1 blocks are definitely lost in loss record 1 of 1
==13509==    at 0x402601E: malloc (vg_replace_malloc.c:207)
==13509==    by 0x4EA608F: strdup (strdup.c:43)
==13509==    by 0x432A015: compile_to_bytecode (main.c:958)
==13509==    by 0x432B380: imcc_run (main.c:1067)
==13509==    by 0x8048977: main (main.c:60)
==13509==
==13509== LEAK SUMMARY:
==13509==    definitely lost: 8 bytes in 1 blocks.
==13509==      possibly lost: 0 bytes in 0 blocks.
==13509==    still reachable: 0 bytes in 0 blocks.
==13509==         suppressed: 0 bytes in 0 blocks.

This with r39769.

Changed 5 years ago by NotFound

I reviewed imcc state->file usages, and replaced some strdup with str_dup and do some other changes in r39772. That should fix this leak.

Changed 5 years ago by coke

Verified that the new test case here leaks no memory in r39772; the original case does, but if we agree that's not worth fixing, this ticket can be closed.

Changed 5 years ago by NotFound

I agree is not worth fixing at this point. When parrot main gets freed from imcc_main we'll be able to do better tests and rethink it.

Changed 5 years ago by coke

  • status changed from new to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.