Crashing

Posted by Dontarion on Fri 08 Oct 2010 04:57 PM — 26 posts, 98,146 views.

USA #0
I can't remember what version I was on, .53 maybe, but I upgraded to both .63 and .64 and had problems on both.

It seems like every time I am in combat situations I crash. Unfortunately the crash also takes out a portion of my logs so I can't tell what's causing this. If the coding isn't in the trigger, highly unliking, it is in Lua .lua files.

Any suggestions and has anyone had this issue yet?
USA #1
Can you tell us more about your computer? What OS? 32-bit or 64-bit? What plugins are you using?
Amended on Fri 08 Oct 2010 05:03 PM by Twisol
USA #2
I'm on Win7 32 bit. Nothing about my coding or plugins has changed since upgrading. Everything was fine before.

Plugins your rift, elixsum, Nick's mapper with upgrades and wholist merged into it, and Worstje's prompt fix.

I'm trying to pinpoint what's causing the crashes still but I haven't yet. However, it's bad enough that I can't do anything in Achaea combat related or I crash (crash not infinite loop). I've had it crash on priests and monks, as well as others, so I'm thinking it's in the Lua and not from triggers firing.

It's also having some weird bug about saving things this time around. I'll make alias changes and it won't save from session to session sometimes even with it setup to save even with variable changes. MUSH used to ask me if I wanted to save with variable only changes and now it doesn't -- something changed here or a bug?
Netherlands #3
Can you narrow it down any? E.g. disable or remove your plugins, and add them back in one by one to see if any of them cause the crash?

Once we know that, we might be able to figure out what those plugins do that causes the crash, and try to fix whatever bug MUSHclient suffers from.
USA #4
Worstje said:

Can you narrow it down any? E.g. disable or remove your plugins, and add them back in one by one to see if any of them cause the crash?

Once we know that, we might be able to figure out what those plugins do that causes the crash, and try to fix whatever bug MUSHclient suffers from.


I can't do that because I haven't even narrowed down what is causing the crash yet. It doesn't seem to be anything specific in combat and the logging doesn't show anything of like the last few seconds of combat before the crash.

I've tried having people hit me with things to recreate this but I've failed with that so far. Once I discover what is causing the crash I'll try to find the source.
USA #5
Dontarion said:
I can't do that because I haven't even narrowed down what is causing the crash yet. It doesn't seem to be anything specific in combat and the logging doesn't show anything of like the last few seconds of combat before the crash.


Import this:
<timers>
  <timer enabled="y" second="0.10" offset_second="0.00"    send_to="12"
>
  <send>if IsLogOpen() then
  FlushLog()
end</send>

  </timer>
</timers>

It will flush the log to disk every 100ms. Obviously this isn't optimal for real gameplay because it'll slow things down a lot, but it'll be really useful for debugging.
Australia Forum Administrator #6
Every 10th of a second might be overdoing it. Probably every second or every 10 seconds. However the log might not tell you much.

Try going back to 4.61 - this was the version before the major code revamps. Possibly something related to plugins is doing it, as they were one of the major changes.

Try turning off MCCP - in case compression is responsible (in the Output configuration, check "Disable compression").

(Do these one at a time so we can work out which it is).

If the problem has NOT gone away with version 4.61, try working backwards in versions until it does (bisecting if you like, so if you were on 4.53 try 4.58, and then go up or down depending).

I'm guessing it is the changes in 4.62/4.63 because they were major and have been out for a comparatively short time. To try to isolate which change, see if you can remove half your plugins, and see if the problem goes away. If not, try the other half.

I know some plugins interact so it may not be possible to remove them one by one, but at least we should be able to say it is caused by one or two in isolation or together.
Australia Forum Administrator #7
Twisol said:

Obviously this isn't optimal for real gameplay because it'll slow things down a lot, but it'll be really useful for debugging.


Slowing things down might stop the problem if it is some sort of race condition.
USA #8
Compression has already been disabled.

My plugins don't talk to each other except your mapper and ATCP plugins. I didn't upgrade to the ones that came with the install either because I've changed the mapper so much that it wasn't worth it. However, it shouldn't be either of these plugins because I'm getting crashes when people attack me not when moving rooms.

I only ever die when I'm being attacked in a room. No other time am I being killed. None of my plugins deal with any of these situations at all so unless there is something real odd in the upgraded MUSH the plugins shouldn't be the cause.

I haven't made it happen in someone just messing with me yet but I want to get a monk to combo me for a while.
Australia Forum Administrator #9
The fact that is uses plugins at all, and that the upgrade changed the way plugins are traversed, could be the cause, regardless of whether you changed the plugins or not.

When you have time, if you can try my suggestions of going back to an earlier version, and disabling various plugins, that might help narrow it down.
USA #10
I haven't had time to do any of that but I have realized that I only crash when being stunned. I think it's only when the system doesn't recognize that I'm actually stunned. This never was a problem before.
Australia Forum Administrator #11
MUSHclient doesn't know you are stunned, per se, so it must be something a plugin does when you get stunned. If you can isolate it down a bit (eg. what happens in the plugins when you get stunned) that would be good.
USA #12
From talking in game, I gather that 4.61 is not affected; it doesn't only happen when he's stunned; and it does not happen when just walking around, but does happen when bashing.
(MUSHclient Users): You say, "Have you tried it with no triggers, no aliases, no plugins?"
(MUSHclient Users): Dontarion says, "Tried what, going into shallam and get shanked? No."
(MUSHclient Users): Dontarion says, "I've tried having people trigger it in Mhaldor but nothing worked."


