seamonkey crashes ocasionally

RESOLVED INCOMPLETE

Status

SeaMonkey
General
RESOLVED INCOMPLETE
12 years ago
10 years ago

People

(Reporter: Jens Elkner, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060531 SeaMonkey/1.0.2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060531 SeaMonkey/1.0.2

(gdb) where
#0  0xb79940f1 in kill () from /usr/lib/libc.so.6
#1  0xb7d35a61 in pthread_kill () from /usr/lib/libpthread.so.0
#2  0xb7d35d7b in raise () from /usr/lib/libpthread.so.0
#3  0xb6cdd3d2 in NSGetModule ()
   from /usr/apps/seamonkey-1.0.2/components/libprofile.so
#4  0xb7d38648 in __pthread_sighandler () from /usr/lib/libpthread.so.0
#5  <signal handler called>
#6  0xb7eb9670 in PL_DHashTableOperate ()
   from /usr/apps/seamonkey/libxpcom_core.so
#7  0xb7efa558 in nsComponentManagerImpl::GetServiceByContractID(char const*, nsID const&, void**) () from /usr/apps/seamonkey/libxpcom_core.so
#8  0xb7eb9e10 in CallGetService(char const*, nsID const&, void**) ()
   from /usr/apps/seamonkey/libxpcom_core.so
#9  0xb7eba20b in nsGetServiceByContractID::operator()(nsID const&, void**) const () from /usr/apps/seamonkey/libxpcom_core.so
#10 0xb7eb9ceb in nsCOMPtr_base::assign_from_gs_contractid(nsGetServiceByContractID, nsID const&) () from /usr/apps/seamonkey/libxpcom_core.so
#11 0xb76363e1 in NSGetModule ()
   from /usr/apps/seamonkey-1.0.2/components/libxpconnect.so
#12 0xb7637737 in NSGetModule ()
   from /usr/apps/seamonkey-1.0.2/components/libxpconnect.so
#13 0xb76327d0 in NSGetModule ()
   from /usr/apps/seamonkey-1.0.2/components/libxpconnect.so
...

The crash happen ocassionally and it gets more and more annoying. Probably need to switch back to mozilla, which never crashed in the last 6 month ... 

Reproducible: Always

Comment 1

12 years ago
Too bad we cannot get a real stacktrace. But i think the PL_DHashTableOperate crashers are already known and will be fixed...
(Reporter)

Comment 2

12 years ago
1) Hmmm, what do you mean with "real" stack trace? Wanna have the core files?
2) Any estimations, when it will be fixed?
Summary: seamonkexy crashes ocasionally → seamonkey crashes ocasionally

Comment 3

12 years ago
With a real stacktrace i mean a stacktrace from a build with symbols (the mozilla.org builds are shipped without symbols). Your stacktrace contains many calls to NSGetModule, which is a exported function so that's probably the reason why it occours so many times in your stacktrace.

Comment 4

12 years ago
what mcsmurf said, either build your own build w/ --enable-debug/--enable-debugger-info-modules or use talkback.

don't try to use gdb or an equivalent on a build w/ --enable-strip or a mozilla.org talkback enabled build, the output is useless.
Jens, are you still seeing this on recent builds of SeaMonkey? Are you able to build your own and test? If you can't build your own, can you try a trunk build from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk and, if you get that crash again, be sure to "send crash data and restart" from the "Breakpad" popup which will appear, then type about:crashes in the URL bar, hit Enter, and copy the crash ID to a comment below?

Timeless, IIUC SeaMonkey builds 1.x.x are shipped without Talkback.

The latest comment is more than 1½ years old. If the reporter doesn't answer within a "reasonable" time frame, I move it be closed INCOMPLETE

Comment 6

10 years ago
indeed, there is no crash reporting available for those builds. reporter if you're still interested, you will need to make your own build.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.