21314 - [DOGFOOD]Random character(s) appearing at bottom of email messages

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[lchiang]

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.

Comment 1

[Phil Peterson]

Rich, can you take a look?

Comment 2

[lchiang]

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

Comment 3

[(not reading, please use [e-mail] instead)]

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

Comment 4

[rhp (gone)]

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

Comment 5

[Scott MacGregor]

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.

Comment 6

[Scott MacGregor]

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.

Comment 7

[rhp (gone)]

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

- rhp

Comment 8

[rhp (gone)]

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

Comment 9

[rhp (gone)]

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

Comment 10

[Scott MacGregor]

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.

Comment 11

[lchiang]

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

Comment 12

[Jean-Francois Ducarroz]

Should be a dup of bug 21333

Comment 13

[rhp (gone)]

Attachment: This email message will crash if loaded into the browser

Comment 14

[rhp (gone)]

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

Comment 15

[rhp (gone)]

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 ***

Comment 16

[fenella]

Mark it Verified/dup.

Comment 17

[Jean-Francois Ducarroz]

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

Comment 18

[Jean-Francois Ducarroz]

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);

Comment 19

[rhp (gone)]

Thanks for following up on this JF!

- rhp

Comment 20

[Jean-Francois Ducarroz]

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

Comment 21

[Jean-Francois Ducarroz]

Warren reviewed the code, it's ok.

Comment 22

[Jean-Francois Ducarroz]

shold be a PTD+. Set Target to M12

Comment 23

[Phil Peterson]

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

Comment 24

[leger]

Putting on PDT+ radar.

Comment 25

[Jean-Francois Ducarroz]

Fixed and checked in

Comment 26

[pmock]

Changing qa assigned to [e-mail]

Comment 27

[laurel]

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

Comment 28

[dcone (gone)]

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