Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ Bug reports ➜ MUSHclient crashing
MUSHclient crashing

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1 2  

Posted by Aznvt33   (18 posts)  Bio
Date Sat 26 May 2007 11:59 PM (UTC)
Message
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?
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #1 on Sun 27 May 2007 05:14 AM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Aznvt33   (18 posts)  Bio
Date Reply #2 on Sun 27 May 2007 04:12 PM (UTC)
Message 

  <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>
Top
Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #3 on Sun 27 May 2007 04:28 PM (UTC)
Message
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.
It is much easier to fight for one's ideals than to live up to them.
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #4 on Sun 27 May 2007 09:06 PM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Aznvt33   (18 posts)  Bio
Date Reply #5 on Mon 04 Jun 2007 02:37 PM (UTC)
Message
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).
Top
Posted by Ked   Russia  (524 posts)  Bio
Date Reply #6 on Mon 04 Jun 2007 04:49 PM (UTC)

Amended on Mon 04 Jun 2007 04:53 PM (UTC) by Ked

Message
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.
Top
Posted by Ked   Russia  (524 posts)  Bio
Date Reply #7 on Mon 04 Jun 2007 05:20 PM (UTC)
Message
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.
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #8 on Mon 04 Jun 2007 08:46 PM (UTC)
Message
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

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Aznvt33   (18 posts)  Bio
Date Reply #9 on Mon 04 Jun 2007 11:14 PM (UTC)
Message
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>
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #10 on Tue 05 Jun 2007 02:37 AM (UTC)
Message
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

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #11 on Tue 05 Jun 2007 04:16 AM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Ked   Russia  (524 posts)  Bio
Date Reply #12 on Tue 05 Jun 2007 08:05 AM (UTC)
Message
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.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #13 on Tue 05 Jun 2007 08:58 AM (UTC)
Message
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.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #14 on Tue 05 Jun 2007 10:07 PM (UTC)
Message
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

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

55,841 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home