Opened 21 years ago
Closed 20 years ago
#1546 closed defect (fixed)
FT: Crash at junkyard
| Reported by: | SF/duloque | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | high | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Full Throttle |
Description
Using: - FT German PC CD Version - 0.6.0 on Mac OS X 10.3
When beeing on the junkyard and trying to leave left to the scene with the dog, the game crashes. I reproduced the error 3 times. Savegame attached.
Same error with 0.6.0 Win32
Ticket imported from: #918280. Ticket imported from: bugs/1546.
Attachments (1)
Change History (23)
by , 21 years ago
comment:2 by , 21 years ago
Sadly I don't have the german FT, so I can't use that savegame...
If you have the developer tools installed on OSX, maybe you can use "gdb" to provide us with some additional information. If you do have the dev tools installed, tell us, then we can tell you how to produce a "backtrace" with gdb (or maybe you already know how to do that :-).
Lastly, there was yet another INSANE bug fixed commited to CVS today. Maybe you can try out tomorrow's daily Windows build to see if the problem is still there?
comment:3 by , 21 years ago
| Component: | → Engine: SCUMM |
|---|---|
| Game: | → Full Throttle |
comment:4 by , 21 years ago
Okay, game still crashes with Daily Snapshot of today. The errormessage is: Invalid actor -11327 in o6_getActorScale
> If you have the developer tools installed on OSX I do have.
> maybe you can use "gdb" to provide us with some additional information. hmmm..
> then we can tell you how to produce a "backtrace" with gdb (or maybe you already know how to do that :-). I don't, so tell me and i will try ;o)
comment:5 by , 21 years ago
Ah, so it does do an "orderly" exit, after all (we distinguish between 'real' crashes, like seg faults; and crashes where we catch a bad situation and make the application self-terminate, to prevent real harm from happening). In this case, a strange value is used in a script. Do you always get the same error message, or does it vary?
This could be due to corrupt data files; or due to a specific problem with the German version of FT (whether the problem is in ScummVM, or the data files, is another question).
Nothing I can do about it w/o a german FT for testing. Maybe somebody else on the team has it... or maybe I can get it cheap from ebay :-)
comment:6 by , 21 years ago
>Ah, so it does do an "orderly" exit, after all (we distinguish >between 'real' >crashes, like seg faults; and crashes where we catch a bad situation >and >make the application self-terminate, to prevent real harm from >happening). In this case, a strange value is used in a script. Ahh, interesting thing. =) Should "orderly exits" also be reported?
>Do you >always get the same error message, or does it vary? The error message stays the same. Only the number varies.
>This could be due to corrupt data files; or due to a specific >problem with >the German version of FT (whether the problem is in ScummVM, >or the >data files, is another question). It worked from time to time in 0.5.1.. I tried a couple of times and when it didn't crash i could continue the game. No possibility with 0.6.0. :/ The program always exits.
Oh, thanks for your support anyway ;)
comment:7 by , 21 years ago
Yes, always report "orderly exits". After all, to the end user they are not any different from a "real" crash. The game unexpectedly quits, which is always bad.
> The error message stays the same. Only the number varies. Interesting.
Can you start ScummVM with the option "-d9" (this will print tons of debug information), and then when it crashes, tell us the last 10 lines or so. This should give some additional insights into the nature of the problem.
Finally, I hope I'll have a german FT in a couple days :-)
comment:9 by , 21 years ago
| Status: | new → pending |
|---|
comment:10 by , 21 years ago
If we had the debug log, we could probably do a bit about the crash... as it is, nothing :-/
comment:11 by , 21 years ago
| Status: | pending → new |
|---|
comment:12 by , 21 years ago
Sorry for my missing response. I've been offline for a week. :/
So here the log comes! I startet todays Snapshot wir "-d9" Parameter an the Terminal showed this last ~20 lines:
getResourceAddress(String,21) == 0x1182a74 Script 2014, offset 0x98b6: [5D] o6_ifNot() Script 2014, offset 0x98b9: [1] o6_pushWord() Script 2014, offset 0x98bc: [1] o6_pushWord() Script 2014, offset 0x98bf: [3] o6_pushWordVar() readvar(16384) Script 2014, offset 0x98c2: [3] o6_pushWordVar() readvar(16385) Script 2014, offset 0x98c5: [B] o6_wordArrayIndexedRead() readvar(419) getResourceAddress(String,21) == 0x1182a74 Script 2014, offset 0x98c8: [3] o6_pushWordVar() readvar(16384) Script 2014, offset 0x98cb: [3] o6_pushWordVar() readvar(16385) Script 2014, offset 0x98ce: [1] o6_pushWord() Script 2014, offset 0x98d1: [1] o6_pushWord() Script 2014, offset 0x98d4: [5E] o6_startScript() runScript(2013) from 2014-28 getResourceAddress(Room,28) == 0x51b0004 Script 2013, offset 0x933f: [3] o6_pushWordVar() readvar(16384) Script 2013, offset 0x9342: [AA] o6_getActorScaleX() (28:2013:0x9342): Invalid actor 25924 in o6_getActorScale Locking mutex IMuseDigital::pause() Unlocking mutex IMuseDigital::pause() Locking mutex IMuseDigital::callback() Unlocking mutex IMuseDigital::callback()
Last 2 lines are in a loop until i type "exit" in scummvm console.
Thx for doing such a great job with ScummVM! :)
comment:13 by , 20 years ago
uuhhrrmm.. checked with current Snapshot and error still occurs :/ *buhuhu*
comment:14 by , 20 years ago
The output looks like an iMUseDigital lockup.
Does the problem still occur for you, duloque?
comment:15 by , 20 years ago
| Owner: | set to |
|---|
comment:16 by , 20 years ago
I had to take OS X Snapshot from 15/07, because i don't know how to compile myself:
getResourceAddress(String,19) == 0x136f594 Script 2014, offset 0x9878: [3] o6_pushWordVar() readvar(16384) Script 2014, offset 0x987b: [3] o6_pushWordVar() readvar(16385) Script 2014, offset 0x987e: [1] o6_pushWord() Script 2014, offset 0x9881: [1] o6_pushWord() Script 2014, offset 0x9884: [5E] o6_startScript() runScript(2013) from 2014-28 getResourceAddress(Room,28) == 0x4e3d004 Script 2013, offset 0x933f: [3] o6_pushWordVar() readvar(16384) Script 2013, offset 0x9342: [AA] o6_getActorScaleX() (28:2013:0x9342): Invalid actor 8224 in o6_getActorScale Locking mutex IMuseDigital::callback() <-- LOTS OF! Unlocking mutex IMuseDigital::callback() <-- LOTS OF! (28:2013:0x9342): Invalid actor 8224 in o6_getActorScale!
Well, it does not seem to work. :(
comment:17 by , 20 years ago
is it imuse thing "(28:2013:0x9342): Invalid actor 25924 in o6_getActorScale" ?
comment:18 by , 20 years ago
No, but this is: Locking mutex IMuseDigital::callback() <-- LOTS OF! Unlocking mutex IMuseDigital::callback() <-- LOTS OF!
It's impossible to tell from that output what is the cause and what is the consequence... maybe the actor/script system is messed up and causes imuse to break; or maybe imuse is messed up and causes the script system to break.. who knows... but maybe you can have a look at this, too, aquadran?
Anyway, since neither of us (I assume?) owns the german version of FT, the savegame is useless, which is kind of a pity :-/
comment:19 by , 20 years ago
| Owner: | removed |
|---|---|
| Priority: | normal → high |
comment:21 by , 20 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:22 by , 20 years ago
Fixed in CVS. Turned out that a workaround I put into CVS for similiar (array) issues was not having any effect due to two stupid mistakes of mine <sigh>.
FT german pc