Re: [hatari-devel] ASAN issues with tests

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 30.7.2022 23.29, Nicolas Pomarède wrote:
> Le 30/07/2022 à 22:13, Nicolas Pomarède a écrit :
>
> > Even with these options, the context / position in sources files is 
> > still not shown.

Ok.


> > So I get some leaks, but I can't tell where they come from.

I get lots of reports with valgrind "--leak-check=full 
--show-leak-kinds=all" options:
-------------------------------------------
==9391== LEAK SUMMARY:
==9391==    definitely lost: 0 bytes in 0 blocks
==9391==    indirectly lost: 0 bytes in 0 blocks
==9391==      possibly lost: 0 bytes in 0 blocks
==9391==    still reachable: 375,962 bytes in 3,173 blocks
==9391==         suppressed: 1,724 bytes in 2 blocks
-------------------------------------------

(Valgrind does not support ASAN interception, so ASAN needs to be 
disabled first.)

"Still reachable" means they were *not* leaked, there's still a pointer 
to these allocs.

By far largest amount comes from dynamic linker, then from X libs, but I 
noticed couple of unfreed being done directly from Hatari too:
-------------------------------------------
==9333== 2,408 bytes in 1 blocks are still reachable in loss record 
2,001 of 2,016
==9333==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==9333==    by 0xE6C1EA: DebugUI_Init.part.0 (debugui.c:1091)
==9333==    by 0x470347: Main_Init (main.c:776)
==9333==    by 0x470347: main (main.c:951)
-------------------------------------------
==9333== 71,680 bytes in 1 blocks are still reachable in loss record 
2,015 of 2,016
==9333==    at 0x483AB65: calloc (vg_replace_malloc.c:760)
==9333==    by 0x48E73D: GemDOS_ClearAllInternalDTAs (gemdos.c:385)
==9333==    by 0x4702E8: Main_Init (main.c:750)
==9333==    by 0x4702E8: main (main.c:951)
-------------------------------------------

I'll try to look at those tomorrow, and if they can be freed, you can 
check whether it has impact on your reports.


> I think I narrow down the leak to the "sound" option . for example with 
> the blitter test :
>
> ../../src/hatari --sound off  --tos none  blitemu.ttp
> -> this creates some leaks
>
>
> ../../src/hatari --sound 44100  --tos none  blitemu.ttp
> -> no leaks at exit

In my case I get in both cases:
Tracer caught signal 11: addr=0x0 pc=0x7f5c9873c0f0 sp=0x7f5c883d9d10
==7495==LeakSanitizer has encountered a fatal error.

So AddressSanitizer tries to find leaks at program end, but crashes 
instead, maybe due to memory corruption that it did not detect.


> maybe some memory is allocated by SDL for audio in all cases, but not 
> correctly free'd when "sound = off" ?

Sounds plausible.


	- Eero