Hi,

I've recently found out that a yabb modification is causing a posting problem on my forum. Almost randomly, it kicks out an error that the subject is missing, seemingly more often with semi-long message. At first I thought it might be related to the recent server move from NT to linux, but apparently it was going on before this, so it's happening in both server types. Tracked it down to one modification that I really don't want to lose. I'm hoping someone seasoned in Perl can see what might be causing the problem.

Here is the mod content that changed Post.pl:

Code:

<edit file> Sources/Post.pl </edit file> <search for>            $extra = qq~      <tr>        <td class="windowbg" bgcolor="$color{'windowbg'}" width="23%"><font size=2><b>$txt{'150'}</b></font></td>        <td class="windowbg" bgcolor="$color{'windowbg'}">      <input type=text name="to" value="$INFO{'to'}" size="20" maxlength="50" onMouseOver="this.focus()" tabindex="2">      <font size="1">$txt{'748'}</font></td>      </tr>      ~; </search for> <replace> if(!$INFO{'adminim'}) {            $extra = qq~      <tr>        <td class="windowbg" bgcolor="$color{'windowbg'}" width="23%"><font size=2><b>$txt{'150'}</b></font></td>        <td class="windowbg" bgcolor="$color{'windowbg'}">      <input type=text name="to" value="$INFO{'to'}" size="20" maxlength="50" onMouseOver="this.focus()" tabindex="2">      <font size="1">$txt{'748'}</font></td>      </tr>      ~; } else { $extra = qq~$adminim~; } </replace> <search for>    <td bgcolor="$color{'bordercolor'}" class="bordercolor"> <form action="$cgi;action=$destination" method="post" name="postmodify" onSubmit="return submitproc()"> <script language="JavaScript1.2" src="$ubbcjspath" type="text/javascript"></script> </search for> <replace>    <td bgcolor="$color{'bordercolor'}" class="bordercolor">~; if($INFO{'adminim'} || $INFO{'action'} eq "imgroups") { $yymain .= qq~<form action="$cgi;action=imgroups" method="post" name="postmodify" onSubmit="return submitproc()">~; } else { $yymain .= qq~<form action="$cgi;action=$destination" method="post" name="postmodify" onSubmit="return submitproc()">~; } $yymain .= qq~<script language="JavaScript1.2" src="$ubbcjspath" type="text/javascript"></script> </replace> <search for>            if($INFO{'to'}) {$settofield="message";} else {$settofield="to";} </search for> <add after>            $idinfo = "$INFO{'id'}"; </add after> <search for>    <input type=hidden name="postid" value="$postid"> </search for> <add after>    <input type=hidden name="info" value="$idinfo"> </add after> <search for>      $csubject = $sub; </search for> <add before>      if($INFO{'action'} eq "imgroups") { $destination = "imgroups"; } </add before>

Might there be anything there in the replaced and added code that would be causing this? This mod is an instant message modification. I wondered if it could be the javascript submitproc(), which is:

Code:

function submitproc() {      if (window.submitted) return false;      window.submitted = true;      return true; }

I have no idea what this is doing.

Thanks in advance. Of course I'm happy to post any of the surrounding code if needed. There are a lot of other yabbers being beaten by this bug too.

is it yabb throwing out this error?

If so, couldn't  you locate where in the yabb scripts this error reporting is? then you could print your vars to a file to see what was in there at the time within the error reporting sub.

I hate random errors, generally I've found when you find the cause its not random at all. Its just a case of finding the condition of the fail.

There are certain people you can trust to post excellent (=== tough !) questions  

I look at your comments saying "semilong" messages cause the problem most and I wonder if that could be because either
a) Being long, they tend to include a lot o special characters, one of which is causing an upset or
b) Being long, a lot happens on the server while the user is typing them in, perhaps including an IM arriving for display on the next page?

