Zugg Software :: View topic

Posted: Mon Apr 07, 2008 5:21 pm

Hmm, thanks for the good log files for this. Looks like CMUD still isn't handling packet boundaries within IAC sequences properly. I think my fix for this might have come "undone" when I was trying to kludge the code to handle those bad MUDs that were sending SE without the IAC. I'll put this back on the bug list.

Magician Joined: 17 Apr 2005 Posts: 496

I've been getting bleedthrough a lot, too. [2.22] I don't mind when it's just a little, but lately I've been getting a lot of the kind that starts with È, which is inevitably accompanied by a program error window and usually a sudden drop in HP as I try to click to get the window to go away so I can get back to entering commands and not dying. It definitely seems linked to large amounts of text being parsed, as it never happens when I'm just sitting around resting.

Posted: Tue Apr 08, 2008 12:37 pm

This might or might not be the same mechanism... if there's more than one case I want to be sure to get them all. Here's another example:

7700h, 8107m, 33900e, 30548w cexkd-
7700h, 8107m, 33900e, 30548w00 M:8107/8107 E:33900/33900 W:30548/32400 NL:0/100 cexkd-
7700h, 8107m, 33900e, 30548w cexkd-

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

All the recently posted examples seem to just be the packet boundary issue, and I think Zugg can track it down from here. Smile

Posted: Tue Apr 08, 2008 4:27 pm

Just tryin' to be thorough Wink

Posted: Thu Apr 24, 2008 10:26 pm

Found it. Should be fixed in v2.23. It was actually a nasty bug that could also cause a slow memory leak in CMUD. Not a "real" memory leak (something that can be caught by my debugging tools), but a case where an internal list in CMUD could keep growing and growing for each line processed from the MUD. And that could definitely lead to other problems. So this was a good one to find.

Posted: Thu Apr 24, 2008 10:42 pm

Bah, posted this to the wrong ATCP Bleedthrough thread. Anyway:

Found it. Should be fixed in v2.23. It was actually a nasty bug that could also cause a slow memory leak in CMUD. Not a "real" memory leak (something that can be caught by my debugging tools), but a case where an internal list in CMUD could keep growing and growing for each line processed from the MUD. And that could definitely lead to other problems. So this was a good one to find.

Posted: Fri May 02, 2008 12:18 pm

Still showing bleedthrough in one case for 2.23:

7700h, 8107m, 33900e, 19886wChar.Vitals
H:7700/7700 M:8107/8107 E:33900/33900 W:19886/32400 NL:0/100 cexdb-
7700h, 8107m, 33900e, 19886w cexdb-

Posted: Sat May 03, 2008 3:18 pm

Another Example, may be the same, maybe not:

For more information, type AB RIDING <ability>.
7700h, 8107m, 33900e, 29255wW:29255/32400 NL:0/100 cexdb-

Beginner Joined: 26 Apr 2007 Posts: 29

Indeed, still experiencing same issues in 2.23.

Posted: Mon May 05, 2008 5:28 pm

Sigh. Added to bug list again. I'm not really sure why this is continuing to cause problems.

Posted: Mon May 05, 2008 9:27 pm

Are you pressing any macro keys or running any triggers that might be trying to write anything to the screen at the same time? Perhaps the Script Debugger window would show more information on what is happening here.

Unlike the previous versions where I was able to reproduce this, my attempts to reproduce this in v2.23 have failed. Here is the test that I tried to use to replicate this:

Beginner Joined: 26 Apr 2007 Posts: 29

It typically happens when you receive a big chunk of text.

Posted: Tue May 06, 2008 2:41 pm

Same here, typically when there is a lot going on text wise.

I can't seem to get it to occur at the moment, it seems to come and go at times. I even tried converting the second text sequence I listed, but to no avail.

Posted: Tue May 06, 2008 6:30 pm

At this point I'm not sure what to do. I cannot find any way to reproduce it, so that chance of getting this fixed in v2.24 is very slim unless someone comes up with more information or another idea.

My best guess is that you have a trigger or script running at the same time that is trying to output something to the screen at the same time that it is in the middle of processing the ATCP packets. I tested this using:

Posted: Wed May 07, 2008 4:33 pm

Last chance to get this one fixed. If nobody else has any additional information on how to make this happen and nobody posts any additional detail from the script debugger, then this one is going to get put on the low priority list and won't be fixed in the public version.

Posted: Sat May 24, 2008 2:17 pm

I'm going to call the original issues fixed and start a new thread for the subsequent bleeding issues seen.