This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

MUSHclient crashing

Posted by Aznvt33 on Sat 26 May 2007 11:59 PM — 18 posts, 79,269 views.

Aznvt33 #0
I have no idea why it's doing this, but MUSHclient crashes every time I add a trigger like this:

<trigger
 match="\b(@!Enemies)\b"
 regexp="y"
 repeat="y"
 expand_variables="y"
 ></trigger>

Not sure if the format is right since I typed that in manually, but the idea is that i have regular expression, repeat on same line, and expand variables checked. The trigger is supposed to match the variable Enemies, and highlights all the names in that variable (which is listed as person1|person2|person3|etc).

Like I said before I have no idea why this trigger would cause MUSHclient to crash. It was working before, I used it for about a week.

Any ideas?
Nick Gammon Australia Forum Administrator #1
Quote:

Not sure if the format is right since I typed that in manually ...


Why do that? Can you copy the actual trigger please? See:

http://mushclient.com/copying

I tried what you posted there and it didn't crash.

  • Which version of MUSHclient are you using?
  • Does it crash as you create the trigger?
  • Does it crash when any data arrives (ie. when it attempts to match).
  • Or does it crash when a matching line arrives?


If you post the actual trigger and answer those questions it will make it easier to help work out what has happened.
Aznvt33 #2 

  <trigger
   custom_colour="14"
   enabled="y"
   expand_variables="y"
   match="\b(@!Enemies)\b"
   regexp="y"
   repeat="y"
   sequence="90"
  >
  </trigger>


That's the trigger to highlight the names, which are stored in the variable Enemies using this trigger:


  <trigger
   enabled="y"
   group="Multi Line"
   lines_to_match="2"
   keep_evaluating="y"
   match="Enemies of The City of Cyrene\:\n(.*?)\Z"
   multi_line="y"
   regexp="y"
   send_to="12"
   sequence="100"
  >
  <send>x = "%1"
result = string.gsub (x,", ","|")
SetVariable ("Enemies", (result))</send>
  </trigger>
Shaun Biggs USA #3
What I would personally do is label the highlighting trigger "highlight" and put this in the send of the other trigger:

SetTriggerOption ("highlight", "match", "\b("..string.gsub ("%1",", ","|")..")\b" )

gets rid of those extra x= and result= statements, and allows a change of what to match without trying to use entities.
Nick Gammon Australia Forum Administrator #4
Quote:

That's the trigger to highlight the names ...


You haven't answered my questions, like which version you are using, or when the crash occurs. Maybe it is fixed in the latest version.

It doesn't crash when I try it.
Aznvt33 #5
Hmm it's working now for some reason. However, I think the number of names to be highlighted might have caused the client to crash. The trigger works with city enemies (400-ish names) and house enemies (78 names) but not with citizens (1000+ names).
Ked Russia #6
I can confirm the crash. This is on version 4.07, and the crash seemingly happens due to the highlighting trigger, when used with a very long list of names (1035 to be exact). The debugger gave:

Unhandled exception at 0x00500068 in mushclient.exe: 0xC0000005: Access violation writing location 0x00000000.


EDIT: To actually answer the questions.

# Which version of MUSHclient are you using? 4.07


# Does it crash as you create the trigger? No

# Does it crash when any data arrives (ie. when it attempts to match). No

# Or does it crash when a matching line arrives? Yes. It actually crashes after the matching line is fully displayed along with the following prompt, after a short delay.
Amended on Mon 04 Jun 2007 04:53 PM by Ked
Ked Russia #7
The problem disappeared after I split the list of names into several smaller lists and created a separate trigger for each. So it most likely does have to do with the number of branches in the regular expression.
Nick Gammon Australia Forum Administrator #8
OK, I'll try to reproduce that. Without giving me the exact list, is it something like this?


Enemies of The City of Cyrene:\n (a|b|c|d ... and so on for 1000 names ... zz1|zz2)\Z

Aznvt33 #9
I just have the names put into a variable:

<variable name="citizens">Person1|Person2|Person3|etc.....</variable>

and match it with this trigger:

  <trigger
   custom_colour="14"
   enabled="y"
   expand_variables="y"
   match="\b(@!citizens)\b"
   regexp="y"
   repeat="y"
   sequence="80"
  >
  </trigger>
