./parrot with no args leaks memory

[coke]

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.

[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.

[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?

[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.

[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.

[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.

[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.