Zugg Software :: View topic - [2.03] CMUD screen stops displaying MUD output

Posted: Wed Sep 26, 2007 10:20 pm

I'm posting this thread myself because it seems to be a major issue that was talked about in the "unconfirmed lockups" thread. I think I have reproduced this myself. If I first type the following command in a blank session:

Posted: Thu Sep 27, 2007 12:24 am

Confirmed. Definitely something weird going on there. I got an error when I did I submitted.

At first #show didn't show anything, so I ran the loop again and that cause the error. @a does have a value, and oddly enough #ECHO does show the value though.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Did you ever get a chance to test the 2 scripts I posted way back with the 2.01 version in this topic http://forums.zuggsoft.com/forums/viewtopic.php?t=28129

They had the same type of thing happening where the display would become lost. Although neither had the simple elegance of your test method.

Posted: Thu Sep 27, 2007 4:47 pm

It's probably similar to what Vijilante posted, but I got sidetracked by the #ABORT command in that post and never tested the script again after #ABORT was fixed.

Posted: Thu Sep 27, 2007 9:39 pm

OK, I think I might have found this one. When processing Windows messages while waiting for a thread to finish, it was trying to prevent network messages from being processed. Instead, it was preventing other "user-defined" messages also, which was preventing several important messages from refreshing the screen properly. Also, it prevented the message sent to the window when the thread terminated from being processed too (this WaitForMultipleObjects API in Windows is pretty tricky when it comes to message handling).

Anyway, it's working now in my 2.04 version and is no longer causing screen output to stop, nor is it causing the crashes. Since it was completely screwing up message processing, this could account for a lot of other weird problems.

Posted: Thu Sep 27, 2007 10:04 pm

Well, I found another one. And I think this is the one that is actually causing people trouble. I played around a bit online and ran into it. I still haven't reproduced it, but I verified that the MUD is still sending output and the screen is just blank. In fact, it looks like everything is still being displayed, but the foreground and background colors are both black, so you can't see any text on the screen. Something to do with the style system. Anyway, I'm still looking into this.

Posted: Thu Sep 27, 2007 10:38 pm

Here is something to try when your MUD output window blanks. Try typing:

#CLR

on the command line. This should clear and reset the screen. Let me know if this restores the screen output for those other people who are getting this error. It might help me track down the cause.

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

Dang, I had come back to another blank screen, but closed out before I read your last.

Here's what I tried:

I did #TEST crash, which did cause an exception, but unfortunately the send failed for the report, so you didn't get any of what I typed-out.
#ECHO and #SEND had zero effect. (Even "#ECHO %ansi(high,red) Test" failed)
My input was definitely going to the MUD.
My main window and one of my capture windows were wholly blank. The only triggers in my main session window are a bunch of capture triggers, and one #SUB trigger.
The capture trigger that feeds the blanked capture window does use a #GAG. As far as I know, none of the triggers in my main session are using any of the new threading features.

Next time I plan to be gone for a long time, I will disable the capture/gag trigger that feeds the one specific window and see if anything occurs.

Hope this helps some. Sorry I didn't see the #CLR suggestion.

Posted: Fri Sep 28, 2007 4:59 pm

What it looks like is happening is this:

1) When a line is received from the MUD, CMUD adds it to a buffer and enables a flag to prevent the screen buffer from being displayed yet
2) Triggers are run on this line
3) When triggers are done, the flag is reset so that the buffer can be updated on the screen.

What happens is that it never reaches step (3). So, the screen buffer remains completely disabled. And there is no way to reset the flag except via #CLR. So, what causes CMUD to not reach step 3? Do you have a trigger that might not finish? Do you have a trigger that might cause an error? I didn't place (3) into a try/finally trap, so any error in the trigger processing might cause it to skip this step.

In v2.04, I have the try/finally trap set up to ensure that (3) is performed. Also, I reset the update flag when you click on the MUD window. So in 2.04, just clicking on the MUD window should display the text properly again. This isn't a "real" fix...I'd still like to find out why it never gets to step (3) in some cases.

Enchanter Joined: 09 Sep 2007 Posts: 605

How much of CMUD perfomance will eat additional try/finally? Or it will be removed later, when you'll implement "real" fix?

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

I'll be leaving my screen running all day again, and see what I can determine if it hangs again. I'll try #CLR and anything else I can think of if it hangs. I can also send you my package if it will help.

Posted: Fri Sep 28, 2007 5:39 pm

try/finally doesn't have any performance impact at all. It's an exception trap so that if an exception occurs, the code in the "finally" section is still executed instead of being skipped.

I received the #TEST crash dump from Thinjon (so somehow it really did send it even though you got an error). Looks like it was stuck executing a #CAPTURE trigger in the background and was waiting for the triggers to run on the captured text before returning. This might be related to the other serious issue where Windows messages were not getting properly handled while waiting for a thread. So it's possible that the thread fix will also fix this problem in 2.04.

Wizard Joined: 14 Aug 2004 Posts: 1269

Maybe it would be worth generating a stack trace that can be submitted in this try/finally trap? Then if it happens, you might get to see why? Or maybe you are already doing that! Smile

Posted: Fri Sep 28, 2007 8:54 pm

In this case it's in a background thread, so generating a proper stack trace is much harder. The try/finally *does* allow normal exception trapping to continue, so if it's at a point where a crash dump can be generated, it still will be.

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

I REALLY hate to do this to you, Zugg... but I went out to a movie and came back to a blank screen. clicking on it DID restore the text that was there, unfortunately no new input is being displayed. #CLR also had no effect, other than to clear the text that clicking had provided.

