GNOME Bugzilla – Bug 337503
Renaming a folder twice crashes Evolution
Last modified: 2008-08-14 12:49:40 UTC
Rename a folder, and rename it once again. Evolution crashes. Tested for both Calendar and Contacts folders. (gdb) bt
+ Trace 67505
Created attachment 68793 [details] [review] Patch for the above bug
You need to create the patch using "cvs diff -up" format Also, I dont understand how the g_object_unref is not necessary. When we are stealing the old value from the Hashtable and substituting it with the new value, dont we need to unref it to avoid the leak?
There is a g_object_ref missing somewhere . This should be gthe culprint. Will need to find that out...
Bumping version to a stable release.
*** Bug 544109 has been marked as a duplicate of this bug. ***
(evolution:4275): evolution-exchange-storage-CRITICAL **: e_folder_get_physical_uri: assertion `E_IS_FOLDER (folder)' failed Program received signal SIGSEGV, Segmentation fault.
+ Trace 204702
Thread 1 (Thread 0xb6134720 (LWP 4275))
Possible dupe of bug #312854.
Created attachment 116161 [details] [review] proposed eds patch for evolution-data-server; It's quite simple for the crash itself, just removed one unref. I also removed code for unused variables and made sure we unref only that what we removed. It wasn't the problem for me, but I believe it's better in this way. The reason why I just removed that unref in xfer function it that the reference counting seems right to me, as far as I can tell, when removing source from the hierarchy, it's unreffed at * exchange-hierarchy-webdav.c::hierarchy_removed_folder: 212 (when removing from the hash table) * exchange-account.c::hierarchy_removed_folder: 461, 462, 464 resulting in 1 ref_count left, which is correct, I think, because it's still shown in the UI in this moment. When adding folder to the hierarchy, it has been reffed in * exchange-hierarchy-webdav.c::hierarchy_new_folder: 197 * exchange-account.c::hierarchy_new_folder: 376, 384, 393, 405 Resulting in 6 references. One has been removed a few lines below the add in xfer function, and yet another one when calling properties of the calendar source, in exchange-account.c::exchange_account_rescan_tree:333. (Line numbers in exchange-account.c are before the patch). I tried also to get the source's physical_uri before removing it from the hierarchy, but it let to the source being shown in the source selector (the tree) in the UI. When I removed the fresh_folders tracker hash table, which has been there for nothing anyway, then it (seems to me) works better. One thing is bad, I'm not for 100% sure whether it leaks the source or not. The source ends with ref_count=1 after the xfer function, but I didn't get the response for it to decrease to zero. Maybe more investigation is required here.
Wouldn't it be easier to use GDestroyNotify callbacks in the 'folders' hash table so you don't have to unref things manually?
Bharath: Ping
(In reply to comment #9) > Wouldn't it be easier to use GDestroyNotify callbacks in the 'folders' hash > table so you don't have to unref things manually? Yes, it can be reworked too, you've right.
Patch looked fine to me, but while testing it I renamed a calendar twice and boom it disappeared from the view. Its still there on the server but only a restart would reflect it back in Evolution. Lot other secrets revealed ;) The patch looks ok so this fixed the issue in here but exposed some hidden issues. My guess is some rename fixes which were checked in recently. Patch looks good. Lets handle the regressions seen in a different bug.
Committed to trunk. Committed revision 9349. I'm sorry to say, but I cannot reproduce the behavior of missing calendar after the second rename on my machine. I recall some strangeness with colors, where sometimes the color has been lost after the rename and sometimes not, but now, I have no color all the time, the item goes away and in next second is back, with new name. It should be fine, I guess. (I have that one as last thing in my list of calendars, so the scrollbar didn't move done after the addition of the calendar, but I doubt it's your issue.)