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 141770 - constant deadlocks on changing network connectivity
Summary: constant deadlocks on changing network connectivity
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Malcolm
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC5Target
TreeView+ depends on / blocked
 
Reported: 2004-12-03 17:47 UTC by Colin Walters
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-08-23 17:51:13 UTC


Attachments (Terms of Use)
evolution backtrace (deleted)
2004-12-03 17:48 UTC, Colin Walters
no flags Details

Description Colin Walters 2004-12-03 17:47:53 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041114 Firefox/1.0

Description of problem:
I swear I filed a bug on this before and we discussed it, but I can't find it.  Anyways, I got a better backtrace from a deadlock.  This seems to happen *very* often now.  Particularly after waking my laptop up from sleep, or changing network connectivity with NetworkManager.

Version-Release number of selected component (if applicable):
evolution-2.0.2-4

How reproducible:
Sometimes

Steps to Reproduce:
1. Use evolution
2. Change network?  Wake from sleep?
  

Additional info:

Comment 1 Colin Walters 2004-12-03 17:48:26 UTC
Created attachment 107850 [details]
evolution backtrace

Comment 2 Dave Malcolm 2005-08-23 00:45:20 UTC
Looking at the backtrace, thread 12 is waiting to acquire a lock on an IMAP
backend, thread 6 is trying to grab data via SSL from an IMAP backend, thread 5
is also waiting for a lock on the IMAP backend.

My guess is that thread 6's read will never succeed, since its IP address has
changed from under it. I don't know offhand if this will timeout.

Am I right in thinking that the latest rawhide evolution is a bit more robust in
this regard?

Comment 3 Colin Walters 2005-08-23 01:02:10 UTC
It seems to work much better, yes.  You can probably close this bug.


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