Oddly enough, the wiznet capture window that was blank in my earlier report was not blank this time.

I'm going to execute another #TEST crash just so you have a dump with 2.04 data, but other than that I'm not sure how else I can help you track this one down.

Sorry :(

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

ROFL....

OK, I posted my last, came back to CMud, entered #TEST crash, and I'm now watching the past 3 hours of MUD input scroll through my screen (it's a TON of text, let me tell you... a 65k line buffer holds a lot :P)

I'm still going to submit the crash report, just in case there's anything there, but it appears my screen is updating normally now... commands input are executing and my main screen IS now receiving input.

One question, though. Is the sudden influx of display on my screen due to the #TEST crash command, or was there simply some delay time between my clicking/using #CLR and it starting to refresh, perhaps due to my insane buffer size? I ask because it seems odd that #TEST crash would fix it, but it coincided perfectly with my hitting Enter on that command.

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

OK, this just got weird in the extreme. It turns out that, post screen-freeze, my screen updates normally only while the "Error in cMUD.exe" window is open. I submitted my crash report, hit "Continue application" (Which I figured was relatively harmless, since /I/ initiated the crashdump, and the screen seemed fine) and suddenly my screen was frozen again. A subsequent #TEST crash provided me with another lovely refresh of the screen, and now since I haven't closed the crash dump dialog, my mud is refreshing wonderfully. I intend to leave it in this state until I get more input from Zugg on anything I can do to assist in tracking this down, as I have a means to keep the state available for entering test commands, without losing full mud functionality.

To summarize: Once my screen has stopped updating, having the crash dump window open allows it to refresh normally henceforth.

Edit: OK, the crash dump window doesn't give me perfect perpetual refresh, but it does allow the refresh for a while before it goes back to frozen again. Hitting "Continue application" and executing "#TEST crash" again resumes screen refresh

Wizard Joined: 14 Aug 2004 Posts: 1269

Fun! I feel we're making progress though.

Did you also try clicking on the command-line and back to the screen several times to see if that brought more output?

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

Tried that. No effect. Though my error window being open lasted me all night, so hopefully if Zugg sees this and needs me to do any other testing, I'll have a "pre-frozen" setup to test things on :P

Wizard Joined: 14 Aug 2004 Posts: 1269

v2.04: I was watching a film and suddenly I noticed that my laptop's fan is on full blast. CPU is at 100% and CMUD is taking it all. Nothing is happening on my CMUD windows, but I do still appear to be connected. So I press Escape and lots of text rushes past. Then CPU returned to normal. My triggers didn't SUB any of this text, but this seems to be a consistent problem (even in zMUD) when using #SUB in a trigger when text is going past very fast. No clue what caused the CPU or freeze, but an #ALARM did fire and #SAY one line to the screen during the period that my screen had stopped displaying MUD output.

The alarm is just:

Posted: Mon Oct 08, 2007 10:11 pm

Is anyone having trouble with the screen blanking out and not updating in v2.05? If you are still having this problem, reply or send me a PM with the hostname and port of the MUD you are playing so that I can try it. I need to find a MUD that doesn't auto-disconnect me so that I can leave something running overnight to try and reproduce this.

The case of 100% CPU vs 0%CPU are different problems. If you get 100% CPU and pressing ESC does something, then that's usually a problem with a background thread that is stuck. I'm more interested in the case where you get a complete hang with 0% CPU (or minimal CPU). In this case, pressing ESC won't do anything. This is caused by a problem with a CriticalSection not being released somewhere in CMUD, and about the only way to track this down is for me to reproduce it here (since it's hung and you can't get any crash dump or anything).

If I can reproduce it here by leaving it connected to a MUD with some simple settings, then when it hangs within the Delphi debugger, I can determine exactly which CriticalSection is causing the problem.

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

I'm not getting the no screen update... but my CMud is locking up solid with 0 processor usage. I connect to Aardwolf (aardmud.org port 4010) The only trigger you'd need to stay online all night is:

#TR (^You disappear into the void.$} {#CR}

In case it helps, I emailed you my package file, too.

Wizard Joined: 14 Aug 2004 Posts: 1269

I just experienced a complete lockup with 0 CPU usage. The package editor was open and I was connected to the MUD, but was actually using a different CMUD process at the time for testing offline. I think the lockup may have happened when my router went crazy and cut my link. I couldn't get the locked CMUD process to show, and it is still in this state after getting my link to the internet back.

EDIT: Not sure if this is the right thread for this, since it's really a lockup and not a case of the MUD screen stopping displaying MUD ouput. v2.05 on WinXP SP2.

Wizard Joined: 14 Aug 2004 Posts: 1269

Hmm, another lockup but no loss of link this time. Though I did have two CMUD applications open (so I suppose that is actually 4 processes) again.

Wizard Joined: 14 Aug 2004 Posts: 1269

3rd lockup (all with settings editor open), but maybe my settings have gotten screwed up by the previous End Task, since I had just realised that Tells that were captured were showing up double in the Tells window. Then I noticed that my settings were showing two Tells windows and two Narrates windows, although only one of each is visible. (Narrates aren't showing up double though.) And I remember that this time I opened CMUD, I was surprised by the fact that one of my capture windows had gained a status bar and command line. I had switched them off, but now looking at the windows in the package editor, one of the Tells windows and one of the Narrates windows was showing up as Visible, while the other one of each had status bar and command line ticked. Then I clicked on the "alarms" window setting to compare (which was not a visible window) and CMUD froze immediately.