Do you know if an IM has arrived for the user composing the IM while he/she has been typing?  (If you do, and it has, problem is (b)).   Do you know if the problem recurrs if the user tries again by
re-pasting the text and re-submitting (if you do, and the problem is reproductable, look to problem area (a)).

If I had to bet on this, I would go for something happening on the server.  Short posts, there's less of a chance.  Very long posts, people cut and paste.   Medium length, they probably sit there are type which takes time ...

I'm at "evidence gathering" at the moment ... not really offering any answer but looking at the "metrics" to help get a feel for the problem ....

Quote:

There are certain people you can trust to post excellent (=== tough !) questions

when stumped, trot over to opentalk I hate to do this, taking up your valuable time.

I saw of lot of these errors in my yabb errorlog (another mod) and didn't think that much of it. It hasn't happened to me in the same way that it's happening to others, but I haven't been posting much lately.  This error is occuring in both IM's and regular posts/replies to board topics.  It seems to trip on posts that are 1000-1500 characters. Thinking about it, I'm not really sure of where it's going wrong, because what happens to me regularly is that when I try to post a message of that sort of length, I get a document not found error or document contains no data in Mozilla, which in sp1.3.1, means that when you click the back button, you lost your text. Today I commented out the no-cache header to prevent people from losing everything when this happens. Today, one my users tried posting text of that length, and it was repeating the same behaviour, everytime she posts, she goes through this. She posts in the Help board and several other people chimed in with how they deal with the problem, and it's the first I've heard of it! No one mentioned it to me.  

A read through of a few threads at boardmod revealed that the IM mod I installed is causing a no subject error for a lot of other people too, installed, no posting, remove it, posting works again. I don't know how I got lucky enough to have some posting working, but I'd rather it didn't work at all and know about it then to find out it wasn't working part of the time.

What I'll do is work with it on my test board, and as I have a user who this is happening regularly to, see if she and I can find out what part of the modification is causing the problem, and verify that it stops when the mod is removed.

I was hoping there might be something there in that code that was questionable.

Do you have any thoughts to what might cause it to give me document not found error at times, or if they're at all related? It maybe that they're getting the document not found error like me and then getting the no subject error when they refresh. Seems logical. It wouldn't be the first time that I wasn't given all the information of a problem.

Thanks Graham

@jfp, thanks, your post made me realize that I could do something with my errorlogging mod that might help with your suggestion to log values.

Hmmm ....

Looking at this from the "micro" level,  I wonder if the IM mod that introduces the problem is fouling up a variable when one of its subroutines is called.  Does the code of the IM mod subroutines have "use strict;" at the top of it?  If not,  try adding it and see if you get a complete failure with loads of error messages in your log file - if you do, you might have a clue  

Variables in Perl default to being shared between all the various subroutines (i.e. they're global), so by default adding a piece of code that just happens to use a variable of the same name, even if it's in a totally different file, can result in strange behaviours.

I'm suspecting the problem does NOT lie in the code you posted but in the extra bits it calls ... Although the mod doesn't change the line $csubject=$sub;, it's quite possible that the IM mod also uses a variable called $sub .....  wild guess, that, but it's the sort of thing I suspect you're looking for.

That's interesting, thanks for that advice. I know I've already experienced a conflict from that mod with another mod (Notify Once) where I had found and reported long ago that:

Quote:

The following mod incompatibility has been pointed out to me between this mod and dOCda S' IM Box mod. It seems that dOCda S has "doubled-up" on the function of the $enable_notification variable, and uses it to control if email notifications are enabled. (really this should be a seperate option!)   The changes I've made mean that $enable_notification is no longer a simple on/off 1/0 switch but can take multiple values which is interfering with this line in the InstantMessage.pl file supplied with the IM Box mod:   if ($dbimcfg[1]==1 && $enable_notification == 1) { replacing it with:   if ($dbimcfg[1]==1 && $enable_notification) { should fix the problem.

So it wouldn't surprise me if the author had done this again with another variable.

Thank you. Nice to have an idea of what to look for.

---