#3204 closed defect (fixed)
FREDDI1: Very rare crash on startup
| Reported by: | eriktorbjorn | Owned by: | eriktorbjorn |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Freddi Fish 1 |
Description
Latest SVN snapshot Swedish Freddi 1
Sometimes - say, once in several dozen attempts - ScummVM crashes instantly for me when I start Freddi Fish 1.
Annoyingly, the generated core file is very unhelpful:
Program terminated with signal 11, Segmentation fault. #0 0xb7dc128b in crc32 () from /usr/lib/libz.so.1 (gdb) bt #0 0xb7dc128b in crc32 () from /usr/lib/libz.so.1 #1 0xb7dc40a9 in ?? () from /usr/lib/libz.so.1 #2 0x00000000 in ?? ()
Running Valgrind, I do get a number of warnings about uninitialized variables in deflate(), like this:
==3860== Thread 1: ==3860== Conditional jump or move depends on uninitialised value(s) ==3860== at 0x815623C: CompressedOutSaveFile::processData(int) (compressed-saves.cpp:184) ==3860== by 0x8156288: CompressedOutSaveFile::finalize() (compressed-saves.cpp:241) ==3860== by 0x81563D7: CompressedOutSaveFile::~CompressedOutSaveFile() (compressed-saves.cpp:221) ==3860== by 0x4CBBC47: Scumm::ScummEngine_v60he::o60_closeFile() (script_v60he.cpp:1031) ==3860== by 0x4D8EADB: Scumm::ScummEngine_v72he::executeOpcode(unsigned char) (script_v72he.cpp:375) ==3860== by 0x4D1EAEE: Scumm::ScummEngine::executeScript() (script.cpp:474) ==3860== by 0x4D1ED87: Scumm::ScummEngine::runScriptNested(int) (script.cpp:340) ==3860== by 0x4D1F0DE: Scumm::ScummEngine::runScript(int, bool, bool, int*, int) (script.cpp:88) ==3860== by 0x4D90FB3: Scumm::ScummEngine_v72he::o72_startScript() (script_v72he.cpp:861) ==3860== by 0x4D8EADB: Scumm::ScummEngine_v72he::executeOpcode(unsigned char) (script_v72he.cpp:375) ==3860== by 0x4D1EAEE: Scumm::ScummEngine::executeScript() (script.cpp:474) ==3860== by 0x4D1ED87: Scumm::ScummEngine::runScriptNested(int) (script.cpp:340)
And when I added debug printf()s before and after the line "delete _hOutFileTable[slot];" in o60_closeFile(), when it crashed the message before was printed, but not the message after.
I have no idea what's causing this. It seems the game tries to create a test file - possibly to verify the savegame path - but the script I suspect is doing it won't descumm properly for me.
Ticket imported from: #1726120. Ticket imported from: bugs/3204.
Change History (8)
comment:1 by , 18 years ago
comment:2 by , 18 years ago
The 'test' file created on startup of HE Games is 0 bytes, maybe trying to compress a zero byte file is causing issues?
Also o60_closeFile() used to always check whether a file was open in the past, before closing the file. As there were attempts to close files that were not open by scripts in the past.
comment:3 by , 17 years ago
sev asked me to try and reproduce the crash with -d9. I did, so here's the end of the output before the crash:
(0:68:0xA6): getResourceAddress(String,17) == 0x820cc1c (0:68:0xA6): Original filename *\test (0:68:0xA6): convertFilePath: original filePath is *\test (0:68:0xA6): convertFilePath: converted filePath is test (0:68:0xA6): Final filename to test (0:68:0xA6): o72_openFile: slot 1, mode 2 (0:68:0xA6): push 1 (0:68:0xA7): Script 68, offset 0xa7: [43] o6_writeWordVar() (0:68:0xA7): pop 1 (0:68:0xA9): writeVar(16384, 1) (0:68:0xAA): Script 68, offset 0xaa: [3] o6_pushWordVar() (0:68:0xAC): readvar(16384) (0:68:0xAC): push 1 (0:68:0xAD): Script 68, offset 0xad: [1] o6_pushWord() (0:68:0xAF): push -1 (0:68:0xB0): Script 68, offset 0xb0: [E] o6_eq() (0:68:0xB0): pop -1 (0:68:0xB0): pop 1 (0:68:0xB0): push 0 (0:68:0xB1): Script 68, offset 0xb1: [5D] o6_ifNot() (0:68:0xB1): pop 0 (0:68:0xBA): Script 68, offset 0xba: [3] o6_pushWordVar() (0:68:0xBC): readvar(16384) (0:68:0xBC): push 1 (0:68:0xBD): Script 68, offset 0xbd: [D9] o60_closeFile() (0:68:0xBD): pop 1 Segmentation fault
comment:4 by , 17 years ago
If you build ScummVM without zlib support, does the problem still occur?
comment:5 by , 17 years ago
It's hard to say for sure, but I haven't managed to crash it without zlib. I did have to use the --gui-theme=classic option because otherwise it wouldn't get through loading the theme.
Strangely enough, if I use the --gui-theme=classic option when zlib support is enabled, ScummVM *always* crashes for me when starting Freddi 1. (It also claims that "Config 'classic' is NOT usable for themes or not found!", but I don't know if that's a bug or not.)
I'm using Debian's zlib packages, version 1:1.2.3-15.
comment:6 by , 17 years ago
It seems that at least *part* of the problem is that when CompressedOutSaveFile::processData() is called, _stream.avail_in is uninitialized and, in my case, a very large negative number.
comment:7 by , 17 years ago
After discussing with Fingolfin, and initializing _stream.avail_in and _stream.next_in to 0, the crash has gone from "happens every single time" to "didn't happen at all in several dozen tries". I think we can close this.
comment:8 by , 17 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Ok, so that part of the Valgrind log didn't point to deflate() after all. Some of the subsequent errors did, though.