Random character(s) appearing at bottom of email messages 12/9/1999 Win32 build 1) Start Messenger 2) Login to IMAP 3) Select a message to view. I've seen this on the dogfood snack return message and on my bugzilla and bugsplat notifications 4) Notice at the bottom of the message in the message pane that there is a random character displayed. Note: Paul Hangas sees this as well. Not sure what the cause of this is.

Rich, can you take a look?

The same message displays without this character in 4.x.

norris, is this yours? I see this on linux, and I get this assertion: Null found at buffer[305] provided by netlib... ###!!! ASSERTION: possible embedded null in append(char*): 'kNotFound==len', file nsString2.cpp, line 1127

Sorry, but I tried to get this to happen over and over again without any luck. They all seem to work on my machines including the test email you sent. - rhp

re-opening. I see this on about 60% of the message I view on both my debug build and the commercial release build from today. apparently seth is seeing it too. Not sure what we need to do to get it to happen on your machine but it definetly is there.

I would add that there doesn't seem to be a corelation about what messages trigger the problem. I have it on regular short messages and not just bugsplat or dogfood snack email.

When did you last build? I just pulled and rebuilt my entire tree? - rhp

Ok, after sleeping on this one, I know what the problem is here. I had a bug in libmime where I was creating a string as follows: nsString strline(linep); but linep was always NULL terminated. Result = Garbage! And this would only happen at the end of messages. I checked in 2 fixes for this problem. They are the top two at the end of this list: http://cvs-mirror.mozilla.org/webtools/bonsai/showcheckins.cgi?person=rhp%25net scape.com&treeid=SeaMonkey I think with all of the problems that happened with CVS, these changes were probably not part of the release build. This would explain why I'm not seeing them. - rhp

It's still early...the line: but linep was always NULL terminated. Result = Garbage! And this would only should read: but linep wasn't always NULL terminated. Result = Garbage! And this would only

Hey Rich, I hate to keep doing this to you but I'm still seeing the problem in today's 12/10/99 win32 commercial release build. I believe this should have the changes you were referring to in the bug report. re-opening.

*** Bug 21387 has been marked as a duplicate of this bug. ***

Should be a dup of bug 21333

If you load the attached message, it will crash layout. Since we are having this problem with corruption, etc... I thought I would post it. - rhp

Ok, we have problems in layout with data getting munged. On Mac, you get double lines and on Windows, it looks like we get garbage at the end. JF really helped diagnose this so we are down to a layout problem with the new approach of message body display. - rhp *** This bug has been marked as a duplicate of 21333 ***

Mark it Verified/dup.

Per comment of troy in bug 21333, I reopen this bug.

I found a problem with the way we compute the size of the decoded string in nsDataChannel.cpp. That explain garbage characters we see often on all platform: Index: nsDataChannel.cpp =================================================================== RCS file: /cvsroot/mozilla/netwerk/protocol/data/src/nsDataChannel.cpp,v retrieving revision 1.17 diff -r1.17 nsDataChannel.cpp 178,179d177 < char *decodedData = (char*)nsAllocator::Alloc((dataLen * 3)/4); < if (!decodedData) return NS_ERROR_OUT_OF_MEMORY; 181c179,180 < decodedData = PL_Base64Decode(comma+1, dataLen, decodedData); --- > char * decodedData = PL_Base64Decode(comma+1, dataLen, nsnull); > if (!decodedData) return NS_ERROR_OUT_OF_MEMORY; 183c182 < dataToWrite->dataLen = (dataLen * 3)/4; --- > dataToWrite->dataLen = PL_strlen(decodedData); 186c185 < rv = bufOutStream->WriteSegments(nsReadData, dataToWrite, (dataLen * 3)/4, &wrote); --- > rv = bufOutStream->WriteSegments(nsReadData, dataToWrite, dataToWrite->dataLen, &wrote);

Thanks for following up on this JF! - rhp

No problem. I asked warren to review the fix, still waiting...

Warren reviewed the code, it's ok.

shold be a PTD+. Set Target to M12

*** Bug 21563 has been marked as a duplicate of this bug. ***

Putting on PDT+ radar.

Fixed and checked in

Changing qa assigned to pmock@netscape.com

OK using 12-14-11m12 commercial build on linux 6.0 OK using 12-14-08m12 commercial build on NT 4.0 OK using 12-14-08m12 commerical build on mac OS 8.5.1

*** Bug 21357 has been marked as a duplicate of this bug. ***