Opened 12 years ago

Closed 10 years ago

#3502 closed defect (fixed)

CRUISE: crash right after resource init

Reported by: SF/mcylke Owned by: vincenthamm
Priority: normal Component: Engine: Cruise
Keywords: Cc:
Game: Cruise for a Corpse


I know this engine is not yet announced, but have been instructed by Sev to put this bugreport here.

So here it goes, right at the beginning, I get following messages and after that a crash. I attach a backtrace from gdb.

WARNING: Config 'modern' is NOT usable for themes or not found!
WARNING: falling back to classic style!
Looking for cruise
Trying to start game 'Cinematique evo.2 engine game'
WARNING: Target upgraded from cruise to cruise!
Disk number: 1
Disk number: 2
Disk number: 3
Disk number: 4
Disk number: 5
Load overlay: AUTO00
Attempting to load overlay file AUTO00.OVL...
File found on disk 0
OVL loading done...

Program received signal SIGSEGV, Segmentation fault.

I'm running: FreeBSD 6.2-STABLE amd64, should that matter.


Ticket imported from: #1848957. Ticket imported from: bugs/3502.

Attachments (1)

cruise-coredump.txt (1.5 KB) - added by SF/mcylke 12 years ago.

Download all attachments as: .zip

Change History (12)

Changed 12 years ago by SF/mcylke

Attachment: cruise-coredump.txt added


comment:1 Changed 12 years ago by sev-

Component: Engine: SCUMM
Game: Day of the Tentacle
Owner: set to vincenthamm

comment:2 Changed 12 years ago by sev-

Yaz, this is the guy who will work on objectifying.

Marcin, please, provide md5s for your game data files. It works well here.

comment:3 Changed 12 years ago by sev-

Component: Engine: SCUMMEngine: Cruise
Game: Day of the TentacleCruise for a Corpse

comment:4 Changed 12 years ago by bluegr

Out of curiosity, are you using a 64-bit version of FreeBSD, or the regular 32-bit version? The cruise engine does use a lot of pointers with type casting, which might cause problems in 64-bit systems

comment:5 Changed 12 years ago by SF/mcylke

Yes, I'm using 64-bit version. If it is not recommended to do this I have another machine, i386 arch. But I may also try to fix it to run on 64bit, but need a little guidance for this :)

I'll post md5 sums in the evening, because now I'm at work :)

comment:6 Changed 12 years ago by bluegr

No no you misunderstood me. I never said that it's not recommended to develop under a 64-bit operating system... I mentioned that the cruise engine uses a lot of pointers with type casting, which might CAUSE PROBLEMS in 64-bit systems.

ScummVM code *should* work both for 32-bit AND 64-bit systems, but in this particular case, if this code doesn't work under 64-bit systems, then it should be fixed. The most likely culprit is that 32-bit systems have 32-bit pointers, whereas 64-bit systems have 64-bit pointers. Also, an integer is 32 bits in 32-bit systems and 64 bits in 64-bit ones. So, if the engine crashes for you under a 64-bit OS but it works under a 32-bit OS, it should be fixed. Not everyone has a 64-bit OS, so you're welcome to fix the crash :)

comment:7 Changed 12 years ago by vincenthamm

I'll look into that particular part. Cruise uses a bunch of "load in place", ie loading data directly to a scructure that is bound to break when changing of cpu architecture.
I can probably fix most of the issues by removing those tricks, but I probably won't be able to test it in 64bits proper until I have a setup up and running (in a few next weeks).

Just to make sures it is not data related, can you try a 32bits build ? (I suppose it is possible to cross-compile and execute 32bit code on FreeBSD).

comment:8 Changed 12 years ago by SF/mcylke

thebluegr: I know that ScummVM runs on 64bit archs, I use it that way, I meant engine code.

yazoo: If You need help with this one - like 64bit arch testing etc, I can help.

comment:9 Changed 12 years ago by SF/mcylke


Here are the md5's for my game files:

MD5 ("D1") = 4a4079e06eb2f7ba7a12821c7c58a3f6
MD5 ("D2") = c4d62b6dcca08e5caf06c01889282859
MD5 ("D3") = a3deb6e481689f1d3303caecb8a6c401
MD5 ("D4") = 2521dc256a4368da87585c936b451dd7
MD5 ("D5") = ea8ea3bfaa27cf4c2f61470447c87eea
MD5 ("DELPHINE.CFG") = bcf36697a7eda35b0a5d45a768b805c0
MD5 ("DELPHINE.EXE") = 7971cc8097d53425b261f55a233c2163
MD5 ("DELPHINE.LNG") = 39a6e9e5a7043feae5793a6a0760229a
MD5 ("DISK1.EXE") = f630a749d414fcff0ff1b162fe13447c
MD5 ("FILE_ID.DIZ") = aa0e15bb94b27ee11bd4325b348e99f8
MD5 ("READ.ME") = 9003dda722e2e3cb24faca793257fc83
MD5 ("README.BAT") = 06eb7b6ce8961650f4f1b5f6e5438d02
MD5 ("SETUP.EXE") = 93eabd46491f2188696c9ea86f1ad42f
MD5 ("SYSTEM.FNT") = ea8e30d7152e7aced033c2f85b2be654
MD5 ("TRSI.NFO") = ad89888b7c13ae1e06833f790be35669
MD5 ("VGADRV.BIN") = bb81b5307d513d453836a91e7dcae552
MD5 ("VOL.1") = d438d9116c13aff8f1282215512bbddf
MD5 ("VOL.2") = d6bb6bd972fa2f52d964af816e0c87a3
MD5 ("VOL.3") = ca278bd52291ccd25769364c01e4e583
MD5 ("VOL.4") = 96be50e7fff4d0a924ab252fb3160cc2
MD5 ("VOL.5") = 73b4a1ea41898ee246ddcd443b73ff94
MD5 ("VOL.CNF") = c113406537f55f99b53e797eb2614d10
MD5 ("VOL.END") = 9a2645cc3a76e01937517e41b423ed91

comment:10 Changed 10 years ago by dreammaster

This seems to correspond to the point where eriktorbjorn identified invalid writes using Valgrind. The culprit was a background caching with a start X of -1 - it was accidentally getting converted to an unsigned value (such as 0xffff), and the area being saved was overwriting legitimate memory. I'm going to presume this was the cause, and close this bug.

comment:11 Changed 10 years ago by dreammaster

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.