Closed Bug 249475 Opened 20 years ago Closed 11 years ago

segfault: in non-virtual thunk to nsDirectoryService::AddRef() ()

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
Other
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: jmarca, Unassigned)

References

Details

(Keywords: crash)

Attachments

(1 file)

backtrace of ./mozilla/dist/bin/TestXPTCInvoke (segfaults)
1.06 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040224 Firefox/0.8
Build Identifier: Mozilla 1.7 release &  Firefox/0.9.1, AMD64

Trying to build Firefox 0.9, 0.9.1, Mozilla 1.7, 1.8+.  on AMD64.  All fail with
this same segfault (more or less).  I suspect it is a problem with something
I've built, as I have built this entire system from scratch by modifying
Slackware 9.1/10 build scripts.  Any pointers to what libraries might be
involved so I can try recompiling those?

these details from gdb bt output for Firefox 0.9.1.  

Program received signal SIGSEGV, Segmentation fault.
0x0000002a95924bd2 in non-virtual thunk to nsDirectoryService::AddRef() ()
   from /usr/lib64/firefox-0.9.1/libxpcom.so
(gdb) bt
#0  0x0000002a95924bd2 in non-virtual thunk to nsDirectoryService::AddRef() ()
   from /usr/lib64/firefox-0.9.1/libxpcom.so
#1  0x0000002a95923b46 in nsDirectoryService::QueryInterface (this=0x1dcffe0, 
    aIID=@0x15af9c0, aInstancePtr=0x2a95b01a70) at nsDirectoryService.cpp:560
#2  0x0000002a9592370a in nsDirectoryService::Create (outer=0x0, 
    aIID=@0x15af9c0, aResult=0x2a95b01a70) at nsDirectoryService.cpp:433
#3  0x0000002a958f173b in NS_InitXPCOM2 (result=0x7fbfffec30, 
    binDirectory=0x1d7e3b0, appFileLocationProvider=0x7fbffff3e0)
    at nsXPComInit.cpp:457
#4  0x000000000159b25e in ScopedXPCOMStartup::Initialize (this=0x7fbfffec30)
    at nsAppRunner.cpp:891
#5  0x000000000159c924 in ImportProfiles (aPService=0x1dcf520, 
    aNative=0x1dcf330) at nsAppRunner.cpp:1381
#6  0x000000000159cf63 in SelectProfile (aResult=0x7fbffff3c0, 
    aNative=0x1dcf330, aStartOffline=0x7fbffff35c) at nsAppRunner.cpp:1487
#7  0x000000000159dd6b in xre_main (argc=1, argv=0x7fbffff4c8, 
    aAppData=0x15aeb40) at nsAppRunner.cpp:1783
#8  0x0000000000966058 in main (argc=1, argv=0x7fbffff4c8)
    at nsBrowserApp.cpp:58

My build flags are as follows:
CFLAGS="-fPIC" \
LDFLAGS="-L/lib64 -L/usr/lib64" \
./configure --prefix=/usr \
    --libdir=/usr/lib64 \
    --x-libraries=/usr/X11R6/lib64  \
    --disable-composer \
    --with-x \
    --with-system-jpeg \
    --with-system-zlib \
    --with-system-png \
    --with-system-mng \
    --disable-mailnews \
    --disable-calendar \
    --disable-pedantic \
    --disable-svg \
    --enable-mathml \
    --without-system-nspr \
    --enable-nspr-autoconf \
    --enable-xsl \
    --enable-crypto \
    --with-java-supplement \
    --with-pthreads \
    --with-default-mozilla-five-home=/usr/lib64/MozillaFirefox \
    --with-user-appdir=.firefox \
    --disable-jsd \
    --disable-accessibility \
    --disable-tests \
    --enable-debug \
    --disable-dtd-debug \
    --disable-logging \
    --enable-cpp-rtti \
    --enable-xterm-updates \
    --disable-ldap \
    --disable-toolkit-qt \
    --disable-toolkit-xlib \
    --enable-extensions=default,-irc,-venkman,-content-packs,-help \
    --enable-toolkit-gtk2 \
    --enable-default-toolkit=gtk2 \
    --disable-toolkit-gtk \
    --enable-xft \
    --disable-freetype2 \
    --disable-optimize \
    --disable-shared \
    --enable-static \
    --enable-single-profile \
    --disable-profilesharing



Reproducible: Always
Steps to Reproduce:
crashes when run from mozilla/dist/bin/mozilla mozilla/dist/bin/firefox, etc
tried both shared and static, always the same problem.


Actual Results:  
see crash backtrace above


when running firefox -g (similar with mozilla), I get:
...
(gdb) run
Starting program: /usr/lib64/firefox-0.9.1/firefox-bin 

Program received signal SIGSEGV, Segmentation fault.
0x0000002a95924bd2 in non-virtual thunk to nsDirectoryService::AddRef() ()
   from /usr/lib64/firefox-0.9.1/libxpcom.so
(gdb) bt
#0  0x0000002a95924bd2 in non-virtual thunk to nsDirectoryService::AddRef() ()
   from /usr/lib64/firefox-0.9.1/libxpcom.so
#1  0x0000002a95923b46 in nsDirectoryService::QueryInterface (this=0x1dcffe0, 
    aIID=@0x15af9c0, aInstancePtr=0x2a95b01a70) at nsDirectoryService.cpp:560
#2  0x0000002a9592370a in nsDirectoryService::Create (outer=0x0, 
    aIID=@0x15af9c0, aResult=0x2a95b01a70) at nsDirectoryService.cpp:433
#3  0x0000002a958f173b in NS_InitXPCOM2 (result=0x7fbfffec30, 
    binDirectory=0x1d7e3b0, appFileLocationProvider=0x7fbffff3e0)
    at nsXPComInit.cpp:457
