Crash at startup when built with gcc-3.4.1, --enable-optimize='-march=pentium4 -O3' [@ nsXMLContentSink::HandleStartElement]

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
14 years ago
2 years ago

People

(Reporter: jsberg, Unassigned)

Tracking

({crash})

Trunk
x86
Linux
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(3 attachments)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.1) Gecko/20040716
Build Identifier: ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7.1/src/mozilla-source-1.7.1.tar.bz2

Here's my .mozconfig:

export MOZILLA_OFFICIAL=1
export BUILD_OFFICIAL=1
export MOZ_INTERNAL_LIBART_LGPL=1
ac_add_options --with-ft-prefix=/opt/freetype
ac_add_options --with-system-jpeg=/opt/jpeg-6b
ac_add_options --with-system-zlib
ac_add_options --with-system-png=/opt/libpng-1.2.5
ac_add_options --enable-default-toolkit=gtk2
ac_add_options --enable-xft
ac_add_options --enable-crypto
ac_add_options --enable-ctl
ac_add_options --enable-xinerama
ac_add_options --enable-extensions="all"
ac_add_options --enable-image-decoders="all"
ac_add_options --enable-svg
ac_add_options --enable-svg-renderer-libart
ac_add_options --disable-tests
ac_add_options --enable-reorder
ac_add_options --enable-elf-dynstr-gc
ac_add_options --enable-old-abi-compat-wrappers
ac_add_options --enable-cpp-rtti
ac_add_options --enable-cpp-exceptions
ac_add_options --enable-strip
ac_add_options --disable-debug
ac_add_options --enable-optimize='-march=pentium4 -O3'

Mozilla segfaults at first startup, before even producing a window.  If I use
-O2 instead of -O3 in the last line, it's fine.  If I instead comment out the
--enable-strip and --disable-debug lines, it's fine.

Compliler is gcc-3.4.1.  Other relevant packages: gnome-2.6.2 (right from
gnome.org), freetype-2.1.9, fontconfig-2.2.3, X is x.org 6.7.0.


Reproducible: Always
Steps to Reproduce:
1. configure --prefix=/opt/mozilla-1.7.1; make; make install
2. rm -rf ~/.mozilla
3. mozilla

Actual Results:  
segfaults
(Reporter)

Comment 1

14 years ago
Created attachment 153416 [details] [diff] [review]
First freetype-2.1.9 patch

Almost forgot: it was built with two patches to make freetype-2.1.9 work!
(Reporter)

Comment 2

14 years ago
Created attachment 153417 [details] [diff] [review]
Second freetype-2.1.9 patch

Updated

14 years ago
Assignee: general → nobody
Component: Browser-General → Build Config
QA Contact: general → core.build-config

Updated

14 years ago
Severity: normal → critical
Keywords: crash

Updated

14 years ago
Blocks: 249358
Same over here:

Changing -O2 to -O3 make mozilla crash at start.

Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8a5) Gecko/20041020

about:buildconfig

Build platform
target
i686-pc-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
gcc-3.4 	gcc version 3.4.2 (Debian 3.4.2-3) 	-Wall -W -Wno-unused
-Wpointer-arith -Wcast-align -Wno-long-long -pedantic -g -W -Wall -O2
-march=athlon-xp -pthread -pipe
g++-3.4 	gcc version 3.4.2 (Debian 3.4.2-3) 	-fno-rtti -fno-exceptions -Wall
-Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -g -W
-Wall -O2 -march=athlon-xp -fshort-wchar -pthread -pipe -I/usr/X11R6/include

Configure arguments
--with-system-jpeg --with-system-zlib --with-system-png
--enable-default-toolkit=gtk2 --enable-xft --disable-freetype2 --disable-ldap
--enable-official-branding --enable-crypto --disable-accessibility
--disable-tests '--enable-optimize=-O2 -march=athlon-xp' --enable-reorder
--enable-extensions=default,-irc --disable-mailnews 

Comment 4

14 years ago
These crash reports aren't helpful without a stack trace.

The freetype issue is covered in bug 234035.

Will try to produce a stack trace next week.
Created attachment 163353 [details]
Backtrace of crash

Here comes the promised Backtrace.
Please notice that I did not apply any patches to mozilla source tree.

If you need more information please tell me what that would be.

Comment 7

14 years ago
==> parser
Assignee: nobody → parser
Component: Build Config → HTML: Parser
QA Contact: core.build-config → mrbkap
Summary: Crash at startup when built with gcc-3.4.1, --enable-optimize='-march=pentium4 -O3' → Crash at startup when built with gcc-3.4.1, --enable-optimize='-march=pentium4 -O3' [@ nsXMLContentSink::HandleStartElement]

Comment 8

14 years ago
Confirming. I'm also experiencing this with current trunk builds of firefox and
thunderbird. In my case I'm compiling with gcc 3.3.2 on mandrake linux 10.0. The
problem only occurs when building without --enable-debug; I'm currently
troubleshooting with a copy of thunderbird configured as follows:

