Opened 20 years ago
Closed 19 years ago
#1942 closed defect (fixed)
BS1: 64-bit crash when menu appears
| Reported by: | SF/cmacksey | Owned by: | lavosspawn |
|---|---|---|---|
| Priority: | normal | Component: | Engine: Sword1 |
| Version: | Keywords: | ||
| Cc: | Game: | Broken Sword 1 |
Description
BS1 crashes when compiled as 64-bit. It crashes the moment the icons are shown on the bottom of the screen during conversation.
The game is playable with the same version of ScummVM on the same system, but compiled as 32-bit instead (-m32). Other games (LucasArts) under the 64-bit version of ScummVM played flawlessly.
ScummVM Version: 0.70, compiled with GCC 3.4.3 Operating System: Linux 2.6.9 (x86_64) Language: English Game: BS1 North American version, released as "Circle of Blood" (although I suspect the problem is not version-dependant)
No saved game is necessary. Steps to reproduce: * Start a new game, skip through all the intro. * Walk into the cafe. * Talk to the waitress. Watch the crash immediately after she asks "Are you a doctor?" - the first occasion that the icons appear on the bottom.
Ticket imported from: #1153682. Ticket imported from: bugs/1942.
Change History (20)
comment:1 by , 20 years ago
comment:2 by , 20 years ago
Just fetched CVS now, compiled and ran it. The problem is there, as well.
I'll do the GDB backtrace tomorrow sometime - it's pretty late here and I'm getting sleepy :)
comment:3 by , 20 years ago
Took a while to get it compiled with debug information :) Anyway, when it crashes, it crashes here:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 182916600832 (LWP 770)] Sword1::Mouse::setLuggage (this=0x0, resId=0, rate=0) at sword1/mouse.cpp:260 260 _currentLuggageId = resId;
The backtrace is as follows: #0 Sword1::Mouse::setLuggage (this=0x0, resId=0, rate=0) at sword1/mouse.cpp:260 #1 0x00000000004fdf14 in Sword1::Menu::fnChooser (this=0xef83d0, compact=0xf2c62c) at sword1/menu.cpp:350 #2 0x00000000004fc51f in Sword1::Logic::fnChooser (this=0x0, cpt=0x0, id=0, c=0, d=0, e=0, f=0, z=0, x=0) at sword1/logic.cpp:1309 #3 0x00000000004fb07b in Sword1::Logic::interpretScript (this=0xf18010, compact=0xf2c62c, id=8388608, scriptModule=0x4fc512, scriptBase=0, scriptNum=0) at sword1/logic.cpp:499 #4 0x00000000004fad64 in Sword1::Logic::scriptManager (this=0xf18010, compact=0xf2c62c, id=8388608) at sword1/logic.cpp:431 #5 0x00000000004fa6ab in Sword1::Logic::processLogic (this=0xf18010, compact=0xf2c62c, id=8388608) at sword1/logic.cpp:206 #6 0x00000000004fa546 in Sword1::Logic::engine (this=0xf18010) at sword1/logic.cpp:144 #7 0x00000000004f6b1a in Sword1::SwordEngine::mainLoop (this=0xec9010) at sword1/sword1.cpp:509 #8 0x00000000004f6964 in Sword1::SwordEngine::go (this=0xec9010) at sword1/sword1.cpp:452 #9 0x000000000040e930 in runGame (detector=@0x7fbffff6c0, system=@0xe72dd0) at base/main.cpp:277 #10 0x000000000040ed4a in main (argc=1, argv=0x7fbffff848) at base/main.cpp:407
comment:4 by , 20 years ago
| Owner: | set to |
|---|
comment:6 by , 20 years ago
Sorry, been without internet connection for the last week. I'll try and look into this tomorrow. =)
comment:8 by , 19 years ago
Any news on this?
Erik, haven't you fixed some 64 bit issues in BS1 in the past? Or was that SKY or BS2 ? I keep forgetting, sorry :-(
comment:9 by , 19 years ago
| Owner: | changed from to |
|---|
comment:10 by , 19 years ago
| Owner: | removed |
|---|
comment:11 by , 19 years ago
I changed BS2 so that it wouldn't cast between pointers and 32-bit integers, which at least theoretically should help when playing it on 64-bit systems.
But that has very little to do with BS1, I'm afraid, and I have no ideas about this bug.
comment:12 by , 19 years ago
Strange. In cmacksey GDB stack trace, "this" is 0 twice. The odd thing is that the first time it happens (level #2) no crash occurs, but rather a apparenly valid (?) value of _menu is used.
Maybe the stack trace is just corrupted?
BTW, why is Logic::_scriptVars static ?
comment:13 by , 19 years ago
I've marked the structs in sword1/object.h as packed, because they looked to me like they ought to be. Does that make any difference at all for this bug report?
comment:14 by , 19 years ago
I've downloaded the daily snapshot at the end of last week (on October, the 14. 2005) from the homepage. But the problem is still there. I also checked the object.h file - all structures are marked as packed.
It's still the same: moving the mouse to the top of the screen entering the menu will cause ScummVM to crash with the same error (same trace when using gdb). But only at 64bit build. The 32bit build in Win32 works fine.
comment:15 by , 19 years ago
Looking at our default makefile, I think we compile by default with -O .. Now the following might be helpful and I'd appreciate if you could help us this way:
Could you disable the "-O", i.e. comment out the following line in "Makefile":
CXXFLAGS+= -O -Wuninitialized
After that, do a "make clean && make" and the use GDB again -- does that produce a different backtrace (with different I mean in particular the vallues displayed for various variables, like the "this" in Sword1::Logic::fnChooser) ? It might be a good idea to attach the new backtrace to this tracker item in any case... Thanks!
comment:16 by , 19 years ago
I compiled without -O, but there is no different. Here's the backtrace from GDB:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912524155840 (LWP 10152)] 0x000000000059f886 in Sword1::Screen::showFrame (this=0x0, x=0, y=0, resId=4294967295, frameNo=0, fadeMask=0x77f280 "\001\a\005\003\002\004\006", fadeStatus=0 '\0') at screen.cpp:908 908 _system->copyRectToScreen(frame, 40, x, y, 40, 40); (gdb) bt #0 0x000000000059f886 in Sword1::Screen::showFrame (this=0x0, x=0, y=0, resId=4294967295, frameNo=0, fadeMask=0x77f280 "\001\a\005\003\002\004\006", fadeStatus=0 '\0') at screen.cpp:908 #1 0x00000000005900eb in Sword1::Menu::refresh (this=0xaa12c0, menuType=0 '\0') at menu.cpp:240 #2 0x00000000005846d1 in Sword1::SwordEngine::mainLoop (this=0xa38ef0) at sword1.cpp:515 #3 0x0000000000584e0f in Sword1::SwordEngine::go (this=0xa38ef0) at sword1.cpp:452 #4 0x00000000004129df in runGame (detector=@0x7ffffffae660, system=@0xa0ed50) at main.cpp:310 #5 0x00000000004130e3 in main (argc=1, argv=0x7ffffffae8e8) at main.cpp:456
comment:17 by , 19 years ago
Thanks. Now, could you do another test: modify sword1/menu.h. Right now, these are the last two (non-static) members of class Menu:
Screen *_screen; Mouse *_mouse;
Could you try moving those up, i.e. cut the two lines, and paste them right after the "private:" in line 80 ?
Then please compile & run again and tell us if it makes any difference.
The reasoning behind this test: If this is some kind of out of bounds memory access / overwrite, then this change should avoid it (and cause the crash to occur in another place). So it might help us narrow down the issue a bit.
comment:18 by , 19 years ago
I guess I found the cause. A pretty simple one, too. The Menu contructor initializes the Menu::_subjects[] array to zero, elements 0 through 119. But the array only has 16 elements. -_-
Will commit the fix as soon as I'm back at home.
comment:19 by , 19 years ago
| Owner: | set to |
|---|
comment:20 by , 19 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
I think there was a 64bit issue we fixed after 0.7.0; maybe you can try whether the crash still occurs with latest CVS of ScummVM?
If the crash persists there, could you provide some additional information as to where the crash occurs precisely? I.e. run the game with gdb, and after it crashes, create a backtrace and send that to us. To do that:
gdb scummvm
Once the GDB prompt shows, you can launch ScummVM by entering
run ARGS
where ARGS are any arguments you would pass to ScummVM normally. Then finally, after the crash, you'll be back to the GDB prompt, on which you can enter:
bt
to produce the desired backtrace.
Thanks!