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 571228 - crash in Evolution Mail: I was closing Evolution.
crash in Evolution Mail: I was closing Evolution.
Status: RESOLVED NOTGNOME
Product: evolution
Classification: Applications
Component: BugBuddyBugs
2.22.x (obsolete)
Other All
: High critical
: ---
Assigned To: Evolution Triage Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2009-02-10 21:45 UTC by rodrigo.sinfo
Modified: 2009-03-12 00:38 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description rodrigo.sinfo 2009-02-10 21:45:20 UTC
What were you doing when the application crashed?
I was closing Evolution.


Distribution: Debian 5.0
Gnome Release: 2.22.3 2008-09-18 (Debian)
BugBuddy Version: 2.22.0

System: Linux 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686
X Vendor: The X.Org Foundation
X Vendor Release: 10402000
Selinux: No
Accessibility: Disabled
GTK+ Theme: Clearlooks
Icon Theme: gnome

Memory status: size: 126255104 vsize: 126255104 resident: 29073408 share: 16891904 rss: 29073408 rss_rlim: 4294967295
CPU usage: start_time: 1234285985 rtime: 4086 utime: 3210 stime: 876 cutime:14 cstime: 30 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/bin/evolution'

[Thread debugging using libthread_db enabled]
[New Thread 0xb65a86d0 (LWP 10273)]
[New Thread 0xb3296b90 (LWP 5268)]
[New Thread 0xb4298b90 (LWP 5266)]
[New Thread 0xb1291b90 (LWP 5264)]
[New Thread 0xb0876b90 (LWP 5262)]
0xb7f30424 in __kernel_vsyscall ()

Thread 5 (Thread 0xb0876b90 (LWP 5262))

  • #0 __kernel_vsyscall
  • #1 __lll_lock_wait
    from /lib/i686/cmov/libpthread.so.0
  • #2 _L_lock_89
    from /lib/i686/cmov/libpthread.so.0
  • #3 pthread_mutex_lock
    from /lib/i686/cmov/libpthread.so.0
  • #4 segv_redirect
    at main.c line 528
  • #5 <signal handler called>
  • #6 NSSRWLock_LockRead_Util
    at nssrwlk.c line 177
  • #7 SECMOD_GetReadLock
    at pk11list.c line 71
  • #8 PK11_TokenExists
    at pk11slot.c line 1733
  • #9 ssl3_config_match_init
    at ssl3con.c line 658
  • #10 ssl2_ConstructCipherSpecs
    at sslcon.c line 206
  • #11 ssl2_BeginClientHandshake
    at sslcon.c line 3018
  • #12 ssl_Do1stHandshake
    at sslsecur.c line 151
  • #13 ssl_SecureRecv
    at sslsecur.c line 1113
  • #14 ssl_SecureRead
    at sslsecur.c line 1132
  • #15 ssl_Read
    at sslsock.c line 1467
  • #16 PR_Read
    at priometh.c line 141
  • #17 stream_read
    at camel-tcp-stream-ssl.c line 401
  • #18 camel_stream_read
    at camel-stream.c line 98
  • #19 stream_fill
    at camel-pop3-stream.c line 60
  • #20 camel_pop3_stream_line
    at camel-pop3-stream.c line 321
  • #21 camel_pop3_engine_new
    at camel-pop3-engine.c line 110
  • #22 connect_to_server_wrapper
    at camel-pop3-store.c line 208
  • #23 pop3_connect
    at camel-pop3-store.c line 608
  • #24 camel_service_connect
    at camel-service.c line 371
  • #25 camel_session_get_service_connected
    at camel-session.c line 275
  • #26 mail_tool_get_inbox
    at mail-tools.c line 70
  • #27 fetch_mail_exec
    at mail-ops.c line 296
  • #28 mail_msg_proxy
    at mail-mt.c line 523
  • #29 g_thread_pool_thread_proxy
    at /tmp/buildd/glib2.0-2.16.6/glib/gthreadpool.c line 265
  • #30 g_thread_create_proxy
    at /tmp/buildd/glib2.0-2.16.6/glib/gthread.c line 635
  • #31 start_thread
    from /lib/i686/cmov/libpthread.so.0
  • #32 clone
    from /lib/i686/cmov/libc.so.6


----------- .xsession-errors (16418 sec old) ---------------------
TFindDeclarationTool.ValidateToolDependencies /usr/lib/lazarus/lcl/extctrls.pp
TFindDeclarationTool.ValidateToolDependencies /usr/lib/lazarus/lcl/stdctrls.pp
TFindDeclarationTool.ValidateToolDependencies /usr/lib/lazarus/lcl/menus.pp
TFindDeclarationTool.ValidateToolDependencies /usr/lib/lazarus/lcl/buttons.pp
TFindDeclarationTool.ValidateToolDependencies /usr/lib/lazarus/lcl/dialogs.pp
TFindDeclarationTool.ValidateToolDependencies /usr/lib/lazarus/lcl/forms.pp
TCustomFormEditor.GetDefineProperties APersistentClassName="TfProcessa" AncestorClassName="TForm"
TCustomFormEditor.GetDefineProperties PersistentClass TForm is registered
TCustomFormEditor.GetDefineProperties Getting define properties for TForm
TDefinePropertiesPersistent.PublicDefineProperties START TDefinePropertiesPersistent :TForm
TDefinePropertiesPersistent.PublicDefineProperties END TDefinePropertiesPersistent :TForm
TLFMTree.AddError IdentifierNotFound: identifier OldCreateOrder not found in class "TfProcessa". Menu.lfm (15,3) NodePath=OldCreateOrder
TFindDeclarationTool.ValidateToolDependencies /usr/lib/lazarus/lcl/lresources.pp
TFindDeclarationTool.ValidateToolD
...Too much output, ignoring rest...
--------------------------------------------------
Comment 1 palfrey 2009-02-10 23:58:26 UTC
This appears to be a bug in the NSS libraries from Mozilla. More specifically, it's https://bugzilla.mozilla.org/show_bug.cgi?id=427715 which the Mozilla folks appear to have at least a preliminary patch for.
Comment 2 Honza Bambas 2009-03-11 23:05:31 UTC
For the first sigh I wouldn't say it's related to https://bugzilla.mozilla.org/show_bug.cgi?id=427715. Can you tell me please which of the threads actually crashed?

-hb- (mozilla)
Comment 3 palfrey 2009-03-12 00:30:29 UTC
(In reply to comment #2)
> For the first sigh I wouldn't say it's related to
> https://bugzilla.mozilla.org/show_bug.cgi?id=427715. Can you tell me please
> which of the threads actually crashed?

This one:

  • #5 <signal handler called>
  • #6 NSSRWLock_LockRead_Util
    at nssrwlk.c line 177
  • #7 SECMOD_GetReadLock
    at pk11list.c line 71
  • #8 PK11_TokenExists
    at pk11slot.c line 1733
  • #9 ssl3_config_match_init
    at ssl3con.c line 658
  • #10 ssl2_ConstructCipherSpecs
    at sslcon.c line 206
  • #11 ssl2_BeginClientHandshake
    at sslcon.c line 3018

Comment 4 Honza Bambas 2009-03-12 00:38:01 UTC
Thread 5 bt looks similar to thread's 4. It is not related to mozilla bug 427715. Looks like you are calling an nss ssl function after nss has been uninitialized. There is probably some net connection leaking.

There are absolutely no checks in nss code for nss initialization. Calling nss while it is not initialized is a crash. Period.