Re: [hatari-devel] Some ACSI images not working in Hatari 2.0

[Thomas Huth <th.huth@xxxxxx>]

Am Fri, 25 Nov 2016 22:34:22 +0100
schrieb Christian Zietz <czietz@xxxxxxx>:

> David Savinkoff schrieb:
> 
> > "Abort trap 6" is searchable on the internet.  
> 
> "Abort trap 6" seems to point to a bug regarding memory corruption
> etc.
> 
> Recall that Hatari crashes directly after the message "Mounting hard
> drive image ...". I see a *confirmed* buffer overflow in
> HDC_CheckAndGetSize, which a) is called directly after that message b)
> was introduced inbetween Hatari 1.9.0 and 2.0.0.
> 
> HDC_CheckAndGetSize calls ...
> 
> File_ShrinkName(shortname, filename, sizeof(shortname));
> 
> ... however, as you can easily check, File_ShrinkName will reduce long
> filenames to a maximal *string* length equal to its last parameter.
> The final \0 byte will take another byte in that buffer. So the
> 'shortname' buffer overflows for long filenames.
> 
> From the original crash report on atari-forum.com, you can see that
> indeed the filename of the HD image is longer than 48
> (=sizeof(shortname)), so this buffer overflow happens there.
> 
> Now I haven't checked how File_ShrinkName is called elsewhere, but you
> should either fix CheckAndGetSize or File_ShrinkName so that this
> buffer doesn't overflow. Maybe this will already fix the crashes on
> MacOS. (It seems that Windows and Linux are perhaps a little less
> sensitive to an overflow by one byte?)

Ack, there is a bug here. Actually, after compiling Hatari with
"--enable-debug" it triggered here, too, likely due to different GCC
optimization level. After debugging the issue for a while, I came to
the same conclusion like Christian, just before reading his mail ...
I just committed a fix, so I hope this problem should be gone now.

(Note to myself: Rewrite File_ShrinkName() one day to use the
destination buffer size as parameter, not the length of the destination
string. Everything thing else is too confusing...)

 Thomas