Closed Bug 149461 Opened 22 years ago Closed 21 years ago

browser dumps core on startup (Solaris 8 x86)

Categories

(Core :: XPConnect, defect, P2)

Product:
Core
Component:
XPConnect
Platform:
x86
SunOS
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.4final

People

(Reporter: ml, Assigned: dbaron)

References

Details

(Whiteboard: [patch])

Attachments

(1 file)

a patch to try
1.14 KB, patch
dbradley
: review+
brendan
: superreview+
asa
: approval1.4+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:0.9.4.1) Gecko/20020406
Netscape6/6.2.2
BuildID:    mozilla release 1.0

The browser dumps core on startup. The OS is Solaris 8 x86. The source was
compiled with GCC 3.1. Ldd from mozilla-bin is the following:
        libgkgfx.so =>   ./libgkgfx.so
        libjsj.so =>     ./libjsj.so
        libmozjs.so =>   ./libmozjs.so
        libxpcom.so =>   ./libxpcom.so
        libplds4.so =>   ./libplds4.so
        libplc4.so =>    ./libplc4.so
        libnspr4.so =>   ./libnspr4.so
        libdl.so.1 =>    /usr/lib/libdl.so.1
        librt.so.1 =>    /usr/lib/librt.so.1
        libgtk-1.2.so.0 =>       /usr/local/X11/opt/lib/libgtk-1.2.so.0
        libgdk-1.2.so.0 =>       /usr/local/X11/opt/lib/libgdk-1.2.so.0
        libgmodule-1.2.so.0 =>   /usr/local/X11/opt/lib/libgmodule-1.2.so.0
        libglib-1.2.so.0 =>      /usr/local/X11/opt/lib/libglib-1.2.so.0
        libXi.so.6.0 =>  /usr/local/X11/lib/libXi.so.6.0
        libXext.so.6.4 =>        /usr/local/X11/lib/libXext.so.6.4
        libX11.so.6.2 =>         /usr/local/X11/lib/libX11.so.6.2
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libm.so.1 =>     /usr/lib/libm.so.1
        libstdc++.so.4 =>        /usr/local/gnu/lib/libstdc++.so.4
        libgcc_s.so.1 =>         /usr/local/gnu/lib/libgcc_s.so.1
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libthread.so.1 =>        /usr/lib/libthread.so.1
        libaio.so.1 =>   /usr/lib/libaio.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2


Reproducible: Always
Steps to Reproduce:
1.CC=gcc CFLAGS=-O4 CXX=g++ CXXFLAGS=-O4 ./configure  i686-pc-solaris2.8
--prefix=/usr/local/mozilla --exec-prefix=/usr/
local/mozilla --x-includes=/usr/local/X11/include --x-libraries=/usr/local/X11/li
b --with-pthreads --with-system-jpeg=/usr/local/X11/opt --with-system-zlib=/usr/l
ocal/std --with-system-png=/usr/local/X11/opt --with-system-mng=/usr/local/X11/op
t --disable-debug --enable-optimize=-O4 --disable-dtd-debug --disable-logging

2. execute "mozilla"

Actual Results:  output of gdb/where:
(gdb) where
#0  0xde58fa19 in xpc_CheckAccessList(unsigned short const*, char const**) ()
   from
/n/Indigo/src/Indigo/local/mozilla/build/mozilla/dist/bin/components/libxpconnect.so
#1  0xde59acb9 in nsXPCException::CanGetProperty(nsID const*, unsigned short
const*, char**) ()
   from
/n/Indigo/src/Indigo/local/mozilla/build/mozilla/dist/bin/components/libxpconnect.so
#2  0xdfa14e07 in ?? () from ./libxpcom.so
#3  0xde5b0196 in XPCWrappedNative::CallMethod(XPCCallContext&,
XPCWrappedNative::CallMode) ()
   from
/n/Indigo/src/Indigo/local/mozilla/build/mozilla/dist/bin/components/libxpconnect.so
#4  0xde5b4f00 in XPC_WN_CallMethod(JSContext*, JSObject*, unsigned, long*,
long*) ()
   from