#4  0x000000000159b25e in ScopedXPCOMStartup::Initialize (this=0x7fbfffec30)
    at nsAppRunner.cpp:891
#5  0x000000000159c924 in ImportProfiles (aPService=0x1dcf520, 
    aNative=0x1dcf330) at nsAppRunner.cpp:1381
#6  0x000000000159cf63 in SelectProfile (aResult=0x7fbffff3c0, 
    aNative=0x1dcf330, aStartOffline=0x7fbffff35c) at nsAppRunner.cpp:1487
#7  0x000000000159dd6b in xre_main (argc=1, argv=0x7fbffff4c8, 
    aAppData=0x15aeb40) at nsAppRunner.cpp:1783
#8  0x0000000000966058 in main (argc=1, argv=0x7fbffff4c8)
    at nsBrowserApp.cpp:58
Severity: normal → critical
Keywords: crash
The first thing I noticed is that "this" in the QueryInterface call is rather
small compared to the rest. Not sure what that means, I don't have a lot of
experience in 64 bit systems.

Can you run TestXPTCInvoke.exe without crashing?
(In reply to comment #1)
...
> Can you run TestXPTCInvoke.exe without crashing?

I will recompile with tests enabled and see.  


/mozilla/dist/bin/TestXPTCInvoke segfaults as well, backtrace attached.

Two notes:  First, I am newbie at gdb and at bugzilla.	Second, many of the
tests from xpcom fail (found using  file * | grep xpcom in the dist/bin
directory).  Some fail with a complaint about relocation error, others fail
with segfaults very similar to the original I reported.  What other tests might
be interesting?
Recompiling with GCC-3.4.1 on x86_64 fixes the problem, for Firefox 0.9+ and
Mozilla 1.7+, (following up on a tip reported in the Debian AMD64 mailing list)
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
I don't see any code has having been checked in, so it looks like nothing was
broken or fixed in Mozilla.

->WORKSFORME
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WORKSFORME
*** Bug 286308 has been marked as a duplicate of this bug. ***
still broken according to bug 286308.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
yes this happends for me also as reported in the duplicate bug.

My stackTrace
Program received signal SIGSEGV, Segmentation fault.
0x0000002a95848432 in non-virtual thunk to nsDirectoryService::AddRef() () from
./libxpcom_core.so
(gdb) bt
#0  0x0000002a95848432 in non-virtual thunk to nsDirectoryService::AddRef() ()
from ./libxpcom_core.so
#1  0x0000002a95847358 in nsDirectoryService::QueryInterface (this=0x568a40,
aIID=@0x4123d0, aInstancePtr=0x2a95a256e8)
    at
/home/henrik/Projects/Mozilla/Source/mozilla/xpcom/io/nsDirectoryService.cpp:538
#2  0x0000002a95846f1c in nsDirectoryService::Create (outer=0x0, aIID=@0x4123d0,
aResult=0x2a95a256e8) at
/home/henrik/Projects/Mozilla/Source/mozilla/xpcom/io/nsDirectoryService.cpp:417
#3  0x0000002a958143bc in NS_InitXPCOM2_P (result=0x0, binDirectory=0x0,
appFileLocationProvider=0x0) at
/home/henrik/Projects/Mozilla/Source/mozilla/xpcom/build/nsXPComInit.cpp:477
#4  0x000000000040aaf3 in main (argc=1, argv=0x7fbffff538) at
/home/henrik/Projects/Mozilla/Source/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1751


I have tried the smaller test programs and they also fails, mostly with a no
such file on libxpcom_core.so

I am running:
Amd64
Ubuntu Hoary (debian)
gcc (GCC) 3.3.5 (Debian 1:3.3.5-8ubuntu2)

Will try with gcc 3.4, but even if that works, we should still try and  fix
this, or at least put in a build faq.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Just some extra information, I can workaround this bug by using gcc 3.4.


Appears to not work with g++-4.0 either (this is a xulrunner trunk build on
amd64 linux ubuntu breezy):

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912567075184 (LWP 3032)]
0x00002aaaab455892 in non-virtual thunk to nsDirectoryService::AddRef() () from
../../../dist/bin/libxul.so
(gdb) bt
#0  0x00002aaaab455892 in non-virtual thunk to nsDirectoryService::AddRef() ()
from ../../../dist/bin/libxul.so
#1  0x00002aaaab454e82 in nsDirectoryService::QueryInterface () from
../../../dist/bin/libxul.so
#2  0x00002aaaab454b9e in nsDirectoryService::Create () from
../../../dist/bin/libxul.so
#3  0x00002aaaab43a840 in NS_InitXPCOM2_P () from ../../../dist/bin/libxul.so
#4  0x00002aaaab4b8219 in ScopedXPCOMStartup::Initialize () from
../../../dist/bin/libxul.so
#5  0x00002aaaab4bb5ff in XRE_main () from ../../../dist/bin/libxul.so
#6  0x000000000040155f in main ()
OK, this is a GCC bug, like I suspected all the time:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16092

if this is still a problem in GCC 4.0, file a bug at gcc.gnu.org or something
(http://gcc.gnu.org/bugs.html)
Status: NEW → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → INVALID
*** Bug 275374 has been marked as a duplicate of this bug. ***
*** Bug 286633 has been marked as a duplicate of this bug. ***
Can/should we add a test to configure to detect this compiler bug and fail out
earlier?
hm, actually, if we do that we could just disable hidden visibility, which would
seem to also fix this bug. should we do that?

reopening for consideration.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
*** Bug 323066 has been marked as a duplicate of this bug. ***
Assignee: dougt → nobody
Status: REOPENED → NEW
QA Contact: xpcom
Status: NEW → RESOLVED
Closed: 19 years ago → 11 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: