Evolution hang (hibernate/network interface/subnet change?)

Update:

Have reproduced this bug again going from wireless->wired network. subnet
changed, as did the interface being used to contact the IMAP server.

Question now is, how do we debug this issue? Are there any evolution debug
options I can set to get more detail of where the hang is?

BTW, this is with hoary - I'll test breezy once evolution is confirmed not to
eat your IMAP folders...

does it consume some CPU while hanging? do you have the same DNS for both
access? Is that the same than http://bugzilla.gnome.org/show_bug.cgi?id=227599 ?
or http://bugzilla.gnome.org/show_bug.cgi?id=267602 ?

1) I don't know if evo is using the CPU during the hang - will look out next
time I encounter this bug
6762) No, the DNS entry doesn't change, but the network interface being used does.
3) This bug isn't 227599, but may be the same as 267602

can you get a backtrace of the hang?

- gdb -p `pidof evolution`
(gdb) thread apply all bt

Created an attachment (id=3380)
backtrace of well hung evolution

Backtrace of the hang - happened this time even when I resumed from hibernation
on the same subnet (same IP address).

I also have a similar (or the same issue). My evolution hung when I tried to forward a message (including an image). The original message was on IMAP. I think this only happens after suspend/resume, but not always. I now had the following scenario:

- suspend
- disconnect network
- resume
- evolution complains about timeout to server
- suspend
- connect network
- resume
- evolution works but when I later try to forward the message it hangs

Attached is a trace of the debug-enabled evolution while hung (from http://people.ubuntu.com/~seb128/debug-pkgs/evolution/ )

reproducible

Could anybody get a backtrace with evolution-data-server-dbg and evolution-dbg on dapper?

The network handling of evolution in Dapper seems to be changed. Short tests didn't crash evolution. Since I test with the Dapper Live cd, it is hard to do some long term testing.

I am now using Dapper beta for a while and I have not been able to reproduce this bug.

Does anybody still get that issue on dapper?

This *might* be related to bug #42422 which is Evolution hanging on Dapper.

After suspend/resume, I get stuck at "Pinging server XXX...", in both Dapper 6.06 and Edgy 6.10. I have a possibly related NetworkManager problem, though (I'm using WPA, but it doesn't reconnect after suspend/resume.) Dunno if that's related.

Anyways, the order of events for me is:
- suspend-to-RAM
- resume
- restart wpa_supplicant by hand (see above)
- click "Send / Receive"; it hangs at "Pinging server XXX".

In Dapper, at least, the close button on the "sending / receiving messages" dialog box didn't always work, and the "cancel" button sometimes caused it to start over, according to the progress bar.

Do you still get that problem? Could you get a debug backtrace on edgy or feisty?

I am having this "Pinging server XXX..." problem on feisty. Without suspend/resume.

Here is my traceback

Sorry, I meant backtrace. I see this bug on 2 boxes. One behind a DSL line (which is disconnected every 24h) and one connected via Ethernet to the imap and smtp server. I have configured 2 email accounts. Both IMAP accounts are using SSL encryption. If you need more information, let me know, please.

My backtrace has nothing to do with that bugreport. I disabled one of the two imap accounts and
can't reproduce the problem, now. Sorry for submitting information to wrong BugId.

I'm now running 7.10, and I don't recall seeing this recently.

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Thanks in advance.

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!.