Re: [hatari-devel] ASAN issues with tests

[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.

Unfortunately one cannot use e.g. Gdb with ASAN.


	- Eero