Opened 16 years ago
Closed 15 years ago
#3502 closed defect (fixed)
CRUISE: crash right after resource init
| Reported by: | SF/mcylke | Owned by: | vincenthamm |
|---|---|---|---|
| Priority: | normal | Component: | Engine: Cruise |
| Version: | Keywords: | ||
| Cc: | Game: | Cruise for a Corpse |
Description
Hello 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.
Bye Marcin
Ticket imported from: #1848957. Ticket imported from: bugs/3502.
Attachments (1)
Change History (12)
by , 16 years ago
| Attachment: | cruise-coredump.txt added |
|---|
comment:1 by , 16 years ago
| Component: | → Engine: SCUMM |
|---|---|
| Game: | → Day of the Tentacle |
| Owner: | set to |
comment:2 by , 16 years ago
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 by , 16 years ago
| Component: | Engine: SCUMM → Engine: Cruise |
|---|---|
| Game: | Day of the Tentacle → Cruise for a Corpse |
comment:4 by , 16 years ago
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 by , 16 years ago
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 by , 16 years ago
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 by , 16 years ago
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 by , 16 years ago
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 by , 16 years ago
Hello
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 by , 15 years ago
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 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
backtrace