Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 236490 - "Tasks" crashes at startup
Summary: "Tasks" crashes at startup
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-04-15 06:40 UTC by Peter Gordon
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-04-15 08:10:27 UTC


Attachments (Terms of Use)
Crash backtrace (deleted)
2007-04-15 06:40 UTC, Peter Gordon
no flags Details

Description Peter Gordon 2007-04-15 06:40:37 UTC
Description of problem:
After this morning's Evolution update, it crashes immediately upon starting.
It shows the main window and shows a warning dialog that my server's SSL
certificate is mismatched (it's a paid-for hosting, but with a wildcard
certificate), to which I click "OK".

Then, Bug Buddy pops up an error dialog saying that the Tasks application has
crashed. It outputs the following to my terminal:

$ evolution
CalDAV Eplugin starting up ...
(evolution:4909): e-data-server-ui-DEBUG: ep_msg_send: in main thread? 1

(evolution:4909): evolution-mail-WARNING **: ignored this junk plugin: not
enabled or we have already loaded one

(evolution:4909): e-utils-WARNING **: Plugin 'Spamassassin junk plugin' failed
to load hook 'org.gnome.evolution.mail.junk:1.0'
libnm_glib_nm_state_cb: dbus returned an error.
  (org.freedesktop.DBus.Error.ServiceUnknown) The name
org.freedesktop.NetworkManager was not provided by any .service files
(evolution:4909): e-data-server-ui-DEBUG: ep_msg_send: in main thread? 0
(evolution:4909): e-data-server-ui-DEBUG: ep_msg_send: in main thread? 0

The backtrace is rather large, so I've attached it to this bug report as a
plaintext file instead of included it directly.

I saw that it's tracing through calls in libssl3.so, so I tried disabling SSL
support (running `evolution --offline`, then setting it to use No Encryption in
the Sending and Receiving tabs of the account preferences, then running
`evolution --online`); and it seems to work A-OK without using an encrypted
connection. Maybe a handshake problem?

My accounts are setup as follows: My personal email (IMAPS), my Gentoo email
(also IMAPS), the Local account, and my work mail (Exchange). I've tried to
reproduce this issue with other applications, but both Epiphany (checking my
personal and work accounts via webmail) and Thunderbird (checking my personal
and Gentoo accounts via IMAPS) both run just fine. 

One thing that jumps out to me about this backtrace is the call to
camel_stream_buffer_gets(...) at camel-stream-buffer.c:411, which looks like its
dereferencing a pointer that is out of scope or no longer meaningful; but IANAE
though. :)

Comment 1 Peter Gordon 2007-04-15 06:40:37 UTC
Created attachment 152639 [details]
Crash backtrace

Comment 2 Peter Gordon 2007-04-15 06:55:48 UTC
It may or may not help, but I looked into it a bit further and it only happens
when BOTH my Gentoo and Personal accounts are set to use SSL (i.e., both "Is
this certificate OK?" prompt dialogs are shown). When I set my Personal account
to not use encryption, or when I disable my Gentoo account temporarily (and set
my Personal account to use SSL encryption), then Evolution runs fine. 

Comment 3 Peter Gordon 2007-04-15 08:10:27 UTC
Okay, not sure what I did here, but after a reboot Evolution is working again.
(I thought that rebooting is supposed to be a Windows-only fix! :-P)

Sorry for the bug spam.

Comment 4 Matthew Barnes 2007-04-15 13:38:37 UTC
Peter, thanks for the detailed report.  Feel free to reopen this bug if you
start encountering the crash again.  Sounds like there might be a race condition
somewhere in the code.


Note You need to log in before you can comment on or make changes to this bug.