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 569103 - segfault
segfault
Status: RESOLVED DUPLICATE of bug 563212
Product: evolution
Classification: Applications
Component: Mailer
2.24.x (obsolete)
Other All
: Normal critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
: 569191 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-01-25 17:44 UTC by Brian J. Murrell
Modified: 2009-01-27 04:02 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Description Brian J. Murrell 2009-01-25 17:44:04 UTC 
Steps to reproduce:
Dunno.  This thing is just crashing spontaneously many times a day now.

Stack trace:

+ Trace 211856

Thread 1 (process 10743)

  • #0 __kernel_vsyscall
  • #1 raise
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 nsProfileLock::FatalSignalHandler
    at nsProfileLock.cpp line 212
  • #3 <signal handler called>
  • #4 pthread_mutex_lock
    from /lib/tls/i686/cmov/libpthread.so.0
  • #5 e_flag_set
    at e-flag.c line 83
  • #6 do_cancel
    at e-book.c line 2527
  • #7 e_book_cancel_async_op
    at e-book.c line 2597
  • #8 try_open_e_book
    at em-utils.c line 2086
  • #9 em_utils_contact_photo
    at em-utils.c line 2266
  • #10 efh_format_message
    at em-format-html.c line 2003
  • #11 emf_message_rfc822
    at em-format.c line 1556
  • #12 efhd_format_attachment
    at em-format-html-display.c line 2331
  • #13 em_format_part_as
    at em-format.c line 633
  • #14 em_format_part
    at em-format.c line 652
  • #15 emf_multipart_mixed
    at em-format.c line 1260
  • #16 em_format_part_as
    at em-format.c line 625
  • #17 em_format_part
    at em-format.c line 652
  • #18 efh_format_message
    at em-format-html.c line 2083
  • #19 efh_format_exec
    at em-format-html.c line 1269
  • #20 mail_msg_proxy
    at mail-mt.c line 520
  • #21 g_thread_pool_thread_proxy
    at /build/buildd/glib2.0-2.18.2/glib/gthreadpool.c line 265
  • #22 g_thread_create_proxy
    at /build/buildd/glib2.0-2.18.2/glib/gthread.c line 635
  • #23 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #24 clone
    from /lib/tls/i686/cmov/libc.so.6 


Other information:
Comment 1 Matthew Barnes 2009-01-25 17:52:47 UTC 
Crash appears to be coming from NSS, but can't pinpoint.
Comment 2 Brian J. Murrell 2009-01-25 17:57:15 UTC 
(In reply to comment #1)
> Crash appears to be coming from NSS, but can't pinpoint.

For my own education, can I ask how you came to that conclusion?

This happens fairly frequently (just happened again).  Is there anything more I can do to provide more/better information?
Comment 3 Matthew Barnes 2009-01-25 18:16:11 UTC 
Check the top of each thread for a non-blocking call.  Examples of blocking calls -- "blocking" meaning the kernel has suspended or "blocked" the thread from continuing until an event occurs (usually an I/O event) -- include read(), poll() or select().

In this case, Thread 1 shows something going amiss in NSS (nsProfileLock::FatalSignalHandler):

+ Trace 211857

Thread 1 (process 10743)

  • #0 __kernel_vsyscall
  • #1 raise
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 nsProfileLock::FatalSignalHandler
    at nsProfileLock.cpp line 212
  • #3 <signal handler called>
  • #4 pthread_mutex_lock
    from /lib/tls/i686/cmov/libpthread.so.0 

Thread 5 also shows something deep inside NSS attempting to poll a network socket.  Might be related, might not.  Hard to tell from this stack trace.

The source of the crash appears to be outside of Evolution in this case, or possibly something bad happened earlier and the side-effects snowballed and eventually caused the crash shown here.
Comment 4 Matthew Barnes 2009-01-25 18:21:11 UTC 
Another possibility is the EFlag being set in Thread 1 was already freed, meaning the memory it points to is now random garbage.  This is called a "dangling pointer" and is a common cause of crashes.

Again, can't tell for sure from the data shown in the stack trace.  Would have to reproduce the crash and go in with a debugger.
Comment 5 Brian J. Murrell 2009-01-25 18:26:31 UTC 
(In reply to comment #3)
> 
> In this case, Thread 1 shows something going amiss in NSS
> (nsProfileLock::FatalSignalHandler):

Ahhh.  Yes.  I did see that.  By "nss" I thought you meant libc's nameservice switch.

(In reply to comment #4) 
> Again, can't tell for sure from the data shown in the stack trace.  Would have
> to reproduce the crash and go in with a debugger.

Is a core file not sufficient?  If you want to drive, I can certainly probe a core file for whatever information you desire.
Comment 6 Matthew Barnes 2009-01-26 13:56:07 UTC 
*** Bug 569191 has been marked as a duplicate of this bug. ***
Comment 7 Akhil Laddha 2009-01-27 04:02:28 UTC 
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.


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