Zugg Software :: View topic - CMUD 2.18 freeze caused by Settings Editor

Posted: Sat Dec 22, 2007 5:51 am

Repeatedly while browsing through the Editor, CMUD just hangs, forcing me to have the Vista Task Manager remove the task. No data on what is causing it since there is no program exception.

Posted: Sat Dec 22, 2007 7:56 am

One thing I've noticed with the 2.18 Settings Editor is that when certain MUD lines appear, the Settings Editor resets (some of) its pointers and if one is not looking at a particular setting but is moving the slider up and down looking for one, the Settings Editor will lose track of where it is and reset the slider. This is new, as with the previous versions of CMUD and ZMUD, the Editor would not react to the MUD output at all.

Novice Joined: 22 Feb 2002 Posts: 48 Location: Latvia

Yup, I can confirm on this issue.
I'm running it under VMware, tho it still counts as windows.

Posted: Sat Dec 29, 2007 9:21 pm

Couple of questions.

When you notice this behavior, are you online are offline? Do you have any triggers that are using background threads, the #WAIT command, #SECTION etc?
Also did you try typing Shift-Esc to see if this fixes the issue?

Novice Joined: 22 Feb 2002 Posts: 48 Location: Latvia

Hi,

No #WAIT or #SECTION or anything close to it in my settings,
didn't tried Shift-Esc, but I will try next time, although I doubt
it will do any good, as CMUD becomes unresponsive.

Posted: Wed Jan 02, 2008 8:09 pm

I've had this as well. Not much I can do from the debugging standpoint as it seems random when it freezes and requires removing it from task manager after it happens.

Also, nothing multi-threaded in my settings, no #wait, etc. On Windows XP SP2. Cmud 2.18

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

I had this today too. I don't have anything threaded yet, it was just when looking through the settings editor. Tried Shift-Esc but didn't do anything, I left it occupying 99% of the CPU for a few minutes to see if it'd sort itself out but eventually had to kill the process

Novice Joined: 22 Feb 2002 Posts: 48 Location: Latvia

Hi, just happened again and I tried Shift-Esc, but nothing happened, cmud still uses cpu by 100% and not responding to anything for the duration of 3 minutes.

Novice Joined: 18 Dec 2006 Posts: 47

I've been having this occur while trying to create a new session from an old. I'm offline, no triggers are firing, having the Package Editor open seems to be enough to cause this to happen, as I'm not always working with it directly when it freezes. I'm also running Vista.

Posted: Tue Jan 15, 2008 5:01 am

Returning to this problem because it is becoming chronic.
It happens to me always while moving the slide to locate an entry. It happens quite often now. I have found no way to get CMUD running again except by deleting the task and re-starting. It's been 23 days since I fist reported this problem and I think it has now a reached a critical point. I am hoping it is moved up the priority list.

Posted: Tue Jan 15, 2008 5:17 am

It's hard to fix a bug with no discernable cause. Unless we can find a way to reproduce the bug or isolate a single factor that's causing it, there's very little that can be done. So far you haven't described anything specific that you're doing to make the bug happen, let alone eliminating various factors (like triggers firing in the background and stuff like that). You need to provide more information.

Posted: Tue Jan 15, 2008 9:07 am

Posted: Tue Jan 15, 2008 6:15 pm

As Fang said, you need to tell us more about exactly what triggers are firing when this happens.

Posted: Fri Jan 18, 2008 11:11 am

I will try to reconstruct from my logs what was on the screen at the time this occured. However, if you want to see for yourself, just move the editor's vertical slide up and down for a while. It will accomodate you. It happens to me, at least, once a session and usually more often than that. So, as I said before, it is recreatable, just not predictable.

Posted: Fri Jan 18, 2008 1:54 pm

I can't reproduce this bug following those instructions. I opened Vijilante's Toolbox and expanded all the classes to make the treeview big enough scroll and sat for about 30 minutes wiggling my scroll wheel and watching The Unit and nothing happened. You (and/or other people experiencing this problem) need to try to narrow down the cause.

Posted: Fri Jan 18, 2008 5:40 pm

I can't reproduce it either, so it definitely related to something specific happening in your settings, like a specific trigger that is firing and causing the problem.

Posted: Sat Jan 19, 2008 10:49 am

I don't know what else is there for me to tell you. I am not doing anything different now that I was doing in the 1.34 version. One thing that does happen is that when one switches from, let's say, variable settings to triggers, the editor forgets where it is and goes back to the last setting that was active for that settings type. That might be a clue. It is defintely related to the update of the screen as the vertical slide moves. At some point, it goes into what it must be a hard loop since all threads are frozen. Perhaps, the Editor should be subtasked rather than threaded so whan it freezes it doesn't bring down all of cMUD. I have hundreds of active triggers but there is no obvious pattern to which triggers are firing when this is happening since MUD output is relatively random.

Newbie Joined: 15 Dec 2007 Posts: 7

The thread was : CMUD 2.18 freeze caused by Settings Editor
So my text was in the correct thread i think. But forget it. I will struggle and manage and pray for an update that won't crash so often.

Posted: Sat Jan 19, 2008 3:39 pm

Please post a separate thread for each separate issue. This thread's about a specific problem relating to scrolling in the package editor.

Posted: Mon Jan 21, 2008 2:23 am