/n/Indigo/src/Indigo/local/mozilla/build/mozilla/dist/bin/components/libxpconnect.so
#5  0xdface60c in js_Invoke () from ./libmozjs.so
#6  0xdfaceb08 in js_InternalInvoke () from ./libmozjs.so
#7  0xdfae5e96 in js_TryMethod () from ./libmozjs.so
#8  0xdfae53f3 in non-virtual thunk to nsAbView::QueryInterface(nsID const&,
void**) () from ./libmozjs.so
#9  0xdfb07bd2 in js_ValueToString () from ./libmozjs.so
#10 0xdfac5f7b in js_ReportUncaughtException () from ./libmozjs.so
#11 0xdfa958c4 in JS_ExecuteScript () from ./libmozjs.so
#12 0xde549b02 in mozJSComponentLoader::GlobalForLocation(char const*, nsIFile*)
    ()
   from
/n/Indigo/src/Indigo/local/mozilla/build/mozilla/dist/bin/components/libjsloader.so
#13 0xde549168 in mozJSComponentLoader::ModuleForLocation(char const*, nsIFile*)
    ()
   from
/n/Indigo/src/Indigo/local/mozilla/build/mozilla/dist/bin/components/libjsloader.so
#14 0xde5487d1 in mozJSComponentLoader::AttemptRegistration(nsIFile*, int) ()
   from
/n/Indigo/src/Indigo/local/mozilla/build/mozilla/dist/bin/components/libjsloader.so
#15 0xde54856e in mozJSComponentLoader::AutoRegisterComponent(int, nsIFile*,
int*) ()
   from
/n/Indigo/src/Indigo/local/mozilla/build/mozilla/dist/bin/components/libjsloader.so
#16 0xde54809e in mozJSComponentLoader::RegisterComponentsInDir(int, nsIFile*)
    ()
   from
/n/Indigo/src/Indigo/local/mozilla/build/mozilla/dist/bin/components/libjsloader.so
#17 0xde547f41 in mozJSComponentLoader::AutoRegisterComponents(int, nsIFile*) ()
   from
/n/Indigo/src/Indigo/local/mozilla/build/mozilla/dist/bin/components/libjsloader.so
#18 0xdf9ed1b8 in ?? () from ./libxpcom.so
#19 0xdf9ecc7e in ?? () from ./libxpcom.so
#20 0xdf9ee899 in ?? () from ./libxpcom.so
#21 0x08056251 in main1(int, char**, nsISupports*) ()
#22 0x08055237 in main ()
#23 0x08054dbd in _start ()
Formally confirming bug for consideration -
Status: UNCONFIRMED → NEW
Ever confirmed: true
Oops, just noticed the reported build date: Gecko/20020406.
Mike, would it be possible to try the latest nightly and see
if the problem is still occurring? 

Note: the site ftp://ftp.mozilla.org/pub/mozilla/nightly/
is currently experienceing heavy volume and may report a bogus
"Not Found" error ...
There are a number of issues with GCC 3.x and I'm not sure all have been
resolved. If the reporter could run TestXPTCInvoke, that may let us know whether
that's an issue or not.
out from TestXPTCInvoke:

calling direct:
        1 + 1 = 2
        1L + 1L = 2
        2 * 2 = 4
        2L * 2L = 4
        1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 = 55
        1 + 2 = 3.000000f
        1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 = 55.000000
        1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 = 55.000000f
        1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 +1 15 + 16 +
17 + 18 + 19 + 20 = 210.000000f
        moo cow = milk
calling via invoke:
Segmentation Fault (core dumped)

I'm going to dupe this to bug 102492. This probably isn't the exact same issue,
but 102492 will be where the TestXPTCInvoke for GCC 3.x and solaris get
found/addressed.

Reporter, you may want to try the suggestion in bug 102492 and see if that gets
you farther or not.

*** This bug has been marked as a duplicate of 102492 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Marking Verified -
Status: RESOLVED → VERIFIED
This is not a duplicate bug. The problem here is due to to the asm code in
XPTC_InvokeByIndex. 

