Menu
▾
▴
#4406 SAM: crash at the end of credits sequence
closed-fixed
9
2009-07-29
2009-07-13
No
Sam & Max crashes at the end of the credits sequence (when the game really starts). This is the french macintosh CD version.
I get the debugger with the following error: ERROR: (7:66:0x17): Cannot read resource!
This looked a lot like a corrupted data file, therefore I recopied the file twice from the original CD with the same result. Also the games works fine with ScummVM 0.13.1 with the same data file and the same settings.
Discussion
I forgot to say that I am using version 1.0.0svn42398 (from July 12) on MacOS X 10.4 (intel).
Also I just started the game with 0.13.1 (again) and saved right at the beginning (after the credit sequence). If I load that save game in 1.0.0svn I can then play the game.
It would be nice if you could attach both saves to this tracker item.
I think the cause for this is that SCUMM seems still to use "ioFailed". For a ReadStream we changed the implementation for that from "return err();" in 0.13.0 to "return (eos() || err());" in current trunk. I guess this resource it's trying to load is directly the last resource, resulting in an eos being set, thus making SCUMM think it could not read the resource properly.
Actually I have only one save (made with ScummVM 0.13.1) just after the crash occurs. I don't have a save before the crash because it occurs right at the beginning. I start the game in ScummVM, press Esc three times, and it crashes (it also crashes if I don't press Esc and looks at the intro sequence and credits).
I also just tried to use extract_scumm_mac which works fine and I get five files. If I point ScummVM 1.0.0svn to these files it doesn't crash. Therefore the problem seems to occur only when playing with the original "Sam & Max Data" file.
Yeah sorry that was my fault, I thought of the credits at the end of the game, I must have missed the "(when the game really starts)" :-).
My English Mac version crashes right at the start, after loading Room resource 94, but appears to work in 0.13.1. As Lordhoto says, it seems to think that eos() means an error occurred, which seems odd to me because the read() function claims it read as much data as it asked for.
I haven't played through the game in 0.13.1, so of course I might have messed up in copying the files from the CD. My "Sam & Max Data" file is 199,195,304 bytes, and its MD5 sum is e84d3a41b3015de79344f2c507639eed.
The problem appears to have been introduced in r40725: "COMMON: Removed Stream::ioFailed() and clearIOFailed(), as they are deprecated; however, retined ioFailed() in SeekableReadStream and File for now (so for now this mainly affects WriteStream subclasses)"
The problem is probably that ScummFile has not been correctly converted to the new Stream semantics. In particular it sets its _myIoFailed flag to "true" if one attempts to read beyond the end of the file.This causes all kinds of confusion.
The issue is probably a bit more complex than that, but I don't have time to look into this now. If nobody beats me to it, I'll try to fix it tonight. And get rid of all ioFailed() uses in SCUMM. Ideally, also in all other engines, but that might cause more regressions, so we should discuss it on -devel.
It looks like the problem is that ScummFile::eos() still defines end-of-stream for subfiles as 'pos >= size', and that the 'new'ioFailed() now returns 'eos() || err()', so it flags reading up to the end of the file as an ioFailed.
I just committed a patch that made the end-of-stream behaviour consistent, and double-checked that all uses of ioFailed and eos() in scummvm expect the new behaviour. (r42632)
Thierry, could you check if that indeed fixes the problem with Sam & Max?
I've only tried the intro, but since it used to crash immediately for me, it definitely works a lot better now. I'd be interested to hear from criezy thogh, since he reported the bug and his problems were different from mine.
I can confirm the problem seems to be fixed with r42856 (I didn't play very far but at least it doesn't crash at the end of the intro sequence now).
That's good to hear. Thanks for the report and testing.