nsUnicodeEncodeHelper::ConvertByTable() (line 112 of that file) reads one byte past the end of src, according to Purify on Solaris with a build from yesterday (August 27, 2000). I got this error while pasting some text in viewer into the URL bar. I don't know how often it happens. The problematic line was: if (!uMapCode((uTable*) aMappingTable, NS_STATIC_CAST(PRUnichar, *(src++)), NS_REINTERPRET_CAST(PRUint16*, &med))) {

Reassign to Frank, cc to Cata.

This does not make sense. I think the purify have some bug here. 102 const PRUnichar * src = aSrc; 103 const PRUnichar * srcEnd = aSrc + *aSrcLength; 111 while (src < srcEnd) { 112 if (!uMapCode((uTable*) aMappingTable, NS_STATIC_CAST(PRUnichar, *(src++)), NS_REINTERPRET_CAST(PRUint16*, &med))) { ... } I think the *(src++) fool purify here. Otherwise, we may pass in *aSrcLength incorrectly. It will be nice if you can attach the whole stack here and the value of *aSrcLength

bruce- can you put more info. stack trace ?

mark this bug as invalid after review the code.

Since I haven't had a purify bug yet with respect to UMRs, I hesitate to believe that I'm seeing one here.

I will append information on this bug and the other(s?) tonight. I have another job during the day that requires my attention.

nsUnicodeHelper::ConvertByTable() nsTableEncoderSupport::ConvertNoBuffNoErr() nsEncoderSupport::ConvertNoBuff() nsEncoderSupport::Convert() nsClipboard::SelectionGetCB() The nsEncoderSupport and nsTableEncoderSupport stuff is from nsUCvLatinSupport.cpp This happens 4 times when I copied some text from viewer sample #1 and pasted it into the URL bar in mozilla.

Does it help if you change it from 111 while (src < srcEnd) { 112 if (!uMapCode((uTable*) aMappingTable, NS_STATIC_CAST(PRUnichar, *(src++)), NS_REINTERPRET_CAST(PRUint16*, &med))) { 113 res = NS_ERROR_UENC_NOMAPPING; 114 break; 115 } 116 117 if (!uGenerate(aShiftTable, 0, med, (PRUint8 *)dest, destLen, 118 (PRUint32 *)&bcw)) { 119 src--; 120 res = NS_OK_UENC_MOREOUTPUT; 121 break; 122 } 123 124 dest += bcw; 125 destLen -= bcw; 126 } to 111 while (src < srcEnd) { 112 if (!uMapCode((uTable*) aMappingTable, NS_STATIC_CAST(PRUnichar, *(src)), NS_REINTERPRET_CAST(PRUint16*, &med))) { 113 res = NS_ERROR_UENC_NOMAPPING; + src++; 114 break; 115 } + src++ 116 117 if (!uGenerate(aShiftTable, 0, med, (PRUint8 *)dest, destLen, 118 (PRUint32 *)&bcw)) { 119 src--; 120 res = NS_OK_UENC_MOREOUTPUT; 121 break; 122 } 123 124 dest += bcw; 125 destLen -= bcw; 126 }

Your team hasn't got access to Purify? How do you make sure your code isn't buggy and sucking?

we do have purify on Window, but not solaris. I cannot tell any code is wrong inside this routin. Can you ?

I'm in a deadline for a milestone at work. Does this error not happen on Windows under Purify? Have you looked at the callers to be sure that the length getting passed in is correct?

Here is the caller 849 nsCOMPtr<nsISupports> genericDataWrapper; 850 rv = transferable->GetTransferData(dataFlavor, 851 getter_AddRefs(genericDataWrapper), 852 &dataLength); 853 nsPrimitiveHelpers::CreateDataFromPrimitive ( dataFlavor, genericDataWrapper, &clipboardData, dataLength ); .... 911 // Estimate out length and allocate the buffer based on a worst-case estimate, then do 912 // the conversion. 913 PRUnichar *castedData = NS_REINTERPRET_CAST(PRUnichar*, clipboardData); 914 encoder->GetMaxLength(castedData, dataLength, &platformLen); 915 if ( platformLen ) { 916 platformText = NS_REINTERPRET_CAST(char*, nsMemory::Alloc(platformLen + sizeof(char))); 917 if ( platformText ) { 918 PRInt32 len = (PRInt32)dataLength; 919 rv = encoder->Convert(castedData, &len, platformText, &platformLen); 920 (platformText)[platformLen] = '\0'; // null terminate. Convert() doesn't do it for us Notice that for the GetMaxLength and Convert, the pass in length should be in the unit of # of PRUnichar, not # of bytes. It seems in other places we call dataLength/2 but not in here. Maybe we need to use dataLength/2 instead here. Reassign pavlov who origional wrote the code pavlov- I guess (just guess) we should use change line 914 to 914 encoder->GetMaxLength(castedData, dataLength/2, &platformLen); and line 918 to 918 PRInt32 len = (PRInt32)dataLength/2;

reassign this to pavlov

Memory corruption!! could be bad... nsbeta3+/P2

pdtp4. Reading past bounds is not corruption. If there is a significant user impact to this bug, please come explain it to the pdt.

Must have scanned 'writing past'.., nsbeta3-

bug 72622 is a crash when pasting large amounts of text from view source. So there is indeed user impact with this bug. Should this still be assigned to pavlov, or should this go to someone else?

Removing [PDT] grafitti.

Added crash and topcrash to keywords. Comments/URLs: (12159362) URL: barrapunto.org (12159362) Comments: I clicked on a link and it crashed

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.

Making this topcrash- and marking worksforme. Talkback data does not show any crashes like this in recent MozillaTrunk builds. The most recent incidents reported are for Netscape 6.2x releases.

Verified.