It hasn't affected me, but then I don't do combat much at all.
Australia Forum Administrator #13
There were so many changes in version 4.62 it is hard to know where to start looking. Major source reorganizations might have caused an important line to be omitted, or things might work in subtly different ways, as was demonstrated with the problem with the Chat system callbacks.

What might work is this:

  • Use a version that does *not* crash (eg. 4.61 or whatever is required)
  • Turn on logging of everything (without adding stuff like preambles) so we have a record. Consider using "raw" logging which logs everything as received, including colour codes etc.

    The suggested alias below assumes a raw log - this will retain the colours and other codes which might be causing it.
  • Try to do the things that would cause a crash on a later version. (eg. get into combat, get stunned etc.)
  • Turn off logging and go back somewhere safe
  • Switch to a more recent version of MUSHclient, one that crashes.
  • Replay the log file (see alias below) - hopefully the logged input will reproduce the crash. If so, start up the client again and start removing plugins until the crash goes away (replay the log file each time)
  • If possible, cut the log file into pieces and replay each piece to try to work out which bit of input causes it.


This method should let you work out what is causing the crash without actually having to die in combat due to a client crash.


Alias to replay a log file (type "replay_log")


<aliases>
  <alias
   match="replay_log"
   enabled="y"
   send_to="12"
   sequence="100"
  >
  <send>

fname = utils.filepicker ("Choose log file to process" )

if not fname then
  return  -- cancelled dialog
end 

-- open log file
f = assert (io.open (fname, "r"))

-- read all into memory
s = f:read ("*a")

-- close log file
f:close ()

-- push through as if it were typed in

Simulate (s)

 </send>
  </alias>
</aliases>

Amended on Tue 26 Oct 2010 03:21 AM by Nick Gammon
USA #14
Darn... that's brilliant. :|
Amended on Tue 26 Oct 2010 03:57 AM by Twisol
Netherlands #15
Could be even more brilliant if there was some sort of timestamps plus Simulate()ing at the proper intervals going on.

I can imagine this one messes up scripts that depend heavily on timers with regards to commands (not) going through, sending them into a possibly inconsistent state compared to the original.
Australia Forum Administrator #16
Absolutely, but if we can reproduce it without timing-critical stuff it will make it easier, to say nothing of easier to set up the test.

If nothing goes wrong, then that suggests that it *is* timing critical.
Australia Forum Administrator #17
Dontarion said:

I'm on Win7 32 bit. Nothing about my coding or plugins has changed since upgrading. Everything was fine before.


Do you by any chance have any plugins that use Python? There have been some other posts recently about crashes involving Windows 7 and Python.
Netherlands #18
In the worst case, I have a ~5 year old plugin to offer that has several thousand triggers, passive threading and so forth - only issue is it probably doesn't really work anymore on the game it was made for.

But that's only if you can't find something simpler to test with. ;)
Australia Forum Administrator #19
Does it crash?
Netherlands #20
Nick Gammon said:

Does it crash?


I haven't had issues with any crashing in Python in years. Last time I had that issue was with the not returning ints from callbacks, so no, I don't have issues.
#21
I got crash a lot as well with version 4.61. Now I switch to old 4.44, and it's good. Guess related to some changes from 461.
Australia Forum Administrator #22
The latest version is currently 4.70. This may fix the crashes, maybe not.

I would be grateful if someone can create a minimal configuration that crashes (that is, narrow things down to a particular plugin, or group of plugins).

Then I could reproduce that under the debugger and work out what is going on.

If that isn't possible, at least please upgrade to version 4.70 temporarily, then use the debug "summary" plugin to list what plugins (and other stuff) you have, and post that here.

Template:summary

Please provide a summary of your world configuration:

  • Either use the scripting Immediate window (Ctrl+I) to execute: Debug ("summary")

    or

  • Install the Summary plugin (see "Summary" feature) and type "summary"

Then copy the resulting information from the output window, and paste into a Forum message.

You need version 4.55 onwards of MUSHclient to do this.



Do this before the crash, but after loading the world file and any plugins you usually use. Also report whether or not it crashes, and roughly under what circumstances (eg. immediately you connect, during combat, when you exit the world, that sort of thing).

Then if it still crashes downgrade back to version 4.44 while we try to work out what it might be.
USA #23
Started playing again.

Just some information before I upgrade:

I am running the exact same setup on a Win XP desktop and a Win 7 laptop - both were installed but I use a flash drive to keep both up to date regarding world files and script.

Win XP never crashes. Win 7 crashes all the time in combat.

I'll upgrade in a minute and let you know what happens.
USA #24
Removed all plugins, upgraded MUSH and it still crashed.

So everytime I was stunned I would crash. I used this to try and figure out the cause of the crash. I put in the short timer to flush the log, changed logging to raw, added your alias.

I tried to crash the client and it wouldn't crash. I added plugins and still no crash.

I don't know what happened. I'll see if I can duplicate it another way.

I've changed logging back to the original settings and removed the timer for now.
Australia Forum Administrator #25
This thread was continued here:

http://www.gammon.com.au/forum/?id=11117

The upshot was that a trigger which turned text bold was responsible. Further testing indicated that this only applied to certain fonts, amongst which were Courier and Arial.

A couple of suggested fixes:

  • As a work-around, turn off Font -> Show -> Bold in the Output world configuration.
  • Use other fonts, for example, Dina.
  • Problems with fonts have been reported by other Windows 7 users (nothing to do with MUSHclient). Some have suggested replacing the problem fonts with copies from another computer.


I'm not sure this is a MUSHclient bug. For the same world and configuration to work under Windows XP, and then switching to Windows 7 causing the problem appears to suggest a Windows 7 issue.

Also, no-one else has reported this. I should point out that a Google search for:

"windows 7" +font +crash

... produces about 17,200,000 results.