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

[Bob Carpenter <hatari@xxxxxxxxxx>]

Troed,

The problem is the pathname is included in the 48 characters. It is not simply the filename itself. Therefore, if you have a long pathname like Frank (/Applications/Atari_ST_Emulatoren/Hatari), you have far fewer characters left to use. While I only have one ACSI image, I can see why Frank named them as he did. One image might have Easymint, another image might be configured completely differently.

The suggestion probably will end up being to have shorter image names and move them to shorter pathnames as well.

Bob C

On Nov 25, 2016, at 4:41 PM, Troed Sångberg <troed@xxxxxxxxxxx> wrote:

From your mail I would assume it would be enough to use images with <48 char filenames. However, the image I tested is named "400MB_image_easymint_68k_ext2.img" which is a lot less than 48. However, after renaming it to "400MB.img" it indeed booted just fine.

So, as a workaround for v2.0.0 users we can just tell them to use shorter filenames. Max length still to be determined (unicode encoding related? 16 bit chars?).

/Troed

On Fri, Nov 25, 2016 at 10:34 PM, Christian Zietz <czietz@xxxxxxx> wrote:

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?)

Regards
Christian
--
Christian Zietz  -  CHZ-Soft  -  czietz@xxxxxxx
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA