Closed Bug 112656 Opened 23 years ago Closed 22 years ago

nsDependentString assertions when ScanTxt() runs on certains news messages

Categories

(MailNews Core :: Networking: NNTP, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: sspitzer, Assigned: Bienvenu)

References

Details

Attachments

(2 files)

getting into ScanTxt() for news messages attachments? more details coming soon. NTDLL! 77f9f9df() nsDebug::Assertion(const char * 0x10100d20 `string', const char * 0x10100d64 `string', const char * 0x10100ce8 `string', int 86) line 290 + 13 bytes nsDependentString::Rebind(const unsigned short * 0x066793dc, const unsigned short * 0x06679412) line 86 + 34 bytes nsDependentString::Rebind(const unsigned short * 0x066793dc, unsigned int 27) line 96 nsDependentString::nsDependentString(const unsigned short * 0x066793dc, unsigned int 27) line 99 + 51 bytes mozTXTToHTMLConv::ItMatchesDelimited(const unsigned short * 0x066793dc, int 27, const unsigned short * 0x018ca5e0, int 4, mozTXTToHTMLConv::LIMTYPE LT_IGNORE, mozTXTToHTMLConv::LIMTYPE LT_IGNORE) line 550 + 315 bytes mozTXTToHTMLConv::GlyphHit(const unsigned short * 0x066793dc, int 27, int 0, nsString & {...}, int & 1239328) line 830 + 68 bytes mozTXTToHTMLConv::ScanTXT(const unsigned short * 0x066793d0, int 33, unsigned int 12, nsString & {...}) line 1019 + 49 bytes mozTXTToHTMLConv::CalculateURLBoundaries(const unsigned short * 0x066793c0, int 63, const unsigned int 41, const unsigned int 14, mozTXTToHTMLConv::modetype abbreviated, const unsigned int 8, const unsigned int 44, nsString & {...}, nsString & {...}, int & 3, int & 3) line 356 mozTXTToHTMLConv::FindURL(const unsigned short * 0x066793c0, int 63, const unsigned int 41, const unsigned int 14, nsString & {...}, int & 1240320, int & 0) line 476 mozTXTToHTMLConv::ScanTXT(const unsigned short * 0x066793c0, int 63, unsigned int 14, nsString & {...}) line 1097 + 48 bytes mozTXTToHTMLConv::ScanTXT(mozTXTToHTMLConv * const 0x06603320, const unsigned short * 0x066793c0, unsigned int 14, unsigned short * * 0x0667a090) line 1259 MimeInlineTextPlain_parse_line(char * 0x06679670, int 63, MimeObject * 0x06674a90) line 435 + 62 bytes MimeInlineText_convert_and_parse_line(char * 0x06679670, int 63, MimeObject * 0x06674a90) line 420 + 20 bytes MimeInlineText_open_dam(char * 0x043a89b0, int 63, MimeObject * 0x06674a90) line 472 + 48 bytes MimeInlineText_rotate_convert_and_parse_line(char * 0x043a89b0, int 63, MimeObject * 0x06674a90) line 539 + 17 bytes convert_and_send_buffer(char * 0x043a89b0, int 63, int 1, int (char *, unsigned int, void *)* 0x0361eb90 MimeInlineText_rotate_convert_and_parse_line(char *, int, MimeObject *), void * 0x06674a90) line 168 + 15 bytes mime_LineBuffer(const char * 0x044c8648, int 63, char * * 0x06674ab8, int * 0x06674ac0, unsigned int * 0x06674ac8, int 1, int (char *, unsigned int, void *) * 0x0361eb90 MimeInlineText_rotate_convert_and_parse_line(char *, int, MimeObject *), void * 0x06674a90) line 255 + 29 bytes MimeInlineText_parse_decoded_buffer(char * 0x044c8648, int 63, MimeObject * 0x06674a90) line 336 + 45 bytes MimeLeaf_parse_buffer(char * 0x044c8648, int 63, MimeObject * 0x06674a90) line 168 + 20 bytes MimeUntypedText_parse_line(char * 0x044c8648, int 63, MimeObject * 0x066765a0) line 192 + 26 bytes convert_and_send_buffer(char * 0x044c8648, int 63, int 1, int (char *, unsigned int, void *)* 0x03633250 MimeUntypedText_parse_line(char *, int, MimeObject *), void * 0x066765a0) line 168 + 15 bytes mime_LineBuffer(const char * 0x044c6850, int 63, char * * 0x066765c8, int * 0x066765d0, unsigned int * 0x066765d8, int 1, int (char *, unsigned int, void *) * 0x03633250 MimeUntypedText_parse_line(char *, int, MimeObject *), void * 0x066765a0) line 255 + 29 bytes MimeObject_parse_buffer(char * 0x044c6850, int 63, MimeObject * 0x066765a0) line 255 + 49 bytes MimeMessage_parse_line(char * 0x044c6850, int 63, MimeObject * 0x06605b90) line 226 + 20 bytes convert_and_send_buffer(char * 0x044c6850, int 63, int 1, int (char *, unsigned int, void *)* 0x03627c40 MimeMessage_parse_line(char *, int, MimeObject *), void * 0x06605b90) line 168 + 15 bytes mime_LineBuffer(const char * 0x0469bc32, int 24948, char * * 0x06605bb8, int * 0x06605bc0, unsigned int * 0x06605bc8, int 1, int (char *, unsigned int, void *) * 0x03627c40 MimeMessage_parse_line(char *, int, MimeObject *), void * 0x06605b90) line 255 + 29 bytes MimeObject_parse_buffer(char * 0x04699d30, int 32886, MimeObject * 0x06605b90) line 255 + 49 bytes mime_display_stream_write(_nsMIMESession * 0x06606340, const char * 0x04699d30, int 32886) line 868 + 20 bytes nsStreamConverter::OnDataAvailable(nsStreamConverter * const 0x065f4e80, nsIRequest * 0x05fd1c40, nsISupports * 0x065da7e0, nsIInputStream * 0x065eb460, unsigned int 0, unsigned int 32886) line 922 + 24 bytes nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x065da550, nsIRequest * 0x05fd1c40, nsISupports * 0x065da7e0, nsIInputStream * 0x065eb460, unsigned int 0, unsigned int 32886) line 240 + 46 bytes nsStreamListenerTee::OnDataAvailable(nsStreamListenerTee * const 0x065f3d80, nsIRequest * 0x05fd1c40, nsISupports * 0x065da7e0, nsIInputStream * 0x065eb4c0, unsigned int 0, unsigned int 32886) line 56 + 51 bytes nsNNTPProtocol::DisplayArticle(nsIInputStream * 0x0053ca90, unsigned int 8022) line 2539 nsNNTPProtocol::ReadArticle(nsIInputStream * 0x0053ca90, unsigned int 8022) line 2613 + 16 bytes nsNNTPProtocol::ProcessProtocolState(nsIURI * 0x05fba5a4, nsIInputStream * 0x0053ca90, unsigned int 153770, unsigned int 8022) line 5176 + 19 bytes nsMsgProtocol::OnDataAvailable(nsMsgProtocol * const 0x05fd1c3c, nsIRequest * 0x0053d320, nsISupports * 0x05fba5a0, nsIInputStream * 0x0053ca90, unsigned int 153770, unsigned int 8022) line 262 + 32 bytes nsOnDataAvailableEvent::HandleEvent() line 193 + 70 bytes nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x065f0704) line 116 PL_HandleEvent(PLEvent * 0x065f0704) line 590 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00506620) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00220198, unsigned int 49489, unsigned int 0, long 5269024) line 1071 + 9 bytes USER32! 77e13eb0() USER32! 77e1401a() USER32! 77e192da() nsAppShellService::Run(nsAppShellService * const 0x03da6eb0) line 303 main1(int 2, char * * 0x00481a90, nsISupports * 0x00000000) line 1302 + 32 bytes main(int 2, char * * 0x00481a90) line 1632 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e87903()
this wasn't an attachment, it was just the text in the message. the text in the message was some sort of ASCII encoding (uuencode? base64?) of some binary data. I'll attach the message source.
Summary: getting into ScanTxt() for news messages attachments? → assertions when ScanTxt() runs on certains news messages
why do you think this is a bug? I would have been suprised if we weren't getting into Scan Txt.
it's not a bug that we get into ScanText(), it's a bug that we assert so much.
Status: NEW → ASSIGNED
Summary: assertions when ScanTxt() runs on certains news messages → nsDependentString assertions when ScanTxt() runs on certains news messages
I think this was dbaron's checkin to mozTXTToHTMLConv.cpp on 11/6 that caused this. I'm looking into it.
Assignee: sspitzer → bienvenu
Status: ASSIGNED → NEW
See the comment in nsDependentString.h right above the assertion: /* * If you see the following assertion, it means that * |nsDependentString| is being used in a way that violates * the meaning of |nsAFlatString| (that the string object * wraps a buffer that is a null-terminated single fragment). * The way to fix the problem is to use the global |Substring| * function to return a string that is an * |nsASingleFragmentString| rather than an |nsAFlatString|. * * In other words, replace: * nsDependentString(startPtr, endPtr) * with * Substring(startPtr, endPtr) * * or replace * nsDependentString(startPtr, length) * with * Substring(startPtr, startPtr+length) */
I'm having trouble telling whether that string is supposed to be null-terminated. The simple fix would be to just use substring directly. That is, change: Substring(nsDependentString(aInString, aInLength), (before == LT_IGNORE ? 0 : 1), aRepLen) to Substring(Substring(aInString, aInString+aInLength), ... which still gets the bounds-checking from the nested substring calls. otherwise you need to do the bounds checking yourself. (The Substring(string, offset, length) form of |Substring| does bounds checking based on |string.Length()|, which is why I used the double-string there.)
Status: NEW → ASSIGNED
I'm voting for dbaron's approach, just replace nsDependentString(str, len) with Substring(str, str + len) for that line. |aInString + aInLength| doesn't necessarily land us on a zero terminator, so it's actually the right thing to do. Btw, here's the code you'd get after working away the double Substring: ... PRUint32 skipChars = (before == LT_IGNORE ? 0 : 1); PRUint32 adjustedLength; if (before == LT_IGNORE) adjustedLength = aInLength; else if (aInLength > skipChars) adjustedLength = aInLength - skipChars; else adjustedLength = 0; adjustedLength = NS_MIN(adjustedLength, aRepLen); ... || !Substring(aInString + skipChars, aInString + skipChars + adjustedLength) .Equals(Substring(rep, rep + aRepLen), nsCaseInsensitiveStringComparator()) Compare that to: !Substring(Substring(aInString, aInString + aInLength), (before == LT_IGNORE ? 0 : 1), aRepLen).Equals(Substring(rep, rep + aRepLen), nsCaseInsensitiveStringComparator()) Which at least makes some kind of sense.
Attached patch proposed fixSplinter Review
this fixes the assertions for me. Please review, thx.
fix checked in, r=mscott
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 162515 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: