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 569191 - segfault
segfault
Status: RESOLVED DUPLICATE of bug 569103
Product: evolution
Classification: Applications
Component: Mailer
2.24.x (obsolete)
Other All
: Normal critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2009-01-26 13:50 UTC by Brian J. Murrell
Modified: 2009-01-26 14:36 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Description Brian J. Murrell 2009-01-26 13:50:15 UTC 
Steps to reproduce:
Not really sure.

Stack trace:

+ Trace 211883

Thread 1 (process 4551)

  • #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 vee_get_message
    at camel-vee-folder.c line 647
  • #5 camel_folder_get_message
    at camel-folder.c line 1126
  • #6 get_message_exec
    at mail-ops.c line 1824
  • #7 mail_msg_proxy
    at mail-mt.c line 520
  • #8 g_thread_pool_thread_proxy
    at /build/buildd/glib2.0-2.18.2/glib/gthreadpool.c line 265
  • #9 g_thread_create_proxy
    at /build/buildd/glib2.0-2.18.2/glib/gthread.c line 635
  • #10 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #11 clone
    from /lib/tls/i686/cmov/libc.so.6 


Other information:
Comment 1 Matthew Barnes 2009-01-26 13:56:07 UTC 

*** This bug has been marked as a duplicate of 569103 ***
Comment 2 Brian J. Murrell 2009-01-26 14:36:02 UTC 
(In reply to comment #1)
> 
> *** This bug has been marked as a duplicate of 569103 ***

Why do you think so?  The crashing thread appears to be thread 1, yes?  It's call stack is:

#0  __kernel_vsyscall
#1  raise
#2  nsProfileLock::FatalSignalHandler

+ Trace 211885

  • #3 <signal handler called>
  • #3 <signal handler called> 

The only thing these stacks have in common is the first 4 frames and that looks to me to be more like generic segfault handling code than than anything.  If I had to guess I'd say the sefaults in those two stacks are actually in frames 4 and 5 respectively, and those are not at all related are they?