Re: [hatari-devel] ASAN issues with tests

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Sun, 31 Jul 2022 01:35:32 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> On 30.7.2022 11.16, Thomas Huth wrote:
> > Am Sat, 30 Jul 2022 06:08:48 +0000
> > schrieb Thomas Huth <th.huth@xxxxxxxxx>:  
> >>> On 29.7.2022 18.26, Eero Tamminen wrote:  
> >>>> With "--vdi-planes 4", 640x200 is enough to trigger it, with 2 planes
> >>>> 640x400, and with mono, 640x736.  
> >>>
> >>> All these cause screen area to be slightly larger
> >>> than the 56 KB padding Thomas added in his SMALL_MEM workaround:
> >>> https://git.tuxfamily.org/hatari/hatari.git/commit/?id=5316b4081e9d3fa177ed14419369bc13892af4e8
> >>>
> >>> It appears that SMALL_MEM ST-RAM padding should take into account also
> >>> largest possible VDI screen size (300KB), i.e. use MAX_VDI_BYTES.  
> ...
> > Ok, I think I've got it now: The problem was that the ST program could have
> > changed the video base address again between the point in time we recorded
> > the VideoBase variable and the point in time the rendering was done in
> > screenConvert.c. So the code in screenConvert.c must not use
> > Video_GetScreenBaseAddr() but has to use the vide base address value that
> > was recorded earlier. I've committed a patch - that will hopefully fix this
> > issue.  
> 
> That seems to have fixed the (read?) heap buffer overflow with that 
> memory end.
> 
> However, I still often get ASAN segfaults at Hatari exit, if it has leak 
> checking enabled i.e. if I have not used "ASAN_OPTIONS=detect_leaks=0" 
> env var, so it seems there's some other issue too.

Maybe try 

 export ASAN_OPTIONS="fast_unwind_on_malloc=0"

.... that really helped me to get rid of some weird asan behavior in the
past already.

 Thomas