 |
ragautier
Beginner
Joined: 11 Aug 2007
Posts: 29
|
 Posted: Mon Aug 27, 2007 11:42 pm
cMUD 2.01 Freezes on #trigger execution
|
I have an Acer Aspire 5670 dual-processor 1.86 Ghz CPU, 2GB RAM.
I downloaded and installed cMud 2.01 and connected to my MUD.
I have a #trigger that executes when I get a 'experience received' message.
It then attempts to execute the following:
1
3
2
which are all quick aliases on the MUD for getting all from corpse, saccing it and putting away my gold.
The numbers never show up on the screen like they did in cMUD 1.34. cMUD locks up and won't respond. The commands are never sent to the MUD.
I relogged in, and tried what Zugg suggested in another post - hitting ESC does unlock cMUD to where output is displayed and I can input commands.
I can replicate this with ANY #trigger that I have, including one that merely does #NODIR; #ABORT 1;
cMUD locks up on the execution of any #trigger. |
|
|
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Mon Aug 27, 2007 11:49 pm
|
Firstly, does this problem happen with new triggers created in a blank session? If yes, try reinstalling CMUD afresh and seeing if that fixes it.
If not, that means it's specific to your package and some kind of corruption that happened in an earlier version. Zugg can probably analyse the problem better if you send him the file. |
|
|
|
|
ragautier
Beginner
Joined: 11 Aug 2007
Posts: 29
|
Posted: Mon Aug 27, 2007 11:56 pm
|
Additional info:
I created a new session, connected to the same MUD, established triggers by hand (#TRIG command) and they worked fine.
I then connected to the previous session (after having it fail in that session previously), and that session's triggers are now working fine.
I will continue to try to duplicate the problem, but as of now I cannot. |
|
|
|
|
ragautier
Beginner
Joined: 11 Aug 2007
Posts: 29
|
Posted: Tue Aug 28, 2007 12:13 am
|
Just reconnected with the same package that was working moments ago.
Fired an alias upon connecting (that worked during the first connection) and got the same 'hang'
The alias is a mere speedwalk such as (abbreviated:)
n
w
w
5
pra
wear ranger
wear ranger
e
e
Once the lockup occurs, any subsequent scripting locks up cMUD, with ESC 'freeing' it up. |
|
|
|
|
ragautier
Beginner
Joined: 11 Aug 2007
Posts: 29
|
Posted: Tue Aug 28, 2007 12:12 pm
|
More information:
1. The same package works fine on the same MUD with cMUD 2.01 loaded on a single processor CPU (another machine)
2. Setting the affinity of cMUD.exe on my dual-core machine to a single CPU while running did NOT fix the problem. |
|
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
Posted: Tue Aug 28, 2007 4:25 pm
|
I tweaked around with this in a blank session using this code entered into the command line
| Code: |
#VAR Test "#ALIAS Bad {"
#LOOP 1000 {Test=%concat(@Test,%i,%crlf)}
#EXEC {%concat(@Test,"}")}
#UNVAR Test
#ONINPUT {%d} {#SHOW %trigger}
#LOOP 100 {#SHOW %i;bad} |
The results were:
1. occasional lockups (ESC would work to free it)
2. #SHOW stopped working
Sometimes #SHOW would fail right from the start.
3. clicking X to close while the script ran did not work
3a. next lockup the close click would register and go.
4. pressing ESC multiple times while the script ran would queue them up and recover from multiple lockups
A small delay was noticeable to mark each lockup.
5. memory usage seemed to keep going up well after the scroll back buffer should have been full
This was determined by using a blank session and CTRL-Qing until the memory didn't change then noting the values for future testing.
6. once going the thread count remained constant, threads are being reused as expected
This doesn't rule out the possibility of the reused thread having its data state damaged from previous use.
7. these behaviors do not exhibit without the trigger in there.
Testing without the trigger, the scrollback buffer reached a full state and then speed increased. No lockup noted through the entire cycle. Memory usage also held steady once the scrollback was full. I couldn't check to see if #SHOW had failed, since it was beyond the scrollback. |
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
 |
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
Posted: Tue Aug 28, 2007 4:47 pm
|
A second test scenario shoed even more interesting results. For this scenario I did the following steps. Opened Task Manager (CTRL-SHIFT-ESC). Launched CMud. Presed ESC to close the Sessions window. Pasted this code into the command line
| Code: |
#VAR Test "#TRIGGER {Bad} {"
#LOOP 1000 {Test=%concat(@Test,%i,%crlf)}
#EXEC {%concat(@Test,"}")}
#UNVAR Test
#LOOP 100 {#SHOW %i Bad} |
Noted which was the main CMud process, and pressed enter.
The script would flash through the 1000 commands then stop. The process would be pegged at 98 to 99% CPU for a while then drop to 0 on its own. This actually shows the loop is going and finishing, but the display is lost. After letting the cycle run I tried "#SHOW Hello" from the command line and got nothing, with no way to recover it. |
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
ragautier
Beginner
Joined: 11 Aug 2007
Posts: 29
|
Posted: Wed Aug 29, 2007 12:07 am FOUND IT!
|
The trigger that would cause this disconcerting problem is this.
#TRIG {^Alas, you cannot go *} {#NODIR; #ABORT 1;}
I removed the ABORT statement from this trigger and am now using my session without any problems. I believe this is what caused cMUD to go into 'Im crazy' mode. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Wed Aug 29, 2007 8:21 pm
|
I've added this to the bug list, and will also test Vijilante's examples to see what I can find.
|
|
|
|
|
|
|
|
