mudinfo.net

First off, let me plug Joker's response in the following thread - http://www.mudinfo.net/viewtopic.php?f= ... xcep#p3322

That went a long way in helping me decipher, at least a little, the data in the GALEXCEP log... now can some kind souls help me understand what may have caused it? I am specifically hung up on whether it was caused by the "" input (double-quotations) or likely tied to a rob-attempt? I pasted what I believe to be the important sections with the data that stood out to me bolded/highlighted based on Joker's post; the exception detail, input, and routines. Any insights and possible fixes would be greatly appreciated!

WORLDGROUP EXCEPTION @ 0260E873 (see "Routines" section below)
Recorded 1/2/2017 21:28:24
Access Violation. Attempt to read from: 20
AX=001C BX=0009 CX=0009 DX=0004 SI=01E5972C DI=020DFEE4
BP=0012F628 SP=0012F628 IP=0260E873 Flags=00010202
CS=0000001B SS=00000023

Online level 6, state 10, substate 130
MSG:WCCMMUD.MCV/-1
Module "MajorMUD"
Input ""

Routines:
0260E859 _already_evil < 0260E873 < 0260E89F _evil_for_robbing
025F6F5D _display_room_desc < 025F7259 < 025F76B9 _display_conversion_
0261003C _execute_input < 0261020D < 02610D5E _commands_pending
025C5104 _ljngame_sttrou < 025C88D3 < 025C88EC _handle_CHAR_input
0042240D _hdlinp < 004224E7 < 004225BB _uidxst
0041DFA7 _axschg < 0041E0FC < 0041F8D2 _fmtx3
0033C1BC __startup < 0033C2EE < 0033C3E0 __startupd
00000000 Unknown < 00000000 < 00000000 Unknown
00000000 Unknown < 00000000 < 00000000 Unknown

Was this someone trying to use the rob command on an already evil user and... poof?

Thanks again!

PM Sent regarding this issue.

Joker wrote:PM Sent regarding this issue.

Why PM?

PM sent.

Interesting, I had a crash recently and looks to to be the same debug info. Same routines where loaded. Only thing different it pointed it to a user, but had the blank input also.

Routines:
02DDEB9E _already_evil < 02DDEBB8 < 02DDEBE4 _evil_for_robbing
02DC7322 _display_room_desc < 02DC761E < 02DC7A7E _display_conversion_
02DE038C _execute_input < 02DE055D < 02DE10AE _commands_pending
02D95107 _ljngame_sttrou < 02D988D6 < 02D988EF _handle_CHAR_input
0042240D _hdlinp < 004224E7 < 004225BB _uidxst
7C2DFC2C StartServiceCtrlDisp < 7C2E02F7 < 7C2E030B RegisterServiceCtrlH
00000000 Unknown < 00000000 < 00000000 Unknown

The strange part is I haven't had a crash in over a year, and I didn't change anything and it hasn't happen again YET.

PM sent to you, as well, Bear

I got no PM

BearFather wrote:Interesting, I had a crash recently and looks to to be the same debug info. Same routines where loaded. Only thing different it pointed it to a user, but had the blank input also.

The log for our crash points to the user as well, I simply excluded that info from my post.

BearFather wrote:I got no PM

Bear, not sure if you dug into this but I did a fair amount of testing based on user feedback to try and confirm the cause specifically. I setup a couple of test characters using the test realm on my local PC; a gypsy and a warrior. I setup macros and message responses in various ways to simulate different scenarios and here is what I found...

rob / attack macro - no crash
rob / attack / forgive - no crash
rob / forgive - no crash
have some type of engagement in place (rob or attack), then flash / forgive - BOOOOOOOOOM crash

I was able to repeat this several times and it aligns with the feedback I was getting from user referenced in the log as well as users that were in the room with them when the crash happened. Both were very insistent that they DID not use the rob command but in both cases they were forgiven for something and saw the board go down right after the "gods forgiven you" message. This would seem to align with the log in that their line/userid was the source of the crash even though it wasn't related to any input from them, hence the "" near the top of the log.

Edit: just to clarify, the error log from my test conditions is an exact match to what's been posted; read from: 20, input "", and already evil from robbing.

I hope that helps and if you have any deeper thoughts please share, but on our board we've blocked off forgive and its variants along with share and its variants. We are now pretty comfortable that we are sheltered against this specific issue int he future. I am not enough of an expert on programming and the mud files to know why it has the "evil for robbing" in there, and I can't remember if I effectively isolated the flash / crash from rob or combat prior (no time to test more at the moment), but thought I'd share what I've seen so far.

so you're saying the fix for this is to basically disable the forgive command? Which I assume you did through FU globals by assigning it to global commands? If so, how many variations of "forgive" did you need to add so I can add it to the instructions?