Zugg Software :: View topic

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Starting from a fresh install and a blank session I did this at the command line

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Still working on getting a crash dump procedure for item 4. I ran into a nice hangup in the attempt.

The procedure to produce a hangup is
1. Launch CMud
2. Close the Sessions window
3 Enter the command to create the alarms from above at the command line.
4 After the first 10000 is displayed press CTRL-G to open the package editor.

Once the lockup occurs it stays in a continuous hourglass state. The CMud process was pegging my processor and I gave it about 5 minutes to see if it would do anything.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I was able to get to get a crash report, but it may be erronius. The procedure to reliably produce a crash is the same as above for a lock up with one extra step. The extra step is the tricky part though, since pressing ESC cancles the crash report and continues the program. I have seen a few different crash error because of not catching the first one.

The procedure to produce a crash is
1. Launch CMud
2. Close the Sessions window
3. Enter the command to create the alarms from above at the command line.
4. After the first 10000 is displayed press CTRL-G to open the package editor.
5. Once the Package Editor hangs in its display press ESC repeatedly until crash.

This is the crash I got when I was able to catch the first crash. Second and 3rd crashes continuing the procedure had a wide variety of causes.

Wizard Joined: 14 Aug 2004 Posts: 1269

Check the bugreport.txt file in your CMUD folder - it may still get written to if you cancel the crash report dialog.

Posted: Fri Sep 28, 2007 11:38 pm

Well, that's definitely a good "horror test" for the threading system and the settings editor.

On (1), that is normal. Alarms do not create their own threads...they execute in the main thread. So the main thread is going to busy executing one alarm before it gets to the next one.

2) When you press ESC, the execution module is aborted. If anything is left on the runtime stack, it gets displayed on the screen (and probably sent to the MUD), since CMUD thinks that this was left on the stack by just putting "10000" on it's own line in the screen. For example, when you have an alias like this:

#ALIAS test {hello world}

it just puts "hello world" on the stack, and when the alias is done, anything left on the stack is sent to the MUD. So, my guess is that the 10000 from the #LOOP command argument is still on the stack somehow. I can look into trying to clear the stack when ESC is detected.

Good catch on the settings editor hang. I didn't work on the settings editor hang bug in 2.04 yet (I was focused more on the other critical problems). But this might be a good way to reproduce it and get it fixed. I can imagine that this test causes all sorts of havoc since you have so much stuff changing in the background (@a being updated and lots of alarms firing).

This is just the kind of cruel and evil stuff that we need to do to CMUD to uncover some of these bugs. I try to do testing like this myself since it tends to bring out problems that you don't normally encounter with normal MUDding.

Posted: Fri Oct 05, 2007 1:19 am

Well, this is a real killer test. It's driving me insane. But it's been really good at tracking down various CriticalSection deadlocks. There were several problems here. Mainly, I had at least one typo where I was calling "Lock" instead of "UnLock" at the end of one routine (so now the CriticalSection was always locked). Also had some problems were I had created my own CriticalSections without fully realizing that they depended upon some other system sections, and there were some deadlock conditions.

In working on this, I have also changed alarms so that they actually run in their own thread instead of in the main thread. Otherwise, when you execute the above test, you end up flooding the main thread with the computation, and within #LOOP there is no Windows message processing. So, the TreeView doesn't get updated until all of the alarms are finished.

Once I changed the alarms to threads, then at least the TreeView would update. But it appeared hung because every background change to @a was causing the tree to update/refresh itself. I fixed this and then I was finally able to run this test. I am able to click on various alarms, and I can watch the alarms disappear from the list as they are executed. Of course, having 100 threads executing a script in the background makes the whole system incredibly slow (especially with all of my thread debugging that I currently have enabled). But I think it's finally working...or at least working much better. I'll probably test this a bit more tomorrow. Right now I'm fried.

Posted: Fri Oct 05, 2007 1:30 am

I've noticed lately, then when i create an #ALARM with a #TRIGGER, more often then not it is formed outside of any module altogether (not even withing the main window), unless i specifically put it in a class.

Posted: Fri Oct 05, 2007 5:59 am

You should probably create a separate thread about that and give me the exact trigger that is creating the alarm. I haven't seen anything like this in my current testing. But it depends a lot upon the context that the trigger fires in.