[Gambas-user] gbx3 warning allocation(s) non freed

Tobias Boege taboege at gmail.com
Sun Jun 2 12:26:10 CEST 2019


On Sun, 02 Jun 2019, KKing wrote:
> is there any debugging options to help identify what the allocations were?
> 

No, but valgrind can give you an idea:

  $ valgrind --leak-check=full gbx3
  ...
  ==11322==
  ==11322== HEAP SUMMARY:
  ==11322==     in use at exit: 16 bytes in 1 blocks
  ==11322==   total heap usage: 338 allocs, 337 frees, 75,582 bytes allocated
  ==11322==
  ==11322== 16 bytes in 1 blocks are possibly lost in loss record 1 of 1
  ==11322==    at 0x483777F: malloc (vg_replace_malloc.c:299)
  ==11322==    by 0x129C15: my_malloc (gb_alloc_temp.h:368)
  ==11322==    by 0x13D8A0: SUBR_alloc (gbx_subr_extern.c:67)
  ==11322==    by 0x163411: EXEC_loop (gbx_exec_loop.c:510)
  ==11322==    by 0x168654: EXEC_function_loop (gbx_exec.c:910)
  ==11322==    by 0x168DA1: EXEC_function_real (gbx_exec.c:897)
  ==11322==    by 0x127529: main (gbx.c:430)
  ...

A practised eye can see that this non-freed allocation was made by the
Alloc built-in function directly from the Gambas program. Other sources
of non-freed allocations are native components which valgrind can explain
to you as well using its backtraces, or if you create circular references
in your Gambas data structures. In the last scenario, the valgrind method
gives you no insight.

I wonder if it's possible, in debug mode, to attach the complete backtrace
from Gambas land to each allocation. (Or if this has been done and I don't
know about it.)

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk


More information about the User mailing list