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)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: sspitzer, Assigned: Bienvenu)
References
Details
Attachments
(2 files)
308.61 KB,
text/plain
|
Details | |
893 bytes,
patch
|
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
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()
Reporter | ||
Comment 1•23 years ago
|
||
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
Comment 2•23 years ago
|
||
why do you think this is a bug? I would have been suprised if we weren't getting
into Scan Txt.
Reporter | ||
Comment 3•23 years ago
|
||
Reporter | ||
Comment 4•23 years ago
|
||
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
Assignee | ||
Comment 5•23 years ago
|
||
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.)
Updated•23 years ago
|
Status: NEW → ASSIGNED
Comment 8•23 years ago
|
||
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.
Assignee | ||
Comment 9•22 years ago
|
||
this fixes the assertions for me. Please review, thx.
Attachment #128812 -
Flags: superreview+
Assignee | ||
Comment 10•22 years ago
|
||
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. ***
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•