Zugg Software :: View topic

Wizard Joined: 14 Aug 2004 Posts: 1269

This thread is for unconfirmed lockups in 2.02, where CMUD just stops responding and you are not sure why!

It's happened twice for me so far. Once when I clicked on the Preferences key and once when CMUD didn't even have focus and I was using Firefox. I was connected to the MUD though. It has also disconnected on me once or twice. I think actually these problems may be caused by my C drive (virtually?) running out of disk space. I'm not sure what has filled up the drive - maybe Windows System Restore and Norton UnErase. I don't know if it is possible to handle this situation more gracefully though?

[EDIT: In a lockup, the GUI stops redrawing, you can't even get to CMUD to press the escape key, and you have to go into Task Manager, which shows CMUD as Unresponsive and End the Task. I suppose some lockups may be accompanied by CMUD using 99 or 100% CPU, i.e. probably in a tight loop, but it wasn't using any CPU in my lockups.]

Posted: Wed Sep 05, 2007 11:54 pm

In case this thread explodes, I'll jump in at the start and say that a lockup is different to a threading problem. The latter are often solved by pressing the Esc key. That doesn't mean not to post them - please do! - but make sure you're posting with the right description when you do.

Posted: Thu Sep 06, 2007 2:55 am

I have had this as well.. the mud stop responding.
And when i go to close it out manually, the windows blank out as if there was to scrollback buffer and then just hangs there.
Only was to close it is via task manager.
I've been in other windows when it happens as well.

Wizard Joined: 14 Aug 2004 Posts: 1269

I had another lockup and my C drive had 400 MB free or so. Again, I was in Firefox when it locked up I think.

Posted: Fri Sep 07, 2007 12:05 am

It would help if you'd also tell me what CMUD was doing at the time. Was the Package Editor running? Was it connected to the MUD and running scripts? These kind of problems are going to be the hardest to track down, so I'm going to need as much information as you can possibly provide. Otherwise there just anything I can do about it, and that would make this thread worthless.

Wizard Joined: 14 Aug 2004 Posts: 1269

In my lockups I was connected to the MUD and I had the Package Editor open, I'm fairly sure. Other than that I wasn't doing anything, except for the time it locked up when I opened Preferences.

Apprentice Joined: 12 Jul 2004 Posts: 190 Location: Canada

I've been getting lockups quite often, sadly. Nearly every time, the Package Editor was open, though it locks up while I'm doing different things. My most recent lockup occurred just after I hit "Save Changes" on an alias. Other times it happens when I click from one alias to another to edit. Unfortunately with processor lockups there's no crash report dump to send :(

Apprentice Joined: 12 Jul 2004 Posts: 190 Location: Canada

Another lockup - in Package Editor, editing an alias, hit Ctrl+S out of habit to save, instant lockup.

Posted: Fri Sep 07, 2007 7:21 pm

Does it happen each time you use Ctrl-S, or is it intermittent? I didn't have any problem here with 2.03, so maybe it's fixed already. I have already fixed some critical section issues in the package editor that might have been causing lockups.

Apprentice Joined: 12 Jul 2004 Posts: 190 Location: Canada

It's definitely intermittent. I've used Ctrl+S before without a problem, and most times it isn't an issue... I've just had "Save Changes" and Ctrl+S lock-up 4 times while editing this one alias... so I am beginning to think it may be a problem with the alias, its surrounding class, or its package in some respect.

I don't know if I should start another thread on this one, but I jsut got another really weird bug. I was in one of my session windows, just interacting with the mud normally, not even sure that I did anything that triggered an alias or anything, when all of a sudden, both my session screens went black (as if I'd used #CLS, though I have absolutely nothing in any script that executes that) and no longer received any incoming text. Outgoing text still worked fine (this was confirmed by sending a command that interacted with my wife, who saw the action on her screen next to me), but no text came in on either session screen. Disconnect/Reconnect didn't affect it. Closing the session and re-opening had no affect. Had to restart CMud.

Apprentice Joined: 12 Jul 2004 Posts: 190 Location: Canada

[Now using 2.03Beta]
Ahh, alas, with the Version History listing for 30-second timeout freeze-detection I'd hoped this would approach resolution. While working in one of my two connected sessions, (and having the Package Editor open, but rolled-up), wasn't doing anything particular with scripts, just chatting (though my chat was being filtered to capture windows), was mid-line typing something in the Command Line and CMud locked-up completely. Waited 30s, no change, hit Esc, no change, waited more... no change. Checked Task Manager, it's not locking up the processor (showing 0% processor usage from Cmud), but the program is completely non-responsive.

Wish I could give you more to work with :(

Posted: Mon Sep 10, 2007 10:07 pm

Looks like the freeze detection only works if no messages get processed for more than 30 seconds. Since the WaitForMultipleObjects that I'm using to wait for thread completion *does* allow Windows messages, I think this prevents the freeze detection from working.

It would definitely be interesting to try and determine if the problem is caused by the Package Editor or not. Even if it is rolled-up, it is still operational, so you might try closing the settings editor more often to see if that makes any difference.

The 0% CPU usage means that CMUD is waiting for a critical section lock that isn't being released somewhere.

Wizard Joined: 14 Aug 2004 Posts: 1269

BTW, even though CMUD is not using visible amounts of CPU, it is still context switching - I can see that in Process Explorer.

Posted: Tue Sep 11, 2007 12:00 am

Yep. I think that is what Windows does when it's waiting on a critical section or when using the WaitForMultipleObjects API routine.

Posted: Tue Sep 25, 2007 7:22 pm

Bumping this topic. I asked above if the lockup problems only occur when the Package Editor is open (or minimized). Please let me know if you still have lockups when the settings editor is completely closed.

Apprentice Joined: 12 Jul 2004 Posts: 190 Location: Canada

I can't offhand think of a lockup that has occurred with the Package Editor closed... but I have had my main screen go completely blank, and while it is still RECEIVING text, it simply isn't displaying anything... not even local echo of commands (successfully) sent.

Posted: Wed Sep 26, 2007 5:06 pm

When the screen goes blank, does clicking on the screen cause it to refresh? Does ESC fix it?

If you find a case where the screen goes blank, try typing the #THREAD command to display a list of threads. Then do whatever is needed to display the text (press ESC or whatever) and report what the #THREAD command showed on the screen if there is any way to see it.

Another trick that you can try when the screen is blank is to type:

#TEST crash

This is a special internal debugging command that will force a crash dump. The crash dump might contain information about what other threads are running that might help figure out what's causing this.

Apprentice Joined: 12 Jul 2004 Posts: 190 Location: Canada

Nothing I've tried has made anything appear on the blank screen... even #ECHO. None of my capture windows are receiving text either, though none of them are blanked-out. I'll try #TEST next time it occurs.