Re: [hatari-devel] Valgrind reported unfreed allocs at exit

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

HI,

On 1.8.2022 21.35, Eero Tamminen wrote:
> On 31.7.2022 2.02, Eero Tamminen wrote:
> > 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 have fixes to these, but I'll wait until you've released v2.4.1 as 
> GEMDOS HD one will need more testing to make sure it does not break 
> anything.

I've been running for a while with these fixes,
and release was done, so I pushed them.


	- Eero

PS. Everything else Valgrind reports:
==6151== LEAK SUMMARY:
==6151==    definitely lost: 153 bytes in 2 blocks
==6151==    indirectly lost: 0 bytes in 0 blocks
==6151==      possibly lost: 63,044 bytes in 1,930 blocks
==6151==    still reachable: 377,355 bytes in 3,295 blocks
==6151==         suppressed: 1,724 bytes in 2 blocks

Comes from portmidi initialization or ALSA libs called by it, and is 
outside of Hatari responsibility asHatari already calls pm_Close() on 
exit and there's no other uninit function in portmidi (header).