187022 - segv in nsCOMPtr_base::assign_from_helper called from nsTypeAheadFind::AttachWindowListeners

Status: RESOLVED INVALID

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Michael Sinz]

For the past few days, a clean/fresh build from mozilla trunk (cvs) would
produce a mozilla that would crash before opening the first window.

The .mozconfig used for the build is:

# Options for 'configure' (same as command-line options).
ac_add_options --enable-crypto
ac_add_options --disable-debug
ac_add_options --enable-optimize="-g -O2 -march=i686"
ac_add_options --disable-ldap
ac_add_options --disable-bidi
ac_add_options --disable-tests
ac_add_options --enable-reorder


Removing the "--disable-debug" will make the browser start up and run.

The traceback is as follows:

(gdb) run -P
[New Thread 1024 (LWP 27470)]
[New Thread 2049 (LWP 27492)]
[New Thread 1026 (LWP 27493)]
[New Thread 2051 (LWP 27494)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 27470)]
0x401b995a in nsCOMPtr_base::assign_from_helper (this=0xbfffe510,
helper=@0xbfffe500, iid=@0x405c85b8) at nsCOMPtr.h:435
/usr/src/mozilla-trunk/mozilla/xpcom/glue/nsCOMPtr.h:435:13253:beg:0x401b995a
(gdb) where
#0  0x401b995a in nsCOMPtr_base::assign_from_helper (this=0xbfffe510,
helper=@0xbfffe500, iid=@0x405c85b8) at nsCOMPtr.h:435
#1  0x405c34f8 in nsTypeAheadFind::AttachWindowListeners (this=0x80fa3c8,
aDOMWin=0x811987c) at ../../../dist/include/xpcom/nsISupportsUtils.h:243
#2  0x405bcce8 in nsTypeAheadFind::Observe (this=0x80fa3c8, aSubject=0x8119878,
aTopic=0x405b3ee3 "domwindowopened", aData=0x0) at
../../../dist/include/xpcom/nsCOMPtr.h:643
#3  0x40131c4f in nsObserverService::NotifyObservers (this=0x80ed1b8,
aSubject=0x8119878, aTopic=0x405b3ee3 "domwindowopened", someData=0x0) at
../../dist/include/xpcom/nsCOMPtr.h:649
#4  0x40594da2 in nsWindowWatcher::AddWindow (this=0x80fe5a0, aWindow=0x811987c,
aChrome=0x0) at ../../../../dist/include/xpcom/nsCOMPtr.h:649
#5  0x40a42353 in nsAppShellService::RegisterTopLevelWindow (this=0x81582c0,
aWindow=0x81379b8) at ../../../dist/include/xpcom/nsCOMPtr.h:649
#6  0x40a41a9b in nsAppShellService::CreateTopLevelWindow (this=0x81582c0,
aParent=0x0, aUrl=0x0, aShowWindow=0, aLoadDefaultPage=0,
aChromeMask=4160750598, aInitialWidth=-1, aInitialHeight=-1, aResult=0xbfffe940)
at nsAppShellService.cpp:691
#7  0x08054c28 in nsWindowCreator::CreateChromeWindow2 (this=0x811b648,
aParent=0x0, aChromeFlags=4160750598, aContextFlags=0, _retval=0xbfffebd0) at
../../dist/include/xpcom/nsCOMPtr.h:649
#8  0x40593689 in nsWindowWatcher::OpenWindowJS (this=0x80fe5a0, aParent=0x0,
aUrl=0x811c138 "chrome://communicator/content/profile/profileSelection.xul",
aName=0x40b5c2a1 "_blank", aFeatures=0x40b5bf00
"centerscreen,chrome,modal,titlebar", aDialog=1, argc=1, argv=0x814b380,
_retval=0xbfffeea0) at ../../../../dist/include/xpcom/nsCOMPtr.h:649
#9  0x40592e1a in nsWindowWatcher::OpenWindow (this=0x80fe5a0, aParent=0x0,
aUrl=0x811c138 "chrome://communicator/content/profile/profileSelection.xul",
aName=0x40b5c2a1 "_blank", aFeatures=0x40b5bf00
"centerscreen,chrome,modal,titlebar", aArguments=0x811c178, _retval=0xbfffeea0)
at nsWindowWatcher.cpp:459
#10 0x40b4b1ab in nsProfile::LoadDefaultProfileDir (this=0x811bac8,
profileURLStr=@0xbffff1b0, canInteract=1) at ../../dist/include/xpcom/nsCOMPtr.h:649
#11 0x40b49ec2 in nsProfile::StartupWithArgs (this=0x811bac8,
cmdLineArgs=0x80f9ec0, canInteract=1) at nsProfile.cpp:357
#12 0x40a3fa10 in nsAppShellService::DoProfileStartup (this=0x81582c0,
aCmdLineService=0x80f9ec0, canInteract=1) at
../../../dist/include/xpcom/nsCOMPtr.h:649
#13 0x0804fb1c in InitializeProfileService (cmdLineArgs=0x80f9ec0) at
../../dist/include/xpcom/nsCOMPtr.h:649
#14 0x0804ec60 in main1 (argc=2, argv=0xbffff634, nativeApp=0x808a1c0) at
../../dist/include/xpcom/nsCOMPtr.h:643
#15 0x0804de6b in main (argc=2, argv=0xbffff634) at nsAppRunner.cpp:1904
#16 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6

Comment 1

[Michael Sinz]

It seems that it is related to the new Type Ahead Find stuff but I don't have
time at the moment to track that down.

Comment 2

[Boris Zbarsky [:bzbarsky]]

To aaronl.  Unsetting various flags reporter should not be setting....

Comment 3

[Boris Zbarsky [:bzbarsky]]

.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

The only unchecked thing I can see is the QI of chromeEventHandler to
nsIDOMEventReceiver.  Mike, try adding "if (chromeEventReceiver)" around the two
calls that use it at the bottom of  nsTypeAheadFind::AttachWindowListeners in
extensions/typeaheadfind/src/nsTypeAheadFind.cpp.

Comment 5

[Asa Dotzler [:asa]]

I don't see this anywhere in the topcrash talkback data so probably not a blocker.

Comment 6

[Michael Sinz]

It seems to only be a problem when the binary is compiled on some of my systems.
 (Basically, RedHat 7.3 systems)  I have not tracked it down due to life
conditions getting in the way.

Comment 7

[Michael Sinz]

Well, after a long time of playing with this, it finally hit me.  (I must have
been really slow on this)

The difference between my systems that show this problem and the ones that don't
is the version of GCC.  The GCC 2.95 and GCC 2.96 (RedHat 7.3 GCC 2.96-113)
systems show the problem and the GCC 3.1 and GCC 3.2 systems do not.  And, even
more confusing is that one of the GCC 2.96 systems did not show the problem.

It turns out that all of my GCC 2.96 (and 2.95) systems show this problem is if use:

ac_add_options --enable-optimize="-O2 -march=i686"

If I comment out that setting in my .mozconfig, all is better (well, other that
the lack of optimization :-().  So, something in the optimizer produces bad code
in Mozilla with the versions of GCC on some of my systems.

For this reason, I would say that this bug is no longer a Mozilla bug but a GCC
bug.  (I guess the best is to mark it as invalid...)

BTW - Mozilla used to build just fine before I reported this bug but I got off
on another project and then worked mainly on GCC 3.x systems and did not notice
when this happened, but I would doubt that it is the fault of any Mozilla code
being wrong but rather that something just pushed the wrong parts of the
compiler and it broke...