36491 - Visiting http://www.memepool.com/ causes Mozilla to die on the spot

Status: VERIFIED FIXED

(Core :: DOM: HTML Parser, defect, P3)

Description

[Chris Siebenmann]

Build ID: 2000041911 (and current CVS pull)

 If I visit the named web site, Mozilla dies on the spot. Bang. 100%
reproduceable. This doesn't happen on M15.

 With my CVS version, I get the following stack backtrace out of gdb:

Program received signal SIGSEGV, Segmentation fault.
0x0 in ?? ()
(gdb) where
#0  0x0 in ?? ()
#1  0x40d3b383 in CNavDTD::CollectAttributes ()
   from /scratch/mozilla/dist/bin/components/libraptorhtmlpars.so
#2  0x40d3a315 in CNavDTD::HandleStartToken ()
   from /scratch/mozilla/dist/bin/components/libraptorhtmlpars.so
#3  0x40d395a0 in CNavDTD::HandleToken ()
   from /scratch/mozilla/dist/bin/components/libraptorhtmlpars.so
#4  0x40d3af04 in CNavDTD::HandleSavedTokens ()
   from /scratch/mozilla/dist/bin/components/libraptorhtmlpars.so
#5  0x40d3a214 in CNavDTD::HandleOmittedTag ()
   from /scratch/mozilla/dist/bin/components/libraptorhtmlpars.so
#6  0x40d39cf6 in CNavDTD::HandleDefaultStartToken ()
   from /scratch/mozilla/dist/bin/components/libraptorhtmlpars.so
#7  0x40d3a527 in CNavDTD::HandleStartToken ()
   from /scratch/mozilla/dist/bin/components/libraptorhtmlpars.so
#8  0x40d395a0 in CNavDTD::HandleToken ()
   from /scratch/mozilla/dist/bin/components/libraptorhtmlpars.so
#9  0x40d3941d in CNavDTD::HandleToken ()
   from /scratch/mozilla/dist/bin/components/libraptorhtmlpars.so
#10 0x40d38fb1 in CNavDTD::BuildModel ()
   from /scratch/mozilla/dist/bin/components/libraptorhtmlpars.so
#11 0x40d45077 in nsParser::BuildModel ()
   from /scratch/mozilla/dist/bin/components/libraptorhtmlpars.so
---Type <return> to continue, or q <return> to quit--- 
#12 0x40d44eac in nsParser::ResumeParse ()
   from /scratch/mozilla/dist/bin/components/libraptorhtmlpars.so
#13 0x40d457d6 in nsParser::OnDataAvailable ()
   from /scratch/mozilla/dist/bin/components/libraptorhtmlpars.so
#14 0x40890a4f in nsDocumentOpenInfo::OnDataAvailable ()
   from /scratch/mozilla/dist/bin/components/liburiloader.so
#15 0x411bb6f5 in InterceptStreamListener::OnDataAvailable ()
   from /scratch/mozilla/dist/bin/components/libnecko_cache.so
#16 0x40cfb35c in nsHTTPServerListener::OnDataAvailable ()
   from /scratch/mozilla/dist/bin/components/libnecko_http.so
#17 0x4082137c in nsOnDataAvailableEvent::HandleEvent ()
   from /scratch/mozilla/dist/bin/components/libnecko.so
#18 0x40820c18 in nsStreamListenerEvent::HandlePLEvent ()
   from /scratch/mozilla/dist/bin/components/libnecko.so
#19 0x4010d356 in PL_HandleEvent () from /scratch/mozilla/dist/bin/libxpcom.so
#20 0x4010d286 in PL_ProcessPendingEvents ()
   from /scratch/mozilla/dist/bin/libxpcom.so
#21 0x4010e02a in nsEventQueueImpl::ProcessPendingEvents ()
   from /scratch/mozilla/dist/bin/libxpcom.so
#22 0x4047015e in event_processor_callback ()
   from /scratch/mozilla/dist/bin/libwidget_gtk.so
#23 0x4046ff02 in our_gdk_io_invoke ()
   from /scratch/mozilla/dist/bin/libwidget_gtk.so
---Type <return> to continue, or q <return> to quit---
#24 0x4060eaca in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#25 0x40610186 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#26 0x40610751 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#27 0x406108f1 in g_main_run () from /usr/lib/libglib-1.2.so.0
#28 0x405355b9 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#29 0x4047063d in nsAppShell::Run ()
   from /scratch/mozilla/dist/bin/libwidget_gtk.so
#30 0x4041365d in nsAppShellService::Run ()
   from /scratch/mozilla/dist/bin/components/libnsappshell.so
#31 0x804ae92 in main1 ()
#32 0x804b1ce in main ()
#33 0x4023a9cb in __libc_start_main (main=0x804b038 <main>, argc=2, 
    argv=0xbfffec44, init=0x8049044 <_init>, fini=0x804bf60 <_fini>, 
    rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbfffec3c)
    at ../sysdeps/generic/libc-start.c:92

(I build from CVS with --disable-tests, --disable-debug, and
--enable-optimize.)

 gdb on the nightly build yields less information but information that's
consistent with this.

 Environment: Redhat 6.1 and Redhat 6.2 systems.

(I have saved a snapshot of the web page, in case it changes enough so
that the crash no longer happens, and I can attach it to the bug report
if desired.)

Comment 1

[David Hallowell]

Reproduced on Mozilla build 2000041915 Linux (Slackware 7.0)

Saved file to local disk and reproduced crash using this build.

Edited HTML file to remove DOCTYPE declaration which was currently the HTML 2.0

version:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> and browser did not crash any more.



Added an HTML 4.0 DOCTYPE: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01

Transitional//EN"  PR-html40-19990824/loose.dtd>

and browser did not crash.



All I can say is that it's the HTML 2.0 DOCTYPE declaration along with some

other elements on the page, I've constructed simple pages with the HTML 2.0

doctype and they have all worked. I don't have the time to narrow down the

search to see what's eactly causing the crash but if I have time I'll

investigate further later.

Comment 2

[rickg]

Fun fun fun for you you you.

Comment 3

[harishd]

Failed to set auto-detect-status in FindSuitableDTD() logic. FIXED now.

Comment 4

[Antti Näyhä]

No crash on build 2000-05-22-08, Red Hat 6.2 & kernel 2.2.14.
Verifying Fixed.

Comment 5

[Jan Carpenter]

Verified
2000-07-07-10-M17 : Linux