Nick Gammon Australia Forum Administrator #10
I can reproduce the crash, but it isn't clear exactly what is causing it.

Certainly, the match on a very big set of alternatives is responsible. With my test, and running in debug mode, I get an error message dialog box along these lines:


Failed: internal error: overran compiling workspace at offset 8067


This error message raises a whole heap of questions ...

  • The PCRE code which generates it is testing for an overrun of a field which is 4096 bytes long - this seems like a large overrun to me (8067 compared to 4096).
  • The comments in the PCRE source say:


    The regex is partly compiled into this space, but the compiled parts are discarded as soon as they can be, so that hopefully there will never be an overrun. The code does, however, check for an overrun. The largest amount I've seen used is 218, so this number is very generous.


    Thus, the usage of over 4096 bytes, when the PCRE author expected no more than a couple of hundred, is strange.
  • Why does the error message not appear in the release version, instead causing a crash? When running under the debugger I don't get the crash.


As a work-around for now, I would break the trigger down into smaller ones as far as practical, while I research this.
Nick Gammon Australia Forum Administrator #11
I can reproduce the error about overrunning the workspace completely independently of MUSHclient, so I have submitted a bug report to the PCRE developer.

It is possible the the error, when it occurs, is corrupting MUSHclient's memory, thus causing a crash.
Ked Russia #12
The crash also doesn't occur if the long list is broken up into several smaller lists which are then used in a single regular expression, like this:

\b(@!Citizens)|(@!Citizens2)|(@!Citizens3)|(@!Citizens4)|(@!Citizens5)\b


Maybe this will shed some additional light.
David Haley USA #13
Quote:
Why does the error message not appear in the release version, instead causing a crash? When running under the debugger I don't get the crash.

Maybe different preprocessor flags are set in debug and release. It wouldn't surprise me if the debug version has some sanity checks thrown in, and the release version is "optimistic" and just assumes it will always work.
Nick Gammon Australia Forum Administrator #14
I have a response from the PCRE developer, that he did not expect anyone to supply 1000 alternatives, and advises that doing so is very inefficient.

However he has made a change to the way it works, and this change will be incorporated in MUSHclient 4.08.

I am inclined to agree with him, that if you are trying to match on a short line, and colour the various words in it if they happen to be a certain name from a very long list, it is probably better to match the generic form of the line (eg. "You see xxx standing here") omit it from output, and then redraw it by checking each word in it with a script. You could look up a list of names in a Lua table very efficiently, as that would be a "keyed" lookup.

The problem with the original trigger (at the start of the thread) is that for every line received, it will break it down into words, and then for every word, the regular expression matcher has to consider 1000 or so alternatives. This must necessarily take a while. For example, a 20-word room description therefore looks up 20 X 1000 alternatives.

Once you have version 4.08, the crash should go away, and if the speed is acceptable, well and good, but I would consider doing it differently.
Nick Gammon Australia Forum Administrator #15
Quote:

It was working before, I used it for about a week.


I presume the list got longer. :)

The breakeven point if until you get version 4.08 is around 800 names (4096 / 5).

As a work-around, use a number of triggers, where each one is limited to less than 800 names.
Thalir #16
Quote:
You could look up a list of names in a Lua table very efficiently, as that would be a "keyed" lookup.


May I ask for an example, as to how a highlighting trigger can use the names in a lua table?
Nick Gammon Australia Forum Administrator #17
Rather than trying to make a regexp match thousands of names, match a wildcard, and look it up, like this:



<triggers>
  <trigger
   enabled="y"
   match="\b(\w+)\b"
   regexp="y"
   repeat="y"
   send_to="12"
  >
  <send>

enemies = enemies or 
  {
  nick = true,
  david = true,
  fred = true,
  }

if enemies ["%1"] then
  -- we found a match
  Note ("matched on %1")
end -- if

</send>
  </trigger>
</triggers>


This is a simple example, but it matches on any word, and inside the script you look up the word in a table ('enemies' in this case). Now this can't be used to colour the words individually, so if that is your intention, you might omit the whole line from output and then redraw it with recolouring.

This can get a bit fiddly, so if you merely want to colour the names of your enemies (all 800 of them?) then the original idea should be OK, since the later versions won't crash on the regular expression.