Closed Bug 95785 Opened 24 years ago Closed 24 years ago

Linux build fails to launch

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: tracy, Assigned: brendan)

References

Details

(Keywords: smoketest)

Attachments

(2 files)

Stack from a cvs build from this morning with --disable-debug, but -g
1.04 KB, text/plain
Details
backout script
2.90 KB, text/plain
Details
seen on linux commercial and mozilla builds 2001-08-17-06-trunk. -install the build (use installer or tarball; both show same beahvior) -launch the build it doesn't start!
Keywords: smoketest
Hmmm. My own debug build starts. Anything printed on the console?
*** Bug 95783 has been marked as a duplicate of this bug. ***
This is what I see on the console: > cd /usr/local/netscape/ > ./netscape ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=/usr/local/netscape LD_LIBRARY_PATH=/usr/local/netscape:/usr/local/netscape/Cool LIBPATH=/usr/local/netscape:/usr/local/netscape/Cool SHLIB_PATH=/usr/local/netscape:/usr/local/netscape/Cool XPCS_HOME=/usr/local/netscape/Cool MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= >
My debug build works fine as well, but the build in /nightly/latest/ is definitely dying on startup.
OK, I see a "Segmentation Fault" with both the 06:00 and 08:00 builds, so it doesn't seem to be a dependency problem.
I think this is a stack overflow (which talkback can't catch, because there's no stack left). The stack looks like: #0 0x40340f80 in gdk_window_resize () from /usr/lib/libgdk-1.2.so.0 #1 0x40899401 in NSGetModule () from /builds/releases/2001-08-17-06-trunk/components/libwidget_gtk.so #2 0x41094efb in NSGetModule () from /builds/releases/2001-08-17-06-trunk/components/libgkview.so #3 0x4109b3ae in NSGetModule () from /builds/releases/2001-08-17-06-trunk/components/libgkview.so #4 0x4109db89 in NSGetModule () from /builds/releases/2001-08-17-06-trunk/components/libgkview.so #5 0x4109427d in NSGetModule () from /builds/releases/2001-08-17-06-trunk/components/libgkview.so #6 0x4089359a in NSGetModule () from /builds/releases/2001-08-17-06-trunk/components/libwidget_gtk.so #7 0x408934c5 in NSGetModule () from /builds/releases/2001-08-17-06-trunk/components/libwidget_gtk.so #8 0x408925b9 in NSGetModule () from /builds/releases/2001-08-17-06-trunk/components/libwidget_gtk.so #9 0x4089947a in NSGetModule () from /builds/releases/2001-08-17-06-trunk/components/libwidget_gtk.so #10 0x41094efb in NSGetModule () from /builds/releases/2001-08-17-06-trunk/components/libgkview.so <repeats>
One guess is that this could have started when coffee went orange.
Both the optimized/non-debug tinderboxes went orange after brendan checked in his fastload changes. Not sure why that would cause this. The two tinderboxes that didn't are non-optimized/debug. Haven't looked at Seamonkey-Ports in detail yet.
Keywords: crash
A third, different stack from a opt/non-debug build pulled after tree closing: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 20333)] 0x4006371d in js_AllocStack () at eval.c:41 41 eval.c: No such file or directory. in eval.c (gdb) where #0 0x4006371d in js_AllocStack () at eval.c:41 #1 0x406b2e73 in nsXPCWrappedJSClass::CallMethod () from /home/tor/mopt/dist/bin/components/libxpconnect.so #2 0x406b16e3 in nsXPCWrappedJS::CallMethod () from /home/tor/mopt/dist/bin/components/libxpconnect.so #3 0x40148493 in PrepareAndDispatch () at eval.c:41 #4 0x4014857a in nsXPTCStubBase::Stub6 () at eval.c:41 #5 0x406cf18b in UnloadAndReleaseModules () from /home/tor/mopt/dist/bin/components/libjsloader.so #6 0x4019a9a7 in PL_HashTableEnumerateEntries () at eval.c:41 #7 0x406d13f1 in mozJSComponentLoader::UnloadAll () from /home/tor/mopt/dist/bin/components/libjsloader.so #8 0x4012990a in CanUnload_enumerate () at eval.c:41 #9 0x400f9caf in _hashEnumerate () at eval.c:41 #10 0x4019a9a7 in PL_HashTableEnumerateEntries () at eval.c:41 #11 0x400fa125 in nsHashtable::Enumerate () at eval.c:41 #12 0x401299d7 in nsComponentManagerImpl::UnloadLibraries () at eval.c:41 #13 0x4012651b in nsComponentManagerImpl::Shutdown () at eval.c:41 #14 0x400f4a12 in NS_ShutdownXPCOM () at eval.c:41 #15 0x0805292f in main () at eval.c:41 #16 0x404bc177 in __libc_start_main (main=0x80527c8 <main>, argc=1, ubp_av=0xbffff8a4, init=0x804c23c <_init>, fini=0x805482c <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff89c) at ../sysdeps/generic/libc-start.c:129 Only crashes if there is no component.reg, otherwise mozilla just quietly exits during startup.
Keywords: crash
tor's stack is already in shutdown. Anyway, I think brendan should own this, at least for now.
Assignee: asa → brendan
And, FWIW, my gcc3 optimized build (depend) starts fine.
palermo HPUX clobber tinderbox has this problem (I think), so it doesn't seem like a dependency problem
A clobber build doesn't help here. I'm backing brendan out.
Brendan is backed out. I'll attach the backout script for future reference.
Is this a likely cause of bug 95815? I believe embedding isn't displaying scrollbars because the chrome is not being parsed properly.
FWIW, my optimized moz build from just before blizzard's back-out does not exhibit the problem (touch wood). Linux/x86, GCC 2.95.3.
adamlock: that was suggested... we're respinning right now, so we'll see.
Blizzard fixed this by backing out brendan's fastload changes.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 95815 has been marked as a duplicate of this bug. ***
*** Bug 95832 has been marked as a duplicate of this bug. ***
verified fixed on linux commercial build 2001-08-21-06-trunk
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: