GNOME Bugzilla – Bug 312854
Evolution will hang while renaming folders twice for exchange
Last modified: 2007-06-15 04:55:49 UTC
Please describe the problem: Steps to reproduce: 1. Rename a folder. 2. Again try to rename the folder. 3. Evolution will hang. Actual results: In the evolution-exchange-storage process, "*** glibc detected *** corrupted double-linked list: 0x41785838 *** " gets printed. Expected results: Does this happen every time? yes Other information:
Start exchange process in gdb and u should be able to get the traces when this happens.
+ Trace 62994
Thread 1 (Thread -1234942848 (LWP 4672))
Re-opening with traces.
replicable even with evolution-2.5.1. Here is the stack trace:
+ Trace 63967
Thread 1 (Thread 1099506496 (LWP 7270))
waits on do_read() *** This bug has been marked as a duplicate of 330404 ***
I'm still able to reproduce this bug on 2.11.3. Reopening. The backtrace I'm getting after the hang is very similar to that in comment #4; we're stuck in a do_read() call while trying to read a 32-bit integer. And it only happens on the second rename.
I've been investigating this in a downstream bug. Here's what my investigation has found so far: The behavior is pretty consistent. There's a noticable delay on the first rename after clicking OK, but it eventually succeeds (that may be due to the fact that the Exchange server I'm talking to is several hundred miles away). On the second rename the read() call gets stuck waiting for 4 bytes (it's looking to collect a 32-bit integer value), but the Exchange server appears to only be issuing a newline character ('\n').
Created attachment 89965 [details] [review] Proposed patch I think I found the problem here. In exchange-hierarchy-webdav.c:xfer_folder() we cast away the constness of EFolder's 'physical_uri' string and then turn around and free it. The EFolder object is left with a dangling 'physical_uri' pointer, but the freed memory it points to apparently stays valid. That's why the folder rename succeeds on the first try. The second time around, xfer_folder() again tries to free the 'physical_uri' string that doesn't belong to it, which it already freed last time. This then causes evolution-exchange-store to abort with the error message that the reporter mentioned in comment #0, and the client is left waiting for a response in the do_read() function. The fix for the server crash is a simple one-liner, though I question the wisdom of the client calling a blocking Camel function in the main (UI) thread.
Matthew, the patch looks fine and please commit to stable and head. There are more such blocking stuffs, which needs to be made async.
Committed to trunk (revision 7819) and gnome-2-18 branch (revision 7820).