gdb ./TestXPTCInvoke  core
GNU gdb 5.2
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-solaris2.8"...
(no debugging symbols found)...
Core was generated by `./TestXPTCInvoke'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from ./libxpcom.so...(no debugging symbols found)...done.
Loaded symbols for ./libxpcom.so
Reading symbols from ./libplds4.so...(no debugging symbols found)...done.
Loaded symbols for ./libplds4.so
Reading symbols from ./libplc4.so...(no debugging symbols found)...done.
Loaded symbols for ./libplc4.so
Reading symbols from ./libnspr4.so...(no debugging symbols found)...done.
Loaded symbols for ./libnspr4.so
Reading symbols from /usr/lib/libdl.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /usr/lib/libsocket.so.1...(no debugging symbols found)...
done.
Loaded symbols for /usr/lib/libsocket.so.1
Reading symbols from /usr/local/gnu/lib/libstdc++.so.4...done.
Loaded symbols for /usr/local/gnu/lib/libstdc++.so.4
Reading symbols from /usr/lib/libm.so.1...done.
Loaded symbols for /usr/lib/libm.so.1
Reading symbols from /usr/local/gnu/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/local/gnu/lib/libgcc_s.so.1
Reading symbols from /usr/lib/libpthread.so.1...done.
Loaded symbols for /usr/lib/libpthread.so.1
Reading symbols from /usr/lib/libc.so.1...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libthread.so.1...done.
Loaded symbols for /usr/lib/libthread.so.1
Reading symbols from /usr/lib/libnsl.so.1...done.
Loaded symbols for /usr/lib/libnsl.so.1
Reading symbols from /usr/lib/libaio.so.1...done.
Loaded symbols for /usr/lib/libaio.so.1
Reading symbols from /usr/lib/libmp.so.2...done.
Loaded symbols for /usr/lib/libmp.so.2
#0  0x08051ac4 in InvokeTestTarget::AddManyDoubles(double, double, double,
double, double, double, double, double, double, double, double*) ()
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Bug 71627 might be of interest.
CC'ing Shaver. I still this needs to be covered under bug 71627. That bug was to
deal with all GCC-3.0 issues on non x86 platforms, which this falls under.
Depends on: 71627
Going to need some help on this. I don't have solaris and no way to test this.
I'll be happy to review any submitted patches, I'm comfortable with x86 assembler.
Severity: blocker → critical
Status: REOPENED → ASSIGNED
No longer depends on: 71627
This shouldn't fall under non x86. this is solaris x86 -- sorry i replaced my
solaris x86 w/ os/2 a while ago. i could install it in vmware but i haven't
reinstalled that yet...
Hardware: Sun → PC
*** Bug 173022 has been marked as a duplicate of this bug. ***
*** Bug 184260 has been marked as a duplicate of this bug. ***
Could those of you who had this problem give a list of the "*.o" files present
in mozilla/xpcom/reflect/xptcall/src/md/unix/ ?  This will at least confirm
which files are being used.
Attached patch a patch to try — — Splinter Review 
This patch might fix it.  It's worth trying, anyway.
I have applied the patch given below, and established (to my
satisfaction) that it works. I have built a debug and release version and have
had no trouble.
Attachment #117397 - Flags: superreview?(brendan)
Attachment #117397 - Flags: review?(dbradley)
Comment on attachment 117397 [details] [diff] [review]
a patch to try

sr=brendan@mozilla.org

/be
Attachment #117397 - Flags: superreview?(brendan) → superreview+
Comment on attachment 117397 [details] [diff] [review]
a patch to try

r=dbradley
Attachment #117397 - Flags: review?(dbradley) → review+
Comment on attachment 117397 [details] [diff] [review]
a patch to try

Requesting approval for this patch -- it's a simple porting fix that affects
only Solaris/x86.
Attachment #117397 - Flags: approval1.4?
Taking
Assignee: dbradley → dbaron
Status: ASSIGNED → NEW
Priority: -- → P2
Whiteboard: [patch]
Target Milestone: --- → mozilla1.4final
Comment on attachment 117397 [details] [diff] [review]
a patch to try

a=asa (on behalf of drivers) for checkin to 1.4
Attachment #117397 - Flags: approval1.4? → approval1.4+
Fix checked in to trunk, 2003-05-20 13:47 -0700.
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
Checkin verified.

ml@slack.net -  if this does not fix the problem, please reopen; thanks -
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: