Closed Bug 40872 Opened 25 years ago Closed 25 years ago

This site crashes mozilla.

Categories

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

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: mcrites, Assigned: rickg)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: fix in hand)

Attachments

(1 file)

full stack trace, PC/Linux, build made from 5/21 sources
2.63 KB, text/plain
Details
From Bugzilla Helper: User-Agent: Mozilla/4.73 [en] (X11; U; Linux 2.2.15 i686) BuildID: 2000052720 When I load up my site, mozilla crashes. Netscape and IE display it correctly. Reproducible: Always Steps to Reproduce: 1.Load up the site in mozilla 2. 3. Actual Results: Mozilla crashes. Expected Results: Render the site. GDB output: #0 0x40e0b1be in NSGetModule () from /home/bigbiff/.desktop/package/components/libraptorhtml.so #1 0x40e0df28 in NSGetModule () from /home/bigbiff/.desktop/package/components/libraptorhtml.so #2 0x41053b8d in NSGetModule () from /home/bigbiff/.desktop/package/components/libraptorhtmlpars.so #3 0x41053c67 in NSGetModule () from /home/bigbiff/.desktop/package/components/libraptorhtmlpars.so #4 0x4105389a in NSGetModule () from /home/bigbiff/.desktop/package/components/libraptorhtmlpars.so #5 0x4105366b in NSGetModule () from /home/bigbiff/.desktop/package/components/libraptorhtmlpars.so #6 0x41048a0f in NSGetModule () from /home/bigbiff/.desktop/package/components/libraptorhtmlpars.so #7 0x41049fe1 in NSGetModule () from /home/bigbiff/.desktop/package/components/libraptorhtmlpars.so #8 0x4104948a in NSGetModule () from /home/bigbiff/.desktop/package/components/libraptorhtmlpars.so #9 0x41049dbc in NSGetModule () from /home/bigbiff/.desktop/package/components/libraptorhtmlpars.so #10 0x40a5d1b3 in NSGetModule () from /home/bigbiff/.desktop/package/components/liburiloader.so #11 0x409899d9 in NSGetModule () from /home/bigbiff/.desktop/package/components/libnecko.so #12 0x4096d84a in NSGetModule () from /home/bigbiff/.desktop/package/components/libnecko.so #13 0x40968656 in NSGetModule () from /home/bigbiff/.desktop/package/components/libnecko.so #14 0x40988979 in NSGetModule () from /home/bigbiff/.desktop/package/components/libnecko.so #15 0x4094b9c4 in NSGetModule () from /home/bigbiff/.desktop/package/components/libnecko.so #16 0x4094b2c0 in NSGetModule () from /home/bigbiff/.desktop/package/components/libnecko.so #17 0x400b27bb in PL_HandleEvent () from /home/bigbiff/.desktop/package/libxpcom.so ---Type <return> to continue, or q <return> to quit--- #18 0x400b26f6 in PL_ProcessPendingEvents () from /home/bigbiff/.desktop/package/libxpcom.so #19 0x400b33bd in nsEventQueueImpl::ProcessPendingEvents () from /home/bigbiff/.desktop/package/libxpcom.so #20 0x405c620f in NSGetModule () from /home/bigbiff/.desktop/package/components/libwidget_gtk.so #21 0x405c5fdd in NSGetModule () from /home/bigbiff/.desktop/package/components/libwidget_gtk.so #22 0x4075547a in g_io_unix_dispatch (source_data=0x8211638, current_time=0xbffff448, user_data=0x8211610) at giounix.c:135 #23 0x407569b6 in g_main_dispatch (dispatch_time=0xbffff448) at gmain.c:656 #24 0x40756f71 in g_main_iterate (block=1, dispatch=1) at gmain.c:877 #25 0x407570e9 in g_main_run (loop=0x8211650) at gmain.c:935 #26 0x40683bca in gtk_main () at gtkmain.c:476 #27 0x405c66ea in NSGetModule () from /home/bigbiff/.desktop/package/components/libwidget_gtk.so #28 0x40388c3a in NSGetModule () from /home/bigbiff/.desktop/package/components/libnsappshell.so #29 0x804d117 in JS_PushArguments () #30 0x804d539 in JS_PushArguments () #31 0x402469cb in __libc_start_main (main=0x804d420 <JS_PushArguments+10336>, argc=1, argv=0xbffff674, init=0x804a780 <_init>, fini=0x8051c58 <_fini>, rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffff66c) at ../sysdeps/generic/libc-start.c:92
Yup, it also crashes the Win32 Mozilla (build 2000052508), with a GPF in GKHTML.
This page starts with: <?xml version="1.0" encoding="UTF-8"?> and then continues with a <!DOCTYPE HTML ... > declaration. If I remove the <?xml ...> line, the page renders fine. I don't know if this makes it less of a bug (Mozilla sure shouldn't segfault), but it may help to resolve the issue. Han Holl
Confimed. Crash also on build 2000052720 on Win2k
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assigning to rickg@netscape.com, cc jrgm@netscape.com and self. This crash occurs in a 5/27 build.
Assignee: asadotzler → rickg
Severity: normal → critical
Component: Browser-General → Parser
Keywords: crash
Bug 40145 and bug 38158 (and maybe others) are still alive in the 5/27 build, but they are marked resolved as duplicates of bug 39520. Rick, since you marked bug 39520 fixed again, which one should deal with these crashers then?
This is now working in my build. I'll close this as "fixed by side effect" when I land my changes.
Status: NEW → ASSIGNED
Whiteboard: fix in hand
It still seems to crash in the latest mozilla. 6/2 is the build.
Sorry for the spam. New QA Contact for Browser General. Thanks for your help Joseph (good luck with the new job) and welcome aboard Doron Rosenberg
QA Contact: jelwell → doronr
yep, this is back in 200060808 win98 mozilla build
OS: Linux → All
I can't seem to get to this site for testing, but I think the problem may be fixed. Please retest if possible.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Currently this site seems to be down, but when I test bug 38158 instead, it's still happily crashing for me on PC/Linux build 2000060908 (which is the latest one on the ftp server). That crashes go away if I set "ENABLE_STRICT" to "true" in my environment before launching mozilla (as suggested in bug 39520). But since this is not the default yet, I really think there should be one bug left open for these crashers until this is enabled by default.
You should repull the tree. EnableStrict is now on by default.
That's good news :-) Also www.exxtreme-linux.org is up again, so I could try the 6/9 build with strict dtd enabled, and it doesn't crash! It seems that this is really fixed...
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: