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

Status: RESOLVED WORKSFORME

(Core :: DOM: HTML Parser, defect)

Description

[J. Scott Berg]

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

Comment 1

[J. Scott Berg]

Attachment: First freetype-2.1.9 patch

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

Comment 2

[J. Scott Berg]

Attachment: Second freetype-2.1.9 patch

Comment 3

[Stefan Fleiter (:sfleiter)]

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

[cls]

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

The freetype issue is covered in bug 234035.

Comment 5

[Stefan Fleiter (:sfleiter)]

Will try to produce a stack trace next week.

Comment 6

[Stefan Fleiter (:sfleiter)]

Attachment: 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

[Andrew Schultz]

==> parser

Comment 8

[Kenneth Herron]

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. 

Comment 9

[Johnny Stenback (:jst)]

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

[Kenneth Herron]

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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

So... sounds like either an aliasing issue when the QI method is inline or a
compiler bug.

Comment 12

[Kenneth Herron]

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.

Comment 13

[Wayne Mery (:wsmwk)]

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

Comment 14

[Wayne Mery (:wsmwk)]

none of these are linux crashes
https://crash-stats.mozilla.com/signature/?signature=nsXMLContentSink%3A%3AHandleStartElement&date=%3E%3D2016-10-11T12%3A05%3A00.000Z&date=%3C2016-10-18T12%3A05%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_sort=-date&page=1