Closed Bug 230733 Opened 21 years ago Closed 19 years ago

Browser crashes when opening this HTML file (with some strange CSS in it)

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: rew, Unassigned)

References

(
URL
)

Details

(Keywords: crash, stackwanted) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031210
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031210

While trying to figure out why Mozilla1.6b won't display pages to be proofed at
http://pgdp.net, I narrowed down the problem to a CSS issue with this file
(which is one frame on the pgdp.net page I'm after).

Imagine my surprise when commenting out one line of the CSS (line 87) causes
Mozilla to crash!  So I figured this was bug-worthy, since it's (a) critical
(Mozilla dies), and (b) repeatable every time.

I'm running on Linux, RH9, patched up pretty well current.

Reproducible: Always

Steps to Reproduce:
1. Fire up mozilla
2. Open this HTML file
3. Boom.

Actual Results:  
Crash.

Expected Results:  
Not crash. :)

Since it's a bit hard to load if it's crashing all the time, I created another
copy of the mozboom.html, moznoboom.html, that has line 87 uncommented.  It's
ugly, but it won't crash the browser.

The parent window of the browser looks like this after error:

[rew@oz]$ Gdk-ERROR **: BadValue (integer parameter out of range for operation)
  serial 21179 error_code 2 request_code 12 minor_code 0
Gdk-ERROR **: BadValue (integer parameter out of range for operation)
  serial 21180 error_code 2 request_code 12 minor_code 0

[rew@oz]$
can you attach a stacktrace from your crash ?

if you're using the standard mozilla startup script, just do
% mozilla -g -d gdb
(gdb) run
[wait for mozilla to crash]
(gdb) bt
(attach the output from "bt" via "create a new attachment")
Keywords: crash, stackwanted
Sorry, my version of mozilla doesn't apparently have any debugging symbols, so
all I get from bt is "No stack".

Where do I get one with debugging symbols to run?
can you try latest pre-1.6 build ?
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-1.6/
If you were using an XFT build (with anti-aliased fonts), you may want to try
the XFT Firebird build (pre-0.8):
http://ftp.mozilla.org/pub/mozilla.org/firebird/nightly/latest-0.8/
Downloaded the build you suggested, unpacked, installed, ran it:

(gdb) run
Starting program: /usr/local/mozilla/mozilla-bin
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...[New Thread 1077691488 (LWP 17583)]
(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...[New Thread
1097108272 (LWP 17584)]
[New Thread 1116957488 (LWP 17585)]
[New Thread 1125350192 (LWP 17586)]
[New Thread 1133742896 (LWP 17587)]
[New Thread 1142135600 (LWP 17588)]
[New Thread 1150528304 (LWP 17589)]
[Thread 1150528304 (LWP 17589) exited]
Couldn't get registers: No such process.
(gdb) bt
Cannot fetch general-purpose registers for thread 1097108272: generic error
(gdb)

Now what?
I should say, more specifically, this build:

http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-1.6/mozilla-i686-pc-linux-gnu-full-installer.tar.gz

Was that the right one?
The URL in the URL field has, on line 87:

//   position:absolute;

Is that supposed to be commented?  (It's not a comment, just a syntax error.) 
If I remove the "//", should this crash?  Because I just tried that, and I see
no crash with a current trunk Linux build.

Reporter, have you been testing gtk2 builds (see about:buildconfig)?  If so,
could you test a GTK1 build?  The one you tested in comment 4 will do; just
don't run it in gdb.  Better yet would be to test a current trunk nightly, but....
No, if you remove the '//' in line 87, it won't crash.  The point is, I don't
think it should crash just because you pass it some bogus CSS.  That was why I
filed the bug.

I made the bogus CSS because (1) I know almost nothing about CSS, but (2) still
had to try to track down why Mozilla 1.6b no longer works with the Project
Gutenberg Distributed Proofreading project, where I volunteer. 1.5 works.  1.6b
worked for a while.  Now it doesn't.

In trying to figure *that* out, I discovered that putting the '//' on line 87
will cause the browser to crash. Hence my bug report.
The URL in the URL field has, on line 87:

//   position:absolute;

Is that supposed to be commented?  (It's not a comment, just a syntax error.) 
If I remove the "//", should this crash?  Because I just tried that, and I see
no crash with a current trunk Linux build.

I looked at about:buildconfig and could see no mention of either gtk1 or gtk2 in
the output.  So I don't know which it is.

I notice this bug is still marked as UNCONFIRMED.  Does that mean that no one
else who's looked at it has seen it crash when trying to load the mozboom.html
URL that I listed?
> No, if you remove the '//' in line 87, it won't crash.

Ah, ok.  So just loading the URL in the URL field crashes for you.  Gotcha.

> the point is, I don't think it should crash

Agreed.  ;)

> I looked at about:buildconfig and could see no mention of either gtk1 or gtk2

Then that's a gtk1 build.  And it crashes?  What's the exact build id on that
build, if so?  You never said whether the current 1.6 build you tried crashes...

The problem is, indeed, that I can't reproduce the crash by loading the page at
http://www.swampfox.net/~rew/mozboom.html (in either a current trunk nightly or
the build I got from
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-1.6/mozilla-i686-pc-linux-gnu.tar.gz).
> Ah, ok.  So just loading the URL in the URL field crashes for you.

Yup.  As soon as I click on that link and the page starts loading, BOOM, no more
mozilla.

> I looked at about:buildconfig and could see no mention of either gtk1 or gtk2

> What's the exact build id on that build, if so?  

I think the Build Identifier is listed at the top of this bug report, of the
1.6b that I was using.

The Build Ident of the nightly trunk version I tried is

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040109

At least, I think that's the build ID.

> You never said whether the current 1.6 build you tried crashes...

Sorry, yes, the nightly build I tried also crashes.

> that I can't reproduce the crash by loading the page at ...mozboom.html

Shoot.  Well, I was hoping that it would help to track down some nasty bug. 
Crashes quite reliably for me. :)

So I'm guessing there is some nasty cross-up with libraries or something on my
system here that make it susceptible, and I might be barking up the wrong tree.

However, if I could get a version with debugging symbols, I could at least
produce a backtrace, if that would help.  I just don't know.

For what it's worth, I downloaded this Firebird build:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

and it handles the bad CSS page fine, as well as the pgdp.net stuff that
originally got me chasing this problem.

Perhaps it's time I just migrated over to Firebird anyway. :)
Getting a version with debug symbols involves building yourself (it would be a
200-some meg download)...  If you're willing to do it (and have the 2 gigs of
disk space needed), I can try to point you to the docs on it.

Could you possibly try a build from
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/ (trunk nightly),
that would be great.

Thanks for helping track this down!
Hmm.  I would guess this is a dup of the CreateNative bug that has some dups. 
That's been fixed for 1.6.
Blocks: gtk2
do you still crash with Mozilla 1.7rc2 ? If so, please post Talkback Incident ID
for this crash by running "mozilla/components/talkback/talkback"
testcase WFM in current Linux trunk.
Product: Browser → Seamonkey
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.