#3010 closed defect
AGI Lock up
| Reported by: | SF/rmaniac | Owned by: | eriktorbjorn |
|---|---|---|---|
| Priority: | normal | Component: | Engine: AGI |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
I am running the latest SVN. I compiled it from source. Whenever I play an AGI game (I used Space Quest 1 & 2) it will lock up after 15 min or so of play. Ego stops moving, and no menus work but the mouse curser can still be moved around the screen. To reproduce load an AGI game and either play for a while or just put it in the background while you do something else. After a while when you come back all will have stopped.
Ticket imported from: #1640420. Ticket imported from: bugs/3010.
Attachments (1)
Change History (24)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
ScummVM 0.10.0svn (Jan 20 2007 10:44:32) English Mac OS X This game only came in floppy. It was Space Quest 1 2.2 and Space Quest 2 2.0F I am on an Intel Mac, A friend also tried the latest Mac OS X snapshot from 1/12/07 on PPC and had the same issue. Save game not needed it happens from the begining. Screenshot at anytime would look just like the issue because everything just stops moving.
comment:3 by , 17 years ago
I've noticed a similar but possibly unrelated bug in LSL1 where the -input- line stops working after about 10 minutes of play, yet the mouse still works (and still moves Ego, and opens menus).
I assume with your bug even clicking with the mouse won't move Ego? I haven't been able to replicate this freeze in SQ1, myself.
comment:4 by , 17 years ago
Correct once this happens Ego will not move and menus will not open.. I can just dance the cursor around the screen. Are you running on a Mac? Two SVN versions have done this on two Macs (Intel and PPC) I'll toss it on my linux box maybe later tonight and see if I can make it happen there.
comment:5 by , 17 years ago
I compiled the latest svn on linux intel and Mac OS X on intel today. I put them both into space quest one (2.2 according to scummvm) and loaded them to the first game play screen. The both made it to the "KABOOM" screen where the station blew up and then I would guess 5 min or so later they both locked up same as usual. The Mac OS one has my config of a few games and such. The Linux was just a fresh svn compile and all I did was add SQ1.
comment:6 by , 17 years ago
| Summary: | AGI Lock up → AGI: Lock up after playing ~15 min |
|---|
comment:7 by , 17 years ago
I've seen the lockup in Leisure Suit Larry that Endy mentions. I don't understand how - I'm not even sure I'm seeing correctly - but it looks like it gets stuck, forever waiting inside AgiEngine::agiTimerLow(). But how could that be...? I don't have the time to look any closer right now.
comment:8 by , 17 years ago
| Summary: | AGI: Lock up after playing ~15 min → AGI Lock up |
|---|
comment:9 by , 17 years ago
On second thought, wouldn't it happen easily if g_tickTimer is increased too quickly? The difference between g_tickTimer and m would *increase*, not decrease...
comment:10 by , 17 years ago
Disregard the last comment. As g_tickTimer increases, the difference is *supposed* to increase. The loop continues while the difference is *smaller* than 5. I shouldn't try to read code while I'm in a hurry.
So it's still a mystery. The g_tickTimer variable is initialized to 0 at creation time, and then increased by a timer callback. Unless the timer callback stopped for whatever reason, I don't see how it could go wrong.
comment:11 by , 17 years ago
The LSL hang count be a problem with our default timer handler. The following line...
const int32 curTime = g_system->getMillis() * 1000;
...will cause overflows after a while (about half an hour?), and I don't know how gracefully we deal with that. With SMUSH no longer needing microsecond timers (or any timers, for that matter), perhaps we should go back to millisecond timers? Of course, that doesn't actually solve the problem (if there is one), it just postpones it.
Also, the Sarien X11 backend doesn't seem to use a timer at all for this function.
comment:12 by , 17 years ago
| Owner: | set to |
|---|
comment:13 by , 17 years ago
If we still need microsecond timers, perhaps something like the attached patch (completely untested, though I'm going to leave LSL running for 30+ minutes with it to see what happens) would do the trick?
Assigning to Fingolfin, not because I expect him to fix AGI bugs but to give him a chance to comment on the possible timer issue. File Added: timer.diff
comment:14 by , 17 years ago
LSL has been running in the background for about two hours now without any lock-up, so I guess it probably is the timer handler that's behind it.
Of course, this doesn't explain why SQ1 (I only have the SCI version, so I can't test it) hangs after a mere 15 minutes.
comment:15 by , 17 years ago
Thanks Torbjörn. That (unhandled) overflow in the timer code is indeed a serious bug -- good catch.
I am reviewing your patch right now and will probably commit a modified version soon.
comment:16 by , 17 years ago
| Owner: | changed from to |
|---|
comment:17 by , 17 years ago
Well I was gonna test this on the space quests.... cept after updating the svn copy on both machines (and noticing this change is in svn already) I get a error on compile: engines/saga/game.cpp:94:94: error: macro "ADVANCED_DETECTOR_DEFINE_PLUGIN" passed 5 arguments, but takes just 4 ngines/saga/game.cpp:94: error: expected constructor, destructor, or type conversion before ‘;’ token engines/saga/game.cpp: In function ‘void g_SAGA_PluginReg_alloc()’: engines/saga/game.cpp:97: error: ‘Engine_SAGA_gameIDList’ was not declared in this scope engines/saga/game.cpp:97: error: ‘Engine_SAGA_findGameID’ was not declared in this scope engines/saga/game.cpp:97: error: ‘Engine_SAGA_create’ was not declared in this scope engines/saga/game.cpp:97: error: ‘Engine_SAGA_detectGames’ was not declared in this scope
Pretty much all goes downhile from there. But I'm pretty sure that is related to someone elses commit
comment:18 by , 17 years ago
Commited your patch. Not closing this report yet as I don't know whether SQ still has issues.
comment:19 by , 17 years ago
Thanks to whoever fixed the saga stuff.. I head already done the wise thing and compiled with saga disabled. I am testing as such. I have now also compiled with saga and will test with that too.
comment:20 by , 17 years ago
Well kiddos.. more than 40 minutes and counting. Have had the space station blow up on me twice now and no lockup. On Mac OS and Linux. I'm gonna leave these open for the evening and I will give you a final report later tonight if all is well and we can close this puppy out. Thanks!
comment:21 by , 17 years ago
Ok guys. I have had space quest running for almost 8 hours now and it is still happy. I figure if someone has been playing that long and has not won it is their fault. :-) So yeah. Lets call this closed. Thanks!
comment:22 by , 17 years ago
| Status: | new → closed |
|---|
comment:23 by , 6 years ago
| Component: | --Unset-- → Engine: AGI |
|---|
To process your bug report appropriately, we need you to provide the following additional information:
* ScummVM version (PLEASE test the latest CVS/Daily build) * Bug details, including instructions on reproducing it * Language of game (English, German, ...) * Version of game (talkie, floppy, ...) * Platform and Compiler (Win32, Linux, MacOS, ...) * Attach a save game if possible * If this bug only occurred recently, please note the last version without the bug, and the first version including the bug. That way we can fix it quicker by looking at the changes made.
This should only take you a little time but will make it much easier for us to process your bug report in a way that satisfies both you and us.
Thank you for your support!