. $topsrcdir/mail/config/mozconfig

ac_add_options --disable-installer
ac_add_options --disable-ldap
ac_add_options --disable-pedantic
ac_add_options --disable-tests
ac_add_options --disable-trace-malloc
ac_add_options --enable-crypto
ac_add_options --enable-default-toolkit=gtk2
ac_add_options --enable-optimize='-O3 -march=athlon-xp -momit-leaf-frame-pointer'
ac_add_options --disable-freetype2
ac_add_options --with-system-mng
ac_add_options --with-system-png
ac_add_options --with-system-zlib

The actual crash is around line 1037 of nsXMLContentSink.cpp,
<http://lxr.mozilla.org/seamonkey/source/content/xml/document/src/nsXMLContentSink.cpp#1037>.
The variable "content" contains NULL because CreateElement() at line 1033 set
"content" to NULL and then returned NS_OK.

By inserting fprintf() calls I've traced this through NS_NewElement() in
content/base/src/nsSpaceManager.cpp to NS_NewHTMLElement() in
content/html/document/src. At line 1009 of NS_NewHTMLElement()
<http://lxr.mozilla.org/seamonkey/source/content/html/document/src/nsHTMLContentSink.cpp#1009>
there is a call to CallQueryInterface() which is supposed to initialize an
argument aResult and to return an nsresult. For some reason this function is
returning NS_OK but leaving *aResult set to NULL. These values propagate back to
nsXMLContentSink::HandleStartElement and lead to the crash. 
Status: UNCONFIRMED → NEW
Ever confirmed: true
Can you track this down to a specific nsHTML*Element's QueryInterface() doing
the wrong thing (which is unlikely), or is this just a gcc optimizer bug that
causes bad code to be generated? We've seen those before...

Comment 10

14 years ago
The QueryInterface() call in question (comment 8) resolves to
nsHTMLInputElement::QueryInterface(). Here's a partial stack trace from the
eventual AddRef() call:

#0  0x41707a74 in nsGenericElement::AddRef () from
/extra/kherron/moz/tb/dist/bin/components/libgklayout.so
#1  0x417aa611 in nsHTMLInputElement::AddRef () from
/extra/kherron/moz/tb/dist/bin/components/libgklayout.so
#2  0x417078e6 in nsGenericElement::QueryInterface ()
   from /extra/kherron/moz/tb/dist/bin/components/libgklayout.so
#3  0x4177d6db in nsGenericHTMLFormElement::QueryInterface ()
   from /extra/kherron/moz/tb/dist/bin/components/libgklayout.so
#4  0x417aa682 in nsHTMLInputElement::QueryInterface ()
   from /extra/kherron/moz/tb/dist/bin/components/libgklayout.so
#5  0x417e5ee0 in NS_NewHTMLElement () from
/extra/kherron/moz/tb/dist/bin/components/libgklayout.so

nsGenericHTMLFormElement::QueryInterface isn't supposed to directly call
nsGenericElement::QueryInterface; in the source, nsGenericHTMLFormElement calls
nsGenericHTMLElement which calls nsGenericElement. I believe
nsGenericHTMLElement was inlined; when I compiled nsGenericHTMLElement.cpp with
-O2, nsGenericHTMLElement::QueryInterface was included in the call stack.

To the point, recompiling nsHTMLInputElement.cpp with less optimization had no
effect, but recompiling nsGenericHTMLElement.cpp (which contains the
nsGenericHTML* code) with -O2 instead of -O3 allows thunderbird to start and run
normally.
So... sounds like either an aliasing issue when the QI method is inline or a
compiler bug.

Comment 12

14 years ago
As a check, I built a copy of thunderbird configured as in comment 8, but using
gcc built from the head of their CVS (which will become gcc 4.0). The resulting
program doesn't exhibit this bug, although it has some minor problems I won't
detail. This lends further support to the idea that a compiler bug is involved here.
Assignee: parser → nobody
QA Contact: mrbkap → parser
(Assignee)

Updated

7 years ago
Crash Signature: [@ nsXMLContentSink::HandleStartElement]

Comment 13

4 years ago
Reporter Scott writes "It's been a few years since I've built my own Thunderbird (I used to roll my own system back then), so I'm afraid I haven't tested it for quite a while,"

perhaps this can be closed?

FWIW, crashes with nsXMLContentSink::HandleStartElement] in signature ...

https://crash-stats.mozilla.com/query/?product=Firefox&version=ALL%3AALL&range_value=4&range_unit=weeks&date=05%2F05%2F2014+11%3A00%3A00&query_search=signature&query_type=contains&query=nsXMLContentSink%3A%3AHandleStartElement&reason=&release_channels=&build_id=&process_type=any&hang_type=any
You need to log in before you can comment on or make changes to this bug.