After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 221948 - evolution mail component crashed at night
evolution mail component crashed at night
Status: RESOLVED DUPLICATE of bug 221604
Product: evolution
Classification: Applications
Component: Mailer
unspecified
Other All
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2002-03-15 07:45 UTC by Toni Willberg
Modified: 2002-03-16 00:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Toni Willberg 2002-03-15 07:46:06 UTC 
Package: Evolution
Priority: Normal
Version: 1.0.2.99
Synopsis: evolution mail component crashed at night
Bugzilla-Product: Evolution
Bugzilla-Component: Mailer

Description:
Evolution mail component was crashed at night while I was out of
office.

One of my imap servers was unreachable at same time, perhaps the crash
has something to do with this, I don't know...

See backtrace if it helps.



Debugging Information:

[New Thread 1024 (LWP 9846)]
[New Thread 2049 (LWP 9862)]
[New Thread 1026 (LWP 9863)]
[New Thread 2051 (LWP 9864)]
[New Thread 4100 (LWP 9868)]
[New Thread 5125 (LWP 9869)]
[New Thread 8198 (LWP 10001)]
0x40f5cca9 in __wait4 () from /lib/i686/libc.so.6

+ Trace 19176

Thread 3 (Thread 1026 (LWP 9863))

  • #0 __sigsuspend
    at ../sysdeps/unix/sysv/linux/sigsuspend.c line 45
  • #1 __pthread_wait_for_restart_signal
    at pthread.c line 969
  • #2 __pthread_alt_lock
    at restart.h line 34
  • #3 __pthread_mutex_lock
    at mutex.c line 120
  • #4 segv_redirect
    at main.c line 80
  • #5 pthread_sighandler
    at signals.c line 97
  • #6 <signal handler called>
  • #7 camel_imap_response_free
    at camel-imap-command.c line 538
  • #8 camel_imap_response_free_without_processing
    at camel-imap-command.c line 557
  • #9 imap_read_response
    at camel-imap-command.c line 356
  • #10 camel_imap_command
    at camel-imap-command.c line 112
  • #11 imap_keepalive
    at camel-imap-store.c line 1857
  • #12 timeout_cb
    at camel-remote-store.c line 219
  • #13 timeout_timeout
    at mail-session.c line 636
  • #14 mail_msg_received
    at mail-mt.c line 500
  • #15 thread_received_msg
    at e-msgport.c line 469
  • #16 thread_dispatch
    at e-msgport.c line 550
  • #17 pthread_start_thread
    at manager.c line 284
Comment 1 Jeffrey Stedfast 2002-03-15 16:25:48 UTC 
hmmm, this *might* be a duplicate of the timeout_cb bug. Not really
sure though...

maybe this also solves the mystery of the timeout_cb bug? if the crash
is really happening in some i/o call but the other stacks didn't show
that, then we could have a winner. Then again, this might simply be
crashing because of some stack corruption (which is what NotZed thinks
is happening in the timeout_cb crashes).
Comment 2 Gerardo Marin 2002-03-16 00:34:51 UTC 
I'll put this as duplicate of bug 221604 and add your notation there...
Anyway, if it's nota a dupe, anyone can unlink it :)



*** This bug has been marked as a duplicate of 221604 ***