Here is an update.
The freezing will also occur while working offline, so the idea that the client interaction with the MUD may be the cause of the problem has weakened.
Let me summarize at this point what I know of the problem.
The mention of the Editor losing its place was not out of place here because I think there is a connection. Let me explain.
Because I use triggers, functions, and of course, variables, with my scripts, I am in the habit having all setting types accessible during my editing rather that just one particular one. When I then decide to narrow the scope by choosing a particular setting the Editor goes away from the class folder I was working with and relocates itself elsewhere. I suspect that the relocation is related to the last setting of that type that was selected, though there are holes in this theory.
The point behind this is that while moving the slide it is possible that the Editor has lost its location entirely and goes into an infinite loop trying to place itself. The fact that the CPU activity goes to 100% is a dead give away for the infinite loop. The fact that the Editor has a problem mantaining its location is a telling point. I am almost certain, without having looked at the code, that the problem lies in this direction. MUD interaction has been eliminated (though, IMO, the Editor being a metaprocessor means that client interactions should not be affecting it).
If you can think of a debugger that can monitor cMUD while running, I will be very happy to install it.

Posted: Mon Jan 21, 2008 7:07 am

If you reckon that choosing a setting filter is part of the procedure to reproduce this problem, can you give us a step-by-step way to make it happen so I can have a go? If it's happening offline and isn't specific to your package or session (if you could check that too while testing the procedure), we should be able to reproduce it.

CMUD's copy protection probably wouldn't like any debugger that would do anything useful.

Posted: Sat Jan 26, 2008 9:31 pm

Here is something else that I painfully discovered. Browsing through the Help screen also causes the problem. Yes, the Editor was opened at the time, but if the Editor did cause the freeze, it did it without any help from me since I was looking for an entry on the Help screen.
Also, and with all due respect, you are asking me to do all this research into this problem. I am using a production version not a BETA version. In other words, my intent is to interact with the MUD, that is why I am using this client. This bug is taking enough time from the game as it is and you want me to spend time figuring out why it doesn't work without having the code in front of me. The fact that you can't reproduce the problem is no indication that it doesn't exist. There are others out there having the same problem. Perhaps, developing a simple debugger that would run CMUD as a subtask might be what this problem needs. A simpler way is to write a little program that would access CMUD after it becomes unresponsive and takes a memory dump.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Fang's not asking you to debug and fix the problem. He's just asking you to give the steps you went through before the problem occurred. With the information you've given thus far, the rest of us are unable to reproduce the problem, and if it can't be reproduced by Zugg, it can't be fixed, unfortunately. By taking a few moments out of your schedule to find a way to reproduce the problem and narrow it down, you can get it fixed much, much sooner and the bug won't take any more of your precious MUD playing time away from you.

Beginner Joined: 10 Oct 2007 Posts: 17

I am going to be very unhelpful here, because I too find it very hard to be specific about recreating my freezing problems.

CMUD was freezing for me around every three minutes when I was working on settings, often when using the slider.

I managed to cut this dramatically by replacing the following with something else.

I had an alias called herqueuealias with the code below

#var but_herbwindow_sw 0
#alarm herbtrigger +2 {herbqueuealias}
#if (@but_triggers_sw=1) {#abort 1}
checkherbqueue

As you can see the alias would call itself every two seconds, the vast majority of the time @but_triggers_sw = 0 so checkherbqueue is almost never called and so I dont think it was that part that caused the problem. I noticed the slider was flickering a bit when this routine was running in which is how I managed to isolate it as the cause of one of the many freezing problems I have.

By reducing the amount of work cmud is doing behind the editor I have cut down on the freezing alot, but it is still a very regular occurence. Annoyingly I can never reproduce the behaviour in a consistent way - sorry.

Posted: Tue Jan 29, 2008 2:06 am

It is not a matter of taking time out of my schedule. It is a matter of trying to do the impossible. As I stated before, the problem centers around the fact that CMUD is going into an infinite loop. Any one who has ever debugged a program that does that knows that there are very few quantitative steps that can be taken to pin down the problem, especially if one doesn't have the code in front of one to see what part of the program is likely to be executing at the time of the loop. Bluebear made a good point when he (I am sorry if I have the sex wrong) made a reference to the slider flickering. That reminded me that sometimes when triggers fire the settings position is lost and the active setting is changed to a previous one. Yesterday I managed to reduce the number of freezing events by making sure that nothing was being sent by the MUD when I moved the slider. This obviously relates to Bluebear's point of reducing CMUD's workload while using the Editor. There is also a new effect that I am encountering that may be related to the problem: As you know, when a setting is referred to in a script, it will show up as blue if it already exists and red if it doesn't. Lately, many of my aliases have failed and, when checked, I have found that some settings are now red even while they are existing. The only way I have found to solve this problem is by cutting and then repasting the offending setting back into its class folder. After this is done, the Editor again recognizes the setting. This may not be related to the freezing problem, then again, it may be.
I am actively working on this problem because it impacts me tremendously. I am continually writing and testing scripts. These are not idle scripts but script that I use actively, so the freezing problem has changed the way I play the game in more ways than one.
One suggestion would be on looking into the Editor's thread as see if it is being confused with another one. My idea of running the Editor as a subtask was not an idle one. If this is done, the problem could be isolated by simply looking at the status of the Editor at the time of the problem. CUMD would still be running, though a way to re-starting the Editor from the main task would have to be added. Alternatively, my suggestion of using an external debugger is one that I still think is valid.
I don't know how much those of you who haven't reproduced the problem rely on the Editor. I have hundreds triggers, close to one hundred aliases and a host of variables, not to mention dozens of functions. The point being that the size of the settings environment might be significant.