Gammon Forum : MUSHclient : Bug reports : Perl-scripts dying causing MUSHclient to miss world-output?

Entire forum ➜ MUSHclient ➜ Bug reports ➜ Perl-scripts dying causing MUSHclient to miss world-output?

Perl-scripts dying causing MUSHclient to miss world-output?

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

Posted by

j0nas (56 posts) Bio

Date

Fri 12 Sep 2003 07:46 PM (UTC)

Message

I've noticed that sometimes when my perl-scripts crash, any text that come in after the crash won't be displayed once I remove the error-message displayed by MUSHc, unless I'm really fast removing the error-message.
This isn't very good, I can accept that the text on my screen isn't correct when these things happen, but I'd very much like my logs to be correct when it comes to the world-output at least, and this bug affects the log too.

It should be fairly easy to reproduce this bug:
<world-input>
aaaaaaaaaaaa
bbbbbbbbbbbb
cccccccccccc
dddddddddddd
eeeeeeeeeeee
ffffffffffff
</world-input>

<perl-script>
sub crash {
die("I've crashed!");
}
</perl-script>

<trigger>
bbbbbbbbbbbb
</trigger>

<post-trigger output>
aaaaaaaaaaaa
bbbbbbbbbbbbeeeeeeeeeeee
ffffffffffff
</post-trigger output>

As you can see, entire lines disappear, which isn't too hot. Is there a way to avoid this right now, and if not, would it be possible to implement something? (My current MC is v3.42, fyi.)

Top

Posted by Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date Reply #1 on Fri 12 Sep 2003 10:18 PM (UTC)

Message

I can't reproduce this. Using your "crash" subroutine, and sending the lines you specify, and matching on the "bbbbbbbbbbbb" line, and colouring it (and calling the script) I see this in the output window:



aaaaaaaaaaaa

bbbbbbbbbbbb

cccccccccccc

dddddddddddd

eeeeeeeeeeee

ffffffffffff

The bold line is the coloured line. So, it matched the trigger, coloured it, called the script, I got the error message, but lost no data.

I also tried sending a "say" to the crashed instance while the error message was on the screen. It appeared also.

Maybe you have a dodgy version of Perlscript? Also, what version of Windows are you running?

- Nick Gammon

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

Top

Posted by

j0nas (56 posts) Bio

Date

Reply #2 on Fri 12 Sep 2003 10:34 PM (UTC)

Message

Windows XP Pro Corp.

It is possible that you need to input more data than just the few lines I provided, and wait for that data to arrive before removing the error-message. If more data isn't enough, I'll look into duplicating the error and describing it step-by-step, allright?
My gut-feeling for this error is that something prevents MC from reading and handling new packets/data properly while the error is displayed, causing some of the older packets/data to be dropped as some buffer somewhere fills up. Is that possible?

I guess I could have a dodgy version of perl, but even if I did it seems strange that it would have this effect on MC's displaying and logging.

Top

Posted by

j0nas (56 posts) Bio

Date

Reply #3 on Fri 12 Sep 2003 11:36 PM (UTC)

Message

In a glorious new twist, I've discovered a new 'feature' I'm getting from this bug. It's displacing text in a strange fashion, it's like some of the text that comes after(in the same packet) as the text that causes the error-message will not get displayed until after I click away the error-message, while other text coming in a bit later(in another packet?) will be shown.

So the aaaabbbbccc from before might become:

aaaaaaaa
eeeeeeee
ffffffffbbbbbbbbb
cccccccc
dddddddd
gggggggg
hhhhhhhh

Right now, it's rather late over here, but if you're having trouble making sense of this issue right now, leave it until I make another post. I'll whip up a detailed step-by-step tomorrow, for clarity.

Top

Posted by

j0nas (56 posts) Bio

Date

Reply #4 on Sat 13 Sep 2003 04:08 AM (UTC)

Amended on Sat 13 Sep 2003 04:10 AM (UTC) by j0nas

Message

I've got it a perfect way to reproduce the bug I'm having now, along with a pretty good guess of what's happening. :)

Allright, so forget anything I wrote previous to this, the bug doesn't actually -loose- any text per-se, but it -displaces- the text in a strange fashion!

Allow me to demonstrate! This all takes place on a linux-box using telnet, a trick you taught me earlier I believe. :)

<main.txt>
aaa
bbb
ccc
</main.txt>

<main2.txt>
111
222
333
</main2.txt>

The trigger is on 'bbb', calls Crash, which is a sub in a perl-script.

<Crash>
sub Crash {
die("I've crashed.");
}
</Crash>

Input the following command, in one line.
cat main.txt;sleep 1s;cat main2.txt

The error will occur, but do not click it away until you've seen it output main2.txt on the screen. You will get output somewhat similar to this, after removing the error-message.

<output>
cat main.txt;sleep 1s;cat main2.txt
aaa
bbb111
222
333
j0nas@q48 j0nas $
j0nas@q48 j0nas $
ccc
</output>

This differs from the output you'd expect:
aaa
bbb
ccc
111
222
333

And I'll tell you why! It seems likely(ie, I'm guessing..) that MC takes each incoming packet, grabs the data and starts processing every full line it can out of that packet against it's triggers, and if something bad happens(the script returns an error), it pauses output to tell you this. Then, a moment later, another packet arrives, and while the output from the previous packet is still frozen, the second packet's data is processed and outputted! Then once you click away the error-message displayed, the first packet's data-processing resumes, causing it's lines to be printed after the lines contained in the second packet, thus messing up both the display and log!

I hope this helps in finding the bug, and I very much hope it's possible to fix it in a way that won't cause the text to be displayed and logged erroneously. :)
Making the error-message 'non-blocking' might be the best solution, to prevent a flood of text just being crammed down the screen once the error is dismissed, if it has been left there for say, an hour or more.

Top

Posted by

Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date

Reply #5 on Sat 13 Sep 2003 07:46 AM (UTC)

Message

I had a similar problem a while back, where if an error box was open strange things happened. What I think happens is that while the error dialog is visible the program puts it into a different thread, and then when another packet arrives from the network it calls the main processing routine, which - in your case - still has more work to do from the original packet.

I'm not sure of a sure-fire fix - considering I didn't actually write this "put it into a thread" code, but which comes with the MFC libraries that MUSHclient is written with.

However what will probably work quite well it would be to do one of these two things:

* put error messages like this into a separate place, eg. a notepad window, like is done with MXP errors; or

* put script error messages into the main output window - however this still might cause problems in the sense that you may get the error message in the middle of an incoming line.

- Nick Gammon

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

Top

Posted by

Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date

Reply #6 on Sat 13 Sep 2003 07:49 AM (UTC)

Message

It might be worth commenting that the problem goes away if you don't have script errors, so a debugged script shouldn't cause too many issues like this.

I suppose what wouldn't be too much work would be to offer the option to users:

1. Keep current behaviour
2. Use notepad window
3. Use output window

- Nick Gammon

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

Top

Posted by

j0nas (56 posts) Bio

Date

Reply #7 on Sat 13 Sep 2003 12:41 PM (UTC)

Message

Properly-debugged scripts are a sound idea in theory, but since I'm doing this in my spare time, just for the fun-factor these scripts will give me, I'm not willing to dedicate the time to really debug the scripts I make. They can end up rather complex, and I'll debug them when I see the bugs, otherwise I'll just leave it alone.

A choice of outputting the errors to a notepad-window sounds perfect. It won't be quite as readily apparent when something goes wrong, but if it's a conscious choice on the behalf of the user to get this behaviour, that won't be a problem. I would really like to see that.

The bug aside, I have to say that I've been very impressed every time I've posted questions to this board, the replies are prompt and factual. It's really very nice, and if I had to choose, I'd name that as the 'feature' that really drove me to register. :)

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.

20,332 views.

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

Go to topic: Search the forum

top