GNOME Bugzilla – Bug 616318
Don't use an unitialized key in folder_changed_remove_uid
Last modified: 2010-04-27 11:07:16 UTC
Stacktrace:
+ Trace 221479
Thread 10570 (Thread 0x97a3fb70 (LWP 25090))
Thread 10560 (Thread 0xa25ffb70 (LWP 25079))
Thread 10550 (Thread 0x9aeffb70 (LWP 25068))
Thread 10548 (Thread 0x9ba0eb70 (LWP 25063))
Thread 5614 (Thread 0xb3b6eb70 (LWP 31584))
Thread 5613 (Thread 0xa15fdb70 (LWP 31583))
Thread 15 (Thread 0xace9fb70 (LWP 29732))
Thread 14 (Thread 0xad6a0b70 (LWP 29731))
Thread 11 (Thread 0xb1ffbb70 (LWP 29728))
Thread 9 (Thread 0xb27fcb70 (LWP 29726))
Thread 8 (Thread 0xb2ffdb70 (LWP 29725))
Thread 7 (Thread 0xb37feb70 (LWP 29724))
Thread 4 (Thread 0xb519bb70 (LWP 29721))
Thread 3 (Thread 0xb599cb70 (LWP 29720))
Thread 1 (Thread 0xb6290760 (LWP 29688))
could be a dupe of bug 586520 Could you please install debug info packages of evolution-data-server, evolution and provide us better traces, tia.
+ Trace 221490
Thread 612 (Thread 0xb45ffb70 (LWP 4267))
Thread 596 (Thread 0xae69cb70 (LWP 4248))
Thread 592 (Thread 0xaba11b70 (LWP 4243))
Thread 16 (Thread 0xad69ab70 (LWP 2584))
Thread 15 (Thread 0xade9bb70 (LWP 2583))
Thread 11 (Thread 0xaeea3b70 (LWP 2577))
Thread 10 (Thread 0xafa12b70 (LWP 2576))
Thread 9 (Thread 0xb2dfcb70 (LWP 2575))
Thread 7 (Thread 0xb35fdb70 (LWP 2573))
Thread 4 (Thread 0xb519bb70 (LWP 2570))
Thread 3 (Thread 0xb599cb70 (LWP 2569))
Thread 1 (Thread 0xb6290760 (LWP 2540))
Stacktrace has nothing to do with bug 586520. Unless, of course, you think the underlying cause is the same.
The suspicious bits are in
+ Trace 221491
0xbe30 is out of bounds and, however, uid is passed as a lookup key to g_hash_table_lookup_extended().
The suspicious code is this: if (g_hash_table_lookup_extended (unmatched_uids, vuid, (gpointer *)&oldkey, &oldval)) { n = GPOINTER_TO_INT (oldval); if (n == 1) { g_hash_table_remove (unmatched_uids, oldkey); if (vee_folder_add_uid_test (folder_unmatched, sub, uid, hash)) camel_folder_change_info_add_uid (folder_unmatched->changes, oldkey); g_free (oldkey); } else { g_hash_table_insert (unmatched_uids, oldkey, GINT_TO_POINTER (n-1)); } } else { if (vee_folder_add_uid_test (folder_unmatched, sub, uid, hash)) camel_folder_change_info_add_uid (folder_unmatched->changes, oldkey); } g_hash_table_lookup_extended() returns FALSE when the key is not found, and hence the oldkey will not be set. That's why I suspect oldkey is uninitialized when camel_folder_change_info_add_uid() is called.
Moving to eds.
Created attachment 159235 [details] [review] [PATCH] Don't use an unitialized key in folder_changed_remove_uid() If g_hash_table_lookup_extended() returns FALSE, then the oldkey is unset, so don't use it to insert a new item in the hash table. Fixes bug 616318. --- camel/camel-vee-folder.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
Above patch is untested but you get the idea.
Thanks for a bug report and the patch. The change makes sense, good catch with it. By the way, Akhil has right, it's the same issue, your lines are just slightly moved due to (I guess) newer sources. Nonetheless, here's the patch, so the older bug will be marked as a duplicate of this.
Created commit c5bbcdc in eds master (2.31.1+) Created commit 134b84e in eds gnome-2-30 (2.30.2+)
*** Bug 586520 has been marked as a duplicate of this bug. ***