#818 closed defect (worksforme)
INDY3: manhole crash
Reported by: | SF/hibernatus | Owned by: | fingolfin |
---|---|---|---|
Priority: | normal | Component: | Engine: SCUMM |
Version: | Keywords: | ||
Cc: | Game: | Indiana Jones 3 |
Description
ScummVM 0.4.2cvs Built on May 27 2003. under WinXP
Sometimes when Indy goes through the manhole in Venice, i get a crash without parachute. Here is a save game in the catacombs.
Ticket imported from: #744129. Ticket imported from: bugs/818.
Attachments (2)
Change History (15)
by , 21 years ago
comment:1 by , 21 years ago
I've noticed that if scummvm doesn't crash once, it never crashes, even if i load that save game again (indy3.s30). But if i close scummvm launch it again, it can crash.
comment:3 by , 21 years ago
It crashed once for me - with an SDL parachute message - but unfortunately I've been unable to reproduce it while running it in a debugger.
comment:4 by , 21 years ago
For some reason, I haven't been able to crash it at all in the debugger, and only once when running it with the -d 9 option. That time the last things it printed were
Script 679, offset 0x7151: [13] o5_actorSet() readvar(16384) Script 679, offset 0x7157: [1A] o5_move() Script 679, offset 0x715c: [80] o5_breakHere() getResourceAddress(Buffer,9) == 17780748 getResourceAddress(Buffer,5) == 36332828 getResourceAddress(Buffer,9) == 17780748 getResourceAddress(Buffer,5) == 36332828 getResourceAddress(Buffer,9) == 17780748 getResourceAddress(Buffer,5) == 36332828 getResourceAddress(Buffer,9) == 17780748 getResourceAddress(Buffer,5) == 36332828 getResourceAddress(Buffer,9) == 17780748 getResourceAddress(Buffer,5) == 36332828 getResourceAddress(Costume,47) == 36242908 getResourceAddress(Matrix,2) == 17813324 getResourceAddress(Buffer,5) == 36332828 getResourceAddress(Buffer,9) == 17780748
But I don't know if this is useful or just a red herring. I didn't get any parachute message this time because I had deliberately turned them off, hoping to get a core dump. Unfortunately MinGW isn't clever enough for that. Maybe I'll have more luck when I try it under Linux.
comment:5 by , 21 years ago
Did you reproduce this with exactly this save game? If yes, can you try this: load the save game, leave via the tunnels, re-enter the room, then save again (as a new savefile). Then try if you can reproduce the bug with that new savegame. Just want to exclude any save game weirdnesses (although I don't think that's a likely cause).
comment:6 by , 21 years ago
Yeah well folks, I still can't reproduce this. As long nobody replies to my questions, and/or proofs this is an actual bug by creating a new, independant save game that also exhibits this problem, I'll consider this is a broken savegame.
comment:7 by , 21 years ago
Status: | new → pending |
---|
comment:8 by , 21 years ago
Status: | pending → new |
---|
comment:9 by , 21 years ago
(Sorry, I meant to answer before.) Right now I can't seem to reproduce it at all. But when I did, it was with the original savegame.
I'm inclined to agree with you. If whever caused the problem is still in the CVS trunk, it'll resurface again eventually. (Probably a few days after the next stable release. ;-)
comment:10 by , 21 years ago
Status: | new → pending |
---|
comment:12 by , 21 years ago
That's an automatic feature. "Pending" is a special state (see also the help text avaiable via the little question mark next to "Status:". It marks a bug as "pending response from somebody". If no response comes withing some preset time, it'll automatically be closed (or deleted? forgot). Otherwise, as soon as any activity is registered, it automatically reverts to open (hence even though I didn't touch the status, submitting this would re-open it... but now I will change the status, to closed :-)
comment:13 by , 21 years ago
Owner: | set to |
---|---|
Resolution: | → worksforme |
Status: | pending → closed |
catacombs entry. 0.4.2cvs 05/27