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

[Benoît Minisini]

Le 02/06/2019 à 12:26, Tobias Boege a écrit :
> 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 are debugging preprocessor constants, that, if set and Gambas 
recompiled, associates a auto-increment integer identifier to each id, 
and gives you the id of the non-free allocation at the end of the 
program. And for each allocation/reallocation/deallocation, it prints 
the id and the function that generates it. But not the backtrace, I have 
to look how to print the backtrace, I never did that.

Regards,

-- 
Benoît Minisini