Closed Bug 293780 Opened 20 years ago Closed 18 years ago

HTML code causes system lockup

Categories

(Core Graveyard :: GFX: Gtk, defect)

Product:
Core Graveyard
Component:
GFX: Gtk
Version:
1.7 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: paulgrogers, Assigned: blizzard)

References

(
URL
)

Details

(Keywords: hang, testcase)

Attachments

(1 file)

reporter's testcase from comment 0
1.50 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.7) Gecko/20050508 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.7) Gecko/20050508 Firefox/1.0.3

This may be similar to #287768, but I hope simplified.

The following bit of HTML code abstracted from the Network Administrator's Guide
v2, causes Firefox-1.0.3 on Linux to do a lot of disk activity for a minute or
so, then the mouse locks up, the keyboard (^C or CTL-ALT-Delete) is inoperative,
and the only way out is to push the reset button.  The following message appears
in /var/log/messages:
May 10 22:31:11 pod kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
May 10 22:31:11 pod kernel: VM: killing process X

(I have put the HTML fragment in a comment, lest it do the same to others who
view this, I hope)
<!---
<HTML
><HEAD
><TITLE
>Original IP Firewall (2.0 Kernels)</TITLE
></HEAD
><BODY
><P
>Specify the destination IP address that this rule will match. The destination
address is coded with the same rules as the source address described previously.
Here is an example:</P
><P
><TT
CLASS="LITERAL"
>-D 172.29.16.1/24 smtp</TT
></P
></DD
><DT
>-V address</DT
><DD
><P
>Specify the address of the network interface on which the packet is received
(<TT
CLASS="OPTION"
>-I</TT
>&#8201;) or is being sent (<TT
CLASS="OPTION"
>-O</TT
>). This
allows us to create rules that apply only to certain network interfaces on our
machine. Here is an example:</P
><P
><TT
CLASS="LITERAL"
>-V 172.29.16.1</TT
></P
></DD
><DT
>-W name</DT
><DD
><P
>Specify the name of the network interface. This argument works in the same way
as the <TT
CLASS="OPTION"
>-V</TT
> argument, except you supply the device name
instead of its address. Here is an example:</P
><P
><TT
CLASS="LITERAL"
>-W ppp0</TT
></P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
></BODY
></HTML
>
-->

Reproducible: Always

Steps to Reproduce:
1. Open that piece of HTML
2.
3.
Actual Results:  
See above.

Expected Results:  
Something should have been rendered.

LFS-4.1 derived system.  Kernel-2.4.29, glibc-2.3.1, gcc-3.2.1, XFree86-4.2.1,
Gtk+/glib-1.2.10, blackbox-0.65, Firefox-1.0.3 (with
Mozilla-1.7-pluginwarn.patch installed) all compiled from scratch.
Paul, can you confirm the attachment I made still hangs your firefox? It didn't
format nicely.
Alternative, please attach an html testcase to this bug report that does show
what you are reporting. thanks!
Hmmm, looks like my email reply wasn't added.

In answer to your test case, it sure does!  Locks it up tight.  Hope you don't
need this tested too many times.

Sorry about the formatting, but it was the author's.
p.s. If there were some extra tags in the HTML fragment I quoted it's because I
took the original section 9.6 (nag-2.0-html.tar.gz most likely downloaded from
ftp.osuosl.org's gentoo distfiles), copied it four times, then cut out
progressive big sections to see which chunk still locked-up.  You could go to
the original for a "properly formatted" complete version--it also locks up my
system.  I was just trying to localize the problem somewhat for you.
Keywords: hang, testcase
Testcase doesn't hang for me with:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050509
Firefox/1.0.4
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050512
Firefox/1.0+ ID:2005051215

Paul, could you test the testcase hang with a nightly trunk (1.1alpha) build to
see if this is still a problem; it may have been fixed by one of the 100s of bug
patches already landed.

You can get the latest trunk version at
- http://www.ftp.uni-erlangen.de/pub/mozilla.org/firefox/nightly/latest-trunk/
But I'd advise you to make a new profile for running it (ie: don't use your 1.03
profile with the trunk build).
I don't think I can.  This is a LFS system of modest resources, e.g. 64MB
P1-233.  I've been careful to select S/W versions which provided needed
features, but don't bog it down, e.g. GTK+-1.2.10.  So I can't use any of
Mozilla's builds, and that's apparently what's at the latest trunk directory,
*686*.  I have to compile from source, at 4.5hrs a pop.  And I don't have CVS
because I'm not a developer of anything.  I did just download the 1.0.4 sources,
but I doubt that will help.
it renders for me no problems at all

