[5659] in testers
Re: Linux 9.2.13 heisenbug: Evolution seg faulted on start-up.
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Jul 21 17:01:35 2003
From: Greg Hudson <ghudson@MIT.EDU>
To: Bill Cattey <wdc@mit.edu>
Cc: testers@mit.edu
In-Reply-To: <1058810235.22303.2.camel@tokata.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1058820976.1470.67.camel@error-messages.mit.edu>
Mime-Version: 1.0
Date: 21 Jul 2003 16:56:16 -0400
So, in theory, the evolution process should still be running, and you
should be able to gdb attach to it and get a stack trace, by running:
gdb /usr/athena/bin/evolution <pid>
and then entering "back" at the gdb prompt. (On Solaris, you have to
add gnu to run gdb, of course, and the executable is
/usr/athena/libexec/evolution-1.4 instead of /usr/athena/bin.) If I'm
arounding zephyr, the stack trace might identify more information I want
to gather via gdb.
In practice, there are sometimes complications. Don't be distracted by
evolution-wombat or evolution-alarm-notify processes; those are
subsidiary and usually uninteresting. The real process should be named
just "evolution". I've run into cases where the process doesn't exist
when the crash dialog is up, in which case the evidence is gone.
If you (beforehand) setenv GNOME_DISABLE_CRASH_DIALOG to 1 and unlimit
coredumpsize, you might get core dumps, depending on how Linux is
feeling about dumping core on multithreaded processes these days. But
you'll lose your potential chance to attach the process, so I don't
recommend doing that unless the other approach consistently fails.
