Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#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 eriktorbjorn, 17 years ago

Ok, so that part of the Valgrind log didn't point to deflate() after all. Some of the subsequent errors did, though.

comment:2 by Kirben, 17 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 eriktorbjorn, 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 Kirben, 17 years ago

If you build ScummVM without zlib support, does the problem still occur?

comment:5 by eriktorbjorn, 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 eriktorbjorn, 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 eriktorbjorn, 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 eriktorbjorn, 17 years ago

Owner: set to eriktorbjorn
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.