[Scummvm-tracker] [ScummVM :: Bugs] #14753: SCUMM: OSX PPC crash when loading Macintosh resource forks

ScummVM :: Bugs trac at scummvm.org
Fri Dec 15 22:28:35 UTC 2023


#14753: SCUMM: OSX PPC crash when loading Macintosh resource forks
---------------------+-----------------------
Reporter:  dwatteau  |      Owner:  (none)
    Type:  defect    |     Status:  new
Priority:  normal    |  Component:  --Unset--
 Version:            |   Keywords:
    Game:            |
---------------------+-----------------------
 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).
-- 
Ticket URL: <https://bugs.scummvm.org/ticket/14753>
ScummVM :: Bugs <https://bugs.scummvm.org>
ScummVM


More information about the Scummvm-tracker mailing list