283811 - Firefox fails to start up due to a miscompiled file with FC3 gcc

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[jim_nance]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050225 Firefox/1.0+

If I compile firefox on a Fedora FC3 system using --enable-optimize
--disable-debug, firefox fails to start.  It appears to hang, consuming all
available CPU.  I have tracked this down to what appears to be a compiler bug
(gcc-3.4.2-6.fc3) causing nsAttrValue.cpp to be miscompiled.  Here is what I
know so far.  If nsAttrValue.cpp is compiled with -O or -O1, the browser hangs.
 If it is compiled with -Os or w/o a -O flag, then the browser works. 
nsAttrValue.cpp is the only file which must be recompiled.  I can leave the
other files alone.  The stack trace always looks like this:

(gdb) bt 5
#0  nsAttrValue::ToString (this=0x83eff90, aResult=@0xbfffde2c)
    at nsAttrValue.h:382
#1  0x40b307a0 in nsXULElement::GetAttr ()
   from dist/bin/components/libgklayout.so
#2  0x409d566f in SelectorMatches ()
   from dist/bin/components/libgklayout.so
#3  0x409d5c53 in ContentEnumFunc ()
   from dist/bin/components/libgklayout.so
#4  0x409cf42f in RuleHash::EnumerateAllRules ()

nsAttrValue::ToString() never returns.

Reproducible: Always

Comment 1

[jim_nance]

Attachment: .mozconfig file to show the problem

This mozconfig file will build a bad firefox on Fedora FC3

Comment 2

[jim_nance]

Attachment: Patch to fix the problem

This patch fixes the problem.

Comment 3

[Bernd]

Comment on attachment 175675 [details] [diff] [review]
Patch to fix the problem

I am not an sr but David can r/sr

Comment 4

[Mike Connor [:mconnor]]

Hmm, this is a dupe, I think, iirc its a gcc bug in the FC3 version, which
bryner exposed with some of the visibility stuff.

--enable-optimize="-O2" works just fine, fwiw.

Comment 5

[Chase Phillips]

(In reply to comment #4)
> Hmm, this is a dupe, I think, iirc its a gcc bug in the FC3 version, which
> bryner exposed with some of the visibility stuff.

If the patch leads to equivalent code but also allows more compilers to generate
correct optimization behaviour, we should consider it.  What do you think?

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Have the appropriate gcc bugs been filed?  (Are they Fedora specific or also in
released gcc versions?)

Comment 7

[Mike Connor [:mconnor]]

I don't remember whether its specific to FC3's gcc version, but I seem to recall
something about Fedora backporting fixes from 3.4.3 to their 3.4.2 package being
to blame.  I know bryner's filed bugs and attached patches on gcc on issues
related to visibility, but he didn't get any response.

Brian, is this patch ok?

Comment 8

[jim_nance]

I have not filed gcc bugs, primarily because I don't know how/where to do so.

Comment 9

[jim_nance]

(In reply to comment #4)

> --enable-optimize="-O2" works just fine, fwiw.

Interesting.  I have reproduced it with -O and -O1, I didn't try -O2.  I did try
-Os and the bug does not show up with that flag.

Comment 10

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I'm not enthusiastic about taking patches like this if appropriate gcc bugs
aren't filed.  Then there's nothing that would cause gcc to fix the underlying bug.

(That said, it also doesn't seem like very high priority to me, since I hope
most people use -O2 rather than -O.)

Comment 11

[jim_nance]

David - I think the bug does happen with -O2.  It definitly happens if you just
specify --enable-optimize in the mozconfig file, because that is how I found it.

The bug does not happen with -Os, which is how the firefox downloads are built.
 I guess this is why this bug is not killing everyone.  Perhaps the best
solution is to have --enable-optimize to use -Os by default rather than -O or
whatever the current default is.  That has consequences on other platforms and
with other compilers that I can't test, so I don't think it should be done lightly.

Any suggestions on the logistics of submitting a gcc bug?  I don't know where to
send it, and I don't want to have to send them all of mozilla to demonstrate the
problem.

Comment 12

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

The build I'm typing this in was built with FC3's gcc with -O2.

Comment 13

[jim_nance]

David, how does your .mozconfig file compare to the one I have attached to this bug?

Comment 14

[cls]

I've hit this bug on FC3 as well.  What I've seen is that my suite builds do not
start regardless of the -O setting unless I use -fno-inline.  My firefox build
(when I tested weeks ago) was fine using -O2.

For my builds, more than just nsAttrValue.cpp needed to be rebuilt to fix the
problem.  I wound up recompiling all of layout & content on the assumption that
anything that used nsAttrValue.h would be affected.

Comment 15

[jim_nance]

Chris, does my patch fix your problem?

Comment 16

[cls]

Yes, it does.

Comment 17

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Comment on attachment 175675 [details] [diff] [review]
Patch to fix the problem

Fine, r+sr=dbaron, but I'd really prefer if you filed a GCC bug at http://gcc.gnu.org/bugzilla/ if this is still a problem with current GCC.

Comment 18

[jim_nance]

Wow, I thought this bug had fallen off the Radar.

I'll verify that the problem still exists, patch it if it does, and submit a gcc bug if necessary.  I'm now running FC4, so if the bugs gone, I may need someone with an FC3 system to help me.

Comment 19

[jim_nance]

Just checked the patch in.  This bug does NOT occur on an FC4 system, which indicates that the gcc people have fixed the bug.