[Scummvm-tracker] [ScummVM :: Bugs] #14753: SCUMM: OSX crash with misread local Macintosh resource forks (was: SCUMM: OSX PPC crash with misread local Macintosh resource forks)
ScummVM :: Bugs
trac at scummvm.org
Fri Dec 15 23:34:54 UTC 2023
#14753: SCUMM: OSX crash with misread local Macintosh resource forks
---------------------+----------------------------
Reporter: dwatteau | Owner: (none)
Type: defect | Status: new
Priority: normal | Component: Engine: SCUMM
Version: | Resolution:
Keywords: | Game:
---------------------+----------------------------
Changes (by dwatteau):
* summary: SCUMM: OSX PPC crash with misread local Macintosh resource
forks => SCUMM: OSX crash with misread local Macintosh resource forks
Old description:
> Both an Engine-SCUMM and Port-OSX issue, I'd say...
>
> On branch-2-8 on OSX PPC. The original Indy3 and Monkey1 Macintosh
> binaries have been copied "as-is" from the HFS disks to the local HFS+
> filesystem, so the resource forks are still there. But, strangely,
> upgrading from ScummVM 2.7.1 to ScummVM 2.8.0pre, it looks like the
> resource fork is not properly read by ScummVM on OSX PPC anymore (it does
> work on modern macOS).
>
> The original Macintosh releases of Monkey1 and Indy3 now trigger crashes
> on this port, which didn't happen on 2.7.1. 2.8.0 now makes use of the
> original Macintosh binaries (for original GUI and improved sound), but
> (AFAICS) the engine doesn't check for the proper format of those
> resources, so if invalid content is read, the engine crashes.
>
> GDB logs below.
>
> Another way of reproducing the crash on a different system is to emulate
> a bad extraction of the resource fork (such as a blind `cp` call from
> Linux reading the HFS disk), which typically gives you zero-byte files:
>
> {{{
> $ echo -n > "/path/to/INDY3-MAC/Indy"
> $ echo -n > "/path/to/MONKEY1-MAC/Monkey Island"
> }}}
>
> Of course, users should follow our guide about preserving the resource
> forks, but the crash is probably "not nice" (we could maybe at least
> check for a 0-byte file?). Moreover, on OSX PPC, reading the local
> resource fork used to work (without any need to macbinary-encode it).
New description:
Both an Engine-SCUMM and Port-OSX issue, I'd say...
On branch-2-8 on OSX PPC. The original Indy3 and Monkey1 Macintosh
binaries have been copied "as-is" from the HFS disks to the local HFS+
filesystem, so the resource forks are still there. But, strangely,
upgrading from ScummVM 2.7.1 to ScummVM 2.8.0pre, it looks like the
resource fork is not properly read by ScummVM on OSX anymore.
The original Macintosh releases of Monkey1 and Indy3 now trigger crashes
on this port, which didn't happen on 2.7.1. 2.8.0 now makes use of the
original Macintosh binaries (for original GUI and improved sound), but
(AFAICS) the engine doesn't check for the proper format of those
resources, so if invalid content is read, the engine crashes.
GDB logs below.
Another way of reproducing the crash on a different system is to emulate a
bad extraction of the resource fork (such as a blind `cp` call from Linux
reading the HFS disk), which typically gives you zero-byte files:
{{{
$ echo -n > "/path/to/INDY3-MAC/Indy"
$ echo -n > "/path/to/MONKEY1-MAC/Monkey Island"
}}}
Of course, users should follow our guide about preserving the resource
forks, but the crash is probably "not nice" (we could maybe at least check
for a 0-byte file?). Moreover, on OSX, reading the local resource fork
used to work (without any need to macbinary-encode it).
--
Comment:
Actually, the crash when reading an original resource fork (which is not
macbinary-encoded, but just copied as-is to the local HFS+/APFS volume) is
there on modern macOS, too.
--
Ticket URL: <https://bugs.scummvm.org/ticket/14753#comment:2>
ScummVM :: Bugs <https://bugs.scummvm.org>
ScummVM
More information about the Scummvm-tracker
mailing list