Closed Bug 10204 Opened 25 years ago Closed 25 years ago

Crash in RDFContentSinkImpl::FlushText from unterminated PRUnichar*

Categories

(Core Graveyard :: RDF, defect, P3)

Product:
Core Graveyard
Component:
RDF
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: kherron+mozilla, Assigned: waterson)

Details

Apprunner is segfaulting during startup before any window appears:

#0  0x401b133a in nsCRT::strlen (s=0x8275002) at
../../../mozilla/xpcom/ds/nsCRT.cpp:261
#1  0x401c0792 in nsString::Append (this=0xbfffebfc, aString=0x8271008,
aCount=37)
    at ../../../mozilla/xpcom/ds/nsString2.cpp:1017
#2  0x40a4984a in RDFContentSinkImpl::FlushText (this=0x821a208,
aCreateTextNode=1,
    aDidFlush=0x0) at ../../../../mozilla/rdf/base/src/nsRDFContentSink.cpp:826
#3  0x40a48bdc in RDFContentSinkImpl::CloseContainer (this=0x821a208,
aNode=@0xbfffed68)
    at ../../../../mozilla/rdf/base/src/nsRDFContentSink.cpp:536
#4  0x402f6cee in CWellFormedDTD::HandleToken (this=0x8267b48, aToken=0x826f708,
    aParser=0x8240008) at
../../../mozilla/htmlparser/src/nsWellFormedDTD.cpp:523
#5  0x402f6220 in CWellFormedDTD::BuildModel (this=0x8267b48, aParser=0x8240008,
    aTokenizer=0x826aa88, anObserver=0x0, aSink=0x821a208)
    at ../../../mozilla/htmlparser/src/nsWellFormedDTD.cpp:252
#6  0x402ee9fc in nsParser::BuildModel (this=0x8240008)
    at ../../../mozilla/htmlparser/src/nsParser.cpp:932
#7  0x402ee8c6 in nsParser::ResumeParse (this=0x8240008, aDefaultDTD=0x0,
    aIsFinalChunk=0) at ../../../mozilla/htmlparser/src/nsParser.cpp:879
[etc.]

Going up to level 2 and examining the prunichar* that is being passed to
nsString::Append, it's not NUL-terminated:

(gdb) up 2
#2  0x40a4984a in RDFContentSinkImpl::FlushText (this=0x821a208,
aCreateTextNode=1,
    aDidFlush=0x0) at ../../../../mozilla/rdf/base/src/nsRDFContentSink.cpp:826
826	                value.Append(mText, mTextLength);
(gdb) p mTextLength
$1 = 37
(gdb) p mText[35]
$2 = 116
(gdb) p mText[36]
$3 = 47
(gdb) p mText[37]
$4 = 50629
(gdb)
$5 = 50629
(gdb) down 2
#0  0x401b133a in nsCRT::strlen (s=0x8275002) at
../../../mozilla/xpcom/ds/nsCRT.cpp:261
261	    while (*s++ != 0) {
(gdb) p len
$6 = 8188
(gdb)

This caused nsCRT::strlen to go beyond the end of valid memory trying to find
the length of the string.

I reported this before (bug 10075) but it was handled as a bug in
nsString::Append.  Rickg's position is that nsString::Append is correct, and
callers should be NUL-terminating strings passed to it.
Yep, this was caused by rickg's stealth-change to the nsString::Append API. My
belief is that nsString2::Append() _should_ pay attention to the length field
(a la strncat()), we can hash this out on this thread:
news://news.mozilla.org/3794AAB8.558D40F6%40netscape.com
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Okay, I'll just shut up: rickg fixed this this morning.
verified on

     1999-07-26-14 RedHat Linux 5.2 (GNOME/enlightenment)
     1999-07-26-08 WinNT 4.0 sp4
     1999-07-26-08 MacOS 8.51
Status: RESOLVED → VERIFIED
Target Milestone: M9
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.