crash while getting stack trace WAS: [Evolution] some gconf paths weren't updated during the upgrade from 1.x to 2.x



On Thu, 2005-02-24 at 14:48 -0500, JP Rosevear wrote:
If the editors are taking a long time to launch, you should get a
stack
trace of what its doing while it takes so long.

After you send this I noticed that this doesn't happen when evolution
has been running only for a couple of minutes (maybe even hours). The
problems only starts when evolution is running for a long period of
time.

Today I noticed the problem again. (Evolution was running since 12:55
Friday, February 25, 2005)

So I tried to get a stack trace (twice) following the instructions on
http://gnome.org/projects/evolution/bugs.shtml But the first time it
didn't seem to provide very much info and I guess I did something wrong
so I started over.

However when I typed 'continue' in gdb to get back to evolution to
change from the calendar to the mailer evolution crashed and the
bug-buddy helper started. I created a bug report and have both
stack-traces on file. I'll attach them both to bug report.

Can someone tell me what I did wrong?

Here are the commands I tried:
(evolution was running and switching from the mailer to the calendar
took very long)
m8ram imladris:~$ ps aux | grep evol
m8ram     2600  0.0  2.0 173976 10380 ?      S    Feb18   0:03 /usr/lib/evolution/evolution-data-server-1.
0 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_InterfaceCheck --oaf-ior-fd=26
m8ram    16311  0.0  0.7 64032 3736 ?        S    Feb20   0:09 /usr/lib/evolution/2.0/evolution-alarm-noti
fy --oaf-activate-iid=OAFIID:GNOME_Evolution_Calendar_AlarmNotify_Factory:2.0 --oaf-ior-fd=28
m8ram    30838  0.2 19.0 214468 98084 pts/0  S    Feb25  42:41 evolution
m8ram    20510  0.0  0.8 80948 4548 ?        S    Mar02   0:00 /usr/lib/evolution/evolution-data-server-1.
0 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_BookFactory:1.0 --oaf-ior-fd=23
m8ram     6925  0.0  0.1  3324  580 pts/11   S+   08:37   0:00 grep evol
m8ram imladris:~$ gdb -p 30838
[...]
---Type <return> to continue, or q <return> to quit---
[return]
(gdb) thread apply all bt
[...]
---Type <return> to continue, or q <return> to quit---
[return]
(gdb) q
The program is running.  Quit anyway (and detach it)? (y or n) y
Detaching from program: /usr/bin/evolution-2.0, process 30838

Then I saved the output to a file and tried again:
m8ram imladris:~$ gdb -p 30838 2>&1 | tee evo-backtrace-2.txt
[...]
(gdb) continue
Continuing.
[New Thread 1211243440 (LWP 7286)]
Cannot get thread event message: debugger service failed
(gdb) thread apply all bt
[...]
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1094471232 (LWP 30838)]
0x48321bb5 in ?? ()
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) Program not restarted.
(gdb) continue
Continuing.

Program received signal SIGCONT, Continued.
0x40f88511 in __waitpid_nocancel () from /lib/tls/libpthread.so.0
(gdb) q
The program is running.  Quit anyway (and detach it)? (y or n) Quitting: Can't detach LWP 7286: No such pr
ocess
m8ram imladris:~$ evolution --force-shutdown
Shutting down evolution (Evolution Shell)
Shutting down evolution-data-server-1.0 (Evolution Calendar file and webcal backend / Evolution Addressboo
k file and LDAP backend)
Shutting down evolution-alarm-notify (Evolution Calendar alarm notification service)


I hope someone can tell what mistake I made here so I can get a better
stack trace next time I notice this problem.

TIA

Bram
-- 
# Mertens Bram "M8ram"   <bram-mertens linux be>   Linux User #349737 #
# debian testing            kernel 2.6.8-1-686     i686     512MB RAM #
# 09:36:27 up 27 days, 13:23, 10 users,  load average: 0.29, 0.20, 0.13 #




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]