FireFox 1.0.4 - Linux - Xorg 6.8.2
(In reply to comment #6)
> Testcase doesn't hang for me with:
> - Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050509
> Firefox/1.0.4
> - Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050512
> Firefox/1.0+ ID:2005051215

That's Windows.  Whatever it is takes down X, so I'm suspicious it might be one
of the firefox-X-linux interfaces.  I have to patch it once already because I'm
using the old GTK+-1.2.10, so if it was something like that it wouldn't be
surprizing.  The Mozilla builds for distribution are built with GTK+-2.  Is
somebody still testing it with 1.2?

> You can get the latest trunk version at
> - http://www.ftp.uni-erlangen.de/pub/mozilla.org/firefox/nightly/latest-trunk/

Where can I find a source tarball for one of these nightly's so I can compile
and test it?
Got a new URL that causes lockup:
http://www.mozilla.org/products/firefox/all.html
All I was trying to do was find the page where I saw it is OK to compile with
GTK+-1.2.
Steve England wanted me to rerun the test with a recent nightly build.  I tried
to find a Firefox tarball, but failed.  I went to
mozilla.org/download-mozilla.html on 5/17 and downloaded (2.5+hr) the nightly I
found there.  It appeared to be the Mozilla Suite 1.8b2, which I compiled this
evening (7.5+hr).  Then I went to section 9.5 of the nag2, which rendered fine.
 Then I clicked on "NEXT" to go to 9.6.  Nothing happened for several seconds,
then the hard drive began thrashing as it does before the system locks-up.  It
was on it's way, so I pressed CTL/ALT/Backspace to stop it.  That's a failure. 
(Do I really need to suffer a hard reset and fsck trying to repair a munged file
system?)

So, yes, whatever it is, it's still in recent nightly's and hasn't been fixed as
a collateral benefit.
I recompiled my firefox-1.0.4 with debug enabled, ran it with a log file, and
went to mozilla.org/products/firefox/all, waited a few seconds after it rendered
what it was going to (something about "Download") until it started exercising my
HD, then pressed CTL-ALT-Backspace to kill it so the log file such as it was
would be closed.  I've attached it here.  Not sure if this helps, or what else I
can do.


###!!! ASSERTION: couldn't get thread private index:
'nsThread::kIThreadSelfIndex != 0', file
/usr/local/src/mozilla/xpcom/threads/nsThread.cpp, line 376
Break: at file /usr/local/src/mozilla/xpcom/threads/nsThread.cpp, line 376
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
/usr/local/src/mozilla/toolkit/profile/src/nsINIParser.cpp, line 51
Type Manifest File: /home/paul/.mozilla/firefox/tfh51oue.default/xpti.dat
nsNativeComponentLoader: autoregistering begins.
*** Registering xpcomObsoleteModule components (all right -- a generic module!)
*** Registering xpconnect components (all right -- a generic module!)
*** Registering nsUConvModule components (all right -- a generic module!)
*** Registering nsUCvMathModule components (all right -- a generic module!)
*** Registering nsI18nModule components (all right -- a generic module!)
*** Registering nsJarModule components (all right -- a generic module!)
*** Registering nsCJVMManagerModule components (all right -- a generic module!)
*** Registering necko_core_and_primary_protocols components (all right -- a
generic module!)
*** Registering necko_secondary_protocols components (all right -- a generic
module!)
*** Registering nsPrefModule components (all right -- a generic module!)
*** Registering nsSecurityManagerModule components (all right -- a generic module!)
*** Registering nsRDFModule components (all right -- a generic module!)
*** Registering nsParserModule components (all right -- a generic module!)
*** Registering nsGfxPSModule components (all right -- a generic module!)
*** Registering nsGfxXprintModule components (all right -- a generic module!)
*** Registering nsGfxGTKModule components (all right -- a generic module!)
*** Registering nsImageLib2Module components (all right -- a generic module!)
*** Registering nsPluginModule components (all right -- a generic module!)
*** Registering nsWidgetGTKModule components (all right -- a generic module!)
*** Registering XRemoteClientModule components (all right -- a generic module!)
*** Registering nsLayoutModule components (all right -- a generic module!)
*** Registering nsMorkModule components (all right -- a generic module!)
*** Registering docshell_provider components (all right -- a generic module!)
*** Registering embedcomponents components (all right -- a generic module!)
*** Registering Browser_Embedding_Module components (all right -- a generic module!)
*** Registering nsEditorModule components (all right -- a generic module!)
*** Registering nsTransactionManagerModule components (all right -- a generic
module!)
*** Registering nsComposerModule components (all right -- a generic module!)
*** Registering appshell components (all right -- a generic module!)
*** Registering nsChromeModule components (all right -- a generic module!)
*** Registering nsAccessibilityModule components (all right -- a generic module!)
*** Registering BOOT components (all right -- a generic module!)
*** Registering NSS components (all right -- a generic module!)
*** Registering PKI components (all right -- a generic module!)
*** Registering nsFileViewModule components (all right -- a generic module!)
*** Registering nsFindComponent components (all right -- a generic module!)
*** Registering XRemoteServiceModule components (all right -- a generic module!)
*** Registering application components (all right -- a generic module!)
*** Registering nsToolkitCompsModule components (all right -- a generic module!)
*** Registering nsSoftwareUpdate components (all right -- a generic module!)
*** Registering JavaScript_Debugger components (all right -- a generic module!)
*** Registering nsCookieModule components (all right -- a generic module!)
*** Registering nsXMLExtrasModule components (all right -- a generic module!)
*** Registering nsAutoConfigModule components (all right -- a generic module!)
*** Registering TransformiixModule components (all right -- a generic module!)
*** Registering nsUniversalCharDetModule components (all right -- a generic module!)
*** Registering nsWebServicesModule components (all right -- a generic module!)
*** Registering nsInspectorModule components (all right -- a generic module!)
*** Registering nsBrowserCompsModule components (all right -- a generic module!)
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
/usr/local/src/mozilla/toolkit/profile/src/nsINIParser.cpp, line 51
GFX: dpi=75 t2p=0.0526316 p2t=19 depth=16
++WEBSHELL == 1
++DOMWINDOW == 1
LoadPlugin() /usr/local/lib/firefox-1.0.4/plugins/libnullplugin.so returned 81798a8
GetMIMEDescription() returned "*:.*:All types"
++WEBSHELL == 2
++DOMWINDOW == 2
/usr/local/lib/firefox-1.0.4/chrome/toolkit.jar mtime changed, invalidating
FastLoad file
Note: styleverifytree is disabled
Note: frameverifytree is disabled
Note: verifyreflow is disabled
++WEBSHELL == 3
++DOMWINDOW == 3
CSS Error (http://foxfire.lan/ :2.63): Expected color but found '#0'.  Error in
parsing value for property 'color'.  Declaration dropped.
WARNING: the property eo already exists
, file /usr/local/src/mozilla/xpcom/ds/nsPersistentProperties.cpp, line 282
###!!! ASSERTION: garbled pattern: unexpected end of pattern: '*p', file
nsFT2FontNode.cpp, line 433
Break: at file nsFT2FontNode.cpp, line 433
###!!! ASSERTION: garbled pattern: unexpected end of pattern: '*p', file
nsFT2FontNode.cpp, line 433
Break: at file nsFT2FontNode.cpp, line 433
###!!! ASSERTION: garbled pattern: unexpected end of pattern: '*p', file
nsFT2FontNode.cpp, line 433
Break: at file nsFT2FontNode.cpp, line 433
Gdk-ERROR **: X connection to :0.0 broken (explicit kill or server shutdown).
nsStringStats
 => mAllocCount: 29458
 => mReallocCount: 3980
 => mFreeCount: 26774
 => mShareCount: 24226
 => mAdoptCount: 5537
 => mAdoptFreeCount: 5503
A friend insisted my Linux system is probably still running, just not accessible
because X left the terminal in an unusable state.  I tested and have discovered
the system still lives.  I set an "at" command to do a reboot several minutes in
the future, then started firefox and went to section 9.6 of NAG2.  I waited a
few minutes for lockup, and then a few minutes more for the timer to expire, and
the system rebooted.  So the range of the failure seems to be firefox & X, but
Linux is still running--just not accessible from the console terminal.  Hope
this helps.  
WFM on FC3, using both Deer Park Alpha (CVS) and Firefox 1.0.4 (rpm)

Build IDs:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050622 Firefox/1.0+
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513
Fedora/1.0.4-1.3.1 Firefox/1.0.4

Linux version:
2.6.11-1.27_FC3

rpm versions:
xorg-x11-6.8.2-1.FC3.13
gcc-3.4.3-22.fc3
gtk2-2.4.14-3.fc3
My LFS system runs a Pentium-I/MMX with 64MB RAM, 256MB swap partition.  A
friend suggested maybe that's too small, so I added a 128MB swapfile to /.  It
still failed with my test case.  BTW, it also crashes on Firefox's "Other
Systems & Languages" page!

I'm trying to compile 1.0.6 with GTK+-2.4.14, et al, but it doesn't run.  No
error messages, it just returns a prompt.  I've asked for help at the
Mozillazine support forums.  If I get this to run I'll be able to check whether
the GTK+-1.2.10 I'm using with Firefox-1.0.4 is playing a role.
Oh, sorry, I've also "upgraded" from XFree86-4.2.1 to XOrg-6.8.2, but the memory
leak, and kernel killing X over an OOM still happens.
I tried recompiling with debug enabled, optimize disabled, then tried to start
firefox from an xterm with a log running.  This time firefox 1.0.6 came up
(???), so I went to my test case.  It crashed again.  Now, this is with
XOrg-6.8.2, GTK+-2.4.14, glib-2.4.2, atk-1.2.4, pango-1.6.0, libIDL-0.8.2.  I've
got the console debug log file.  Do you want that posted?  I'll try to preserve
this state for a few days at least, but I'll have to archive and clean-off most
of this whole branch before long.
run ./firefox -g -d gdb
###!!! ASSERTION: garbled pattern: unexpected end of pattern: '*p', file
nsFT2FontNode.cpp, line 433
Break: at file nsFT2FontNode.cpp, line 433

when you get to that get a stack trace. read the unix debugging faq if 
necessary. dump the locals and such.
Assignee: nobody → blizzard
Component: General → GFX: Gtk
Product: Firefox → Core
QA Contact: general → gtk
Version: unspecified → 1.7 Branch
>Additional Comments From timeless@bemail.org  2005-08-17 07:01 PDT
>run ./firefox -g -d gdb
>###!!! ASSERTION: garbled pattern: unexpected end of pattern: '*p', file
>nsFT2FontNode.cpp, line 433
>Break: at file nsFT2FontNode.cpp, line 433
>
>when you get to that get a stack trace. read the unix debugging faq if 
>necessary. dump the locals and such.

I'm sorry, I'm willing to do those things (I just installed gdb) but your
request seems to presume I'm a code jockey--and I haven't been that for
decades and certainly not on *nix systems.  It's a bit too sketchy for me
to interpret.  I DID refer to, and copy locally, the Mozilla Unix
debugging FAQ, but that too seems to presume one is a Mozilla
developer--and I'm VERRRY far from that!  (About the most advanced thing
I can do is make/install source tarballs on my LFS system, when the files
work--which isn't always.)   If somebody has the time and inclination to
be a bit more precise about doing this debugging, I'm more than happy to
cooperate (I DO want to fix this bug!), but I'm just not knowledgable
enough to do it myself as your other developers are.
I saw something about gtk "dying horribly" if it couldn't get the fonts it
wants.  Using that as a clue, I have a new test case:
<HTML><BODY>
&#8220;/32&#8221;
&#8220;all&#8221;&#8201;
</BODY></HTML>

That crashes.  Remove the "&" from those in the previous test case, and it
renders.  So it seems my system is missing some characters--it's probably not
Firefox's problem at all.  Still, if anybody can point me in the direction of
fixing this, I'd be appreciative.  (I've been trying to keep this system free of
I18N--I'm much to old to begin learning a new orthography.)
http://www.mozilla.org/build/
make sure your mozconfig (use the build configurator) includes --enable-debug

http://www.mozilla.org/unix/debugging-faq.html
It has been built with debug enabled, optimize disabled.
I'm sorry, I can't let you off the hook--this sucker IS a BUG (IMO), but I know
now how to work around this crash.  Firefox SHOULD NOT crash so ugly it takes X
down with it just because it cannot find a UTF character in the selected font!

The work-around I found is to change the Edit/Preferences/Fonts/"Fonts for" from
"Western" to "Unicode" and then select a font ending in ...iso-10646-1.  Yeah,
like that was supposed to be obvious, right?  Well, IT ISN'T!!!  I've been
plagued with this for 4 months!

Your drop-down window isn't wide enough to show the full name so one can select
the proper font when the name is long, so you need to add a horizontal scroll-bar.
p.s.  Even with the workaround it STILL crashes on Mozilla's own
Firefox/Product/Other Systems and Languages page!  Just what DO you have on there?
i'm not sure who you think is on hook. our toolkit code is mostly orphanned. if 
gtk is killing us or xfree/xorg are killing themselves then you need to find 
gtk/gdk/x11 hackers to guide you. i don't know where they live, they don't seem 
to live here :( -- if you find them, let me know so i can tap them in the 
future.
I'm a user, not a developer.  But from a user's perspective, it's VERY UNCOOL
for firefox to crash, take X with it, and because of what X does to the video &
kb, also make the console, hence the desktop computer itself, unusable.  I
haven't been able to identify just where the font rendering is being done.  I
don't know where it's happening, who's responsible, but firefox is where I'm
making the font selection, what is running when it crashes, so it appears
firefox is responsible.  If firefox is passing UTF characters off for rendering,
but the subsystem doing that can't handle UTF, what do you propose--circular
finger pointing?  Make sure the rendering subsystem in fact CAN handle the
characters you're passing it.  Don't do it otherwise.  This is a BUG.  It needs
to be fixed.  Give me a blot, a block, a "?", but crashing just isn't acceptable
to users.  What's next, a BSOD?

Firefox is out there competing with other browsers, it's got to establish it's
reputation.  Is finger pointing the reputation you want?  I'm sure Bill would be
happy for you to take that position.  I suggest firefox has to take the
responsibility to protect itself, and its users from unwarranted and unnecessary
system crashes.
I'm very inclined to WFM this one.  The reporter is using an oddball build.  None of the supposed testcases actually produce the alleged result.
May I suggest, since one of Linux's attractions is that one CAN build from scratch an optimized system (even if it is for a lowly Pentium), an adequate fix would be better instructions for non-developers to compile & build a properly configured Firefox?  I've tried to do it right, as best I could discover that, but there's something of a presumption in the site docs that Firefox users will either use a standard pre-built binary or be a participating developer, with nobody in the middle like me.  Even as I type, I am compiling Firefox-1.0.7 on a slightly cleaner version of my same LFS-4.1 system, still with GTK+-1.2.10, but this time using Xft to see if that works.  Thanks to whoever added the more standard "configure/make" approach!  That's a good thing.
Paul, can you reproduce the bug using the latest MOZILLA_1_8_BRANCH
code (or trunk)?
I'm currently using FF-1.5.0.11, compiled locally but with the same system, same script & configuration.  I just tried the code fragment above and it rendered without hosing the system.  8-)
Ok, thanks.

-> WORKSFORME
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: