Opened 16 years ago
Closed 16 years ago
#4015 closed defect (fixed)
MONKEY2: Crash during gameplay
| Reported by: | SF/trik72 | Owned by: | wjp |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Monkey Island 2 |
Description
ScummVM version: 0.12.0 Bug details: Using the coin return on the grog machine will close the ScummVM without any warning. Language of game: English Version of game: Floppy Platform and Compiler: Maemo N800/OS2008 Other remarks: The crash won't occur on Win32 version (0.12.0), the same bug has been reported to exist on Win CE platform. See forum post: http://forums.scummvm.org/viewtopic.php?t=6502
Ticket imported from: #2340221. Ticket imported from: bugs/4015.
Attachments (1)
Change History (17)
by , 16 years ago
| Attachment: | monkey2.s09 added |
|---|
comment:1 by , 16 years ago
| Summary: | Crash during gameplay → MONKEY2: Crash during gameplay |
|---|
comment:2 by , 16 years ago
Run ScummVM from the command line. It will print out the error message there. Alternatively you may redirect stderr to some file.
comment:3 by , 16 years ago
Ok, this is what I got:
/usr/games $ ./scummvm Using configuration file: /home/user/.scummvmrc User picked target 'monkey2' (gameid 'monkey2')... Looking for a plugin supporting this gameid... Scumm Engine Starting 'Monkey Island 2: LeChuck's Revenge' Fatal signal: Segmentation Fault (SDL Parachute Deployed) Segmentation fault /usr/games $
comment:4 by , 16 years ago
I don't get any crashes, or even Valgrind warnings, when I try it on my Linux box. I don't know anything about the Maemo. Is it possible to run a debugger on it to find out where ScummVM crashes?
comment:6 by , 16 years ago
I'm only familiar with how I'd do it under Linux, where I'd run ScummVM under GDB like so:
$ gdb ./scummvm [GDB prints a greeting followed by a prompt.] (gdb) run [GDB prints some information about starting the program.]
The program runs as usual, but if it crashes GDB should print a message, followed by a prompt. Typing "bt" at the prompt prints a "backtrace" of how the program got to the point where it crashes. (Though only if the program still hasn't been stripped of the debugging information.) After that... well, it depends on what kind of error it is...
comment:7 by , 16 years ago
I am not a developer so it took a while to figure out how to get the gdb installed, but here it is:
/usr/games $ gdb ./scummvm.bin GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "arm-linux-gnueabi"... (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/games/scummvm.bin BFD: /usr/lib/debug/lib/ld-2.5.so: warning: sh_link not set for section `.ARM.exidx' (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) BFD: /usr/lib/debug/lib/libpthread-2.5.so: warning: sh_link not set for section `.ARM.exidx' (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 1073864304 (LWP 1609)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) BFD: /usr/lib/debug/lib/libc-2.5.so: warning: sh_link not set for section `.ARM.exidx' (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Using configuration file: /home/user/.scummvmrc (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread 1086899344 (LWP 1612)] [New Thread 1095287952 (LWP 1613)] User picked target 'monkey2' (gameid 'monkey2')... Looking for a plugin supporting this gameid... Scumm Engine Starting 'Monkey Island 2: LeChuck's Revenge'
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1073864304 (LWP 1609)] 0x000f16a4 in ?? () (gdb) bt #0 0x000f16a4 in ?? () Cannot access memory at address 0x28 (gdb)
comment:8 by , 16 years ago
I guess there was no debugging information left, then. I was hoping to get something more like this, though this is just an example. I deliberately introduced a crash by calling abort():
(gdb) bt 0 0xb7f79424 in __kernel_vsyscall () #1 0xb79fb640 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb79fd018 in abort () from /lib/i686/cmov/libc.so.6 #3 0x0816752b in Scumm::ScummEngine_v5::o5_walkActorTo (this=0x98a7848) at engines/scumm/script_v5.cpp:2685 #4 0x08165db6 in Scumm::ScummEngine_v5::executeOpcode (this=0x98a7848, i=254 '.') at engines/scumm/script_v5.cpp:375 #5 0x0806d073 in Scumm::ScummEngine::executeScript (this=0x98a7848) at engines/scumm/script.cpp:476 ...
That is, a useful backtrace would show how functions were called to eventually reach the line where the crash happened.
Did you build ScummVM yourself? If so, did you run "strip" on the resulting program? That would remove most (all?) debugging information. You may be able to find out by using the "file" command. On my computer, that says:
$ file scummvm scummvm: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped
comment:9 by , 16 years ago
No, I didn't build the ScummVM myself. I installed it via OS2008 Application Manager which downloads install packages from several preconfigured repositories. But I think it should be the same package that is downloadable here:
http://maemo.org/downloads/product/OS2008/scummvm/
Unfortunately I don't have that file utility installed by default and due to generic name I couldn't find any information how to get it.
comment:10 by , 16 years ago
Would like to also add that i am experiencing this exact same bug also, i am using scumm 0.12.0 with my Nokia 6220
comment:11 by , 16 years ago
I looked up the crash address reported in the disassembly a friend made of scummvm.bin in http://repository.maemo.org/extras/pool/chinook/free/s/scummvm/scummvm_0.12.0_armel.deb (hoping it is the right binary). That address is in custom assembly code in engines/scummvm/proc3ARM.s , specifically, the following instruction :
LDRB r14,[r10],r11 @ r14 = mask[0] mask += _numStrips
robinwatts, I'm assigning this to you. Could you take a look?
comment:12 by , 16 years ago
| Owner: | set to |
|---|
comment:13 by , 16 years ago
Follow-up: the assembly code doesn't seem to do the short-circuit evaluation of the logical or in
if (_scaleY == 255 || v1.scaletable[scaleIndexY++] < _scaleY) {
If I un-short-circuit the C++-code, valgrind gives a memory error at that point when using the coin return on my system too (amd64 linux).
comment:14 by , 16 years ago
Sorry, my previous comment was nonsense. I meant to look at the line below that:
The C++ expression is: masked = (y < 0 || y >= _out.h) || (v1.x < 0 || v1.x >= _out.w) || (v1.mask_ptr && (mask[0] & maskbit));
but in the assembly, the mask[0] dereference is the first instruction.
comment:15 by , 16 years ago
It turned out to be more subtle. The inner loop in the asm uses min(len,height) as a loop counter, but this causes an near-infinite loop (but first a segfault) when len == 0. I committed a fix as r36039. I don't check height == 0 because then the C++ code would go into a near-infinite loop too.
comment:16 by , 16 years ago
| Owner: | changed from to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Savegame from the room where the grog machine is