Claws Mail Bugzilla – Bug 164
Crash on rebuild folder tree
Last modified: 2003-06-22 19:23:06
You need to log in before you can comment on or make changes to this bug.
Upgraded to 0.9.0claws1, selected "Rebuild folder tree" and received this crash. Sylpheed version 0.9.0claws1 GTK+ version 1.2.10 Features: gdk-pixbuf libcompface GNU/aspell Operating system: Linux 2.4.20 (i686) C Library: GNU libc 2.3.1 -- [New Thread 16384 (LWP 30825)] 0x4023eeb9 in wait4 () from /lib/libc.so.6 #0 0x4023eeb9 in wait4 () from /lib/libc.so.6 #1 0x402bc214 in __DTOR_END__ () from /lib/libc.so.6 #2 0x081434cc in crash_handler (sig=30869) at crash.c:541 #3 <signal handler called> #4 0x0808f9e8 in folder_item_get_name (item=0x0) at folder.c:715 #5 0x0807101b in folderview_update_node (folderview=0x822d220, node=0x82953dc) at folderview.c:1104 #6 0x08071211 in folderview_update_node (folderview=0x822d220, node=0x8295370) at folderview.c:1199 #7 0x0807170d in folderview_update_item (source=0xbfffeb30, data=0x822d220) at folderview.c:1218 #8 0x08159de0 in hooks_marshal (hook=0xfffffe00, data=0xbfffeb30) at hooks.c:102 #9 0x404f47cd in g_hook_list_marshal () from /usr/lib/libglib-1.2.so.0 #10 0x08159e4b in hooks_invoke ( hooklist_name=0xfffffe00 <Address 0xfffffe00 out of bounds>, source=0xfffffe00) at hooks.c:120 #11 0x080944c9 in folder_item_update (item=0xfffffe00, update_flags=0) at folder.c:2799 #12 0x080908a7 in folder_item_scan (item=0x8292458) at folder.c:1269 #13 0x0808f255 in folder_scan_tree_func (node=0xfffffe00, data=0xfffffe00) at folder.c:414 #14 0x404fc6bc in g_node_traverse_post_order () from /usr/lib/libglib-1.2.so.0 #15 0x404fc68f in g_node_traverse_post_order () from /usr/lib/libglib-1.2.so.0 #16 0x404fb81e in g_node_traverse () from /usr/lib/libglib-1.2.so.0 #17 0x0808f2cb in folder_scan_tree (folder=0x8296b88) at folder.c:435 #18 0x08070a7b in folderview_rescan_tree (folder=0x8296b88) at folderview.c:828 #19 0x403e4c98 in gtk_item_factory_callback_marshal () from /usr/lib/libgtk-1.2.so.0 #20 0x403f4486 in gtk_marshal_NONE__NONE () from /usr/lib/libgtk-1.2.so.0 #21 0x4042c816 in gtk_handlers_run () from /usr/lib/libgtk-1.2.so.0 #22 0x4042ba3d in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0 #23 0x404296d2 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0 #24 0x4046d6ed in gtk_widget_activate () from /usr/lib/libgtk-1.2.so.0 #25 0x403fe244 in gtk_menu_shell_activate_item () from /usr/lib/libgtk-1.2.so.0 #26 0x403fd447 in gtk_menu_shell_button_release () from /usr/lib/libgtk-1.2.so.0 #27 0x403f40b6 in gtk_marshal_BOOL__POINTER () from /usr/lib/libgtk-1.2.so.0 #28 0x4042ba82 in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0 #29 0x404296d2 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0 #30 0x4046d398 in gtk_widget_event () from /usr/lib/libgtk-1.2.so.0 #31 0x403f3d5f in gtk_propagate_event () from /usr/lib/libgtk-1.2.so.0 #32 0x403f2c84 in gtk_main_do_event () from /usr/lib/libgtk-1.2.so.0 #33 0x404c20b5 in gdk_event_dispatch () from /usr/lib/libgdk-1.2.so.0 #34 0x404f807e in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #35 0x404f7e39 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #36 0x404f6d94 in g_main_run () from /usr/lib/libglib-1.2.so.0 #37 0x403f270f in gtk_main () from /usr/lib/libgtk-1.2.so.0 #38 0x080698c1 in main (argc=1, argv=0xbffff6f4) at main.c:359 #39 0x401a6dc4 in __libc_start_main () from /lib/libc.so.6
Why the hell does folder_scan_tree (see folder.c) destroy the tree first, and then do the naughty thing below??? Am I missing something? Keith, if this is reproducable, can you move the tree deletion below the node_traverse?
*** Bug 168 has been marked as a duplicate of this bug. ***
This backtrace is strange. The backtrace shows that it crashed in line 715, but the call to folder_item_get_name shows that item is NULL. In this case it should have crashed much easier at 682 where item is accessed for the first time. Secondly folderview_update_node should never call folder_item_get_name when item is NULL. After fetching item from the ctree is checks if item is NULL and should never get to folder_item_get_name when it is NULL. Maybe the stack got destroyed somewhere. In this case the backtrace is not useable.
Aren't we looking at access to data that may have been freed alread?
Maybe. The NULL pointer is still strange and should not be possible. We probably need a hook to notify the folderview about changes in the tree to let it know that it's FolderItem pointers are no longer valid. Currently the folderview rebuilds the tree itself after a command like add folder or remove folder was executed. I think the problem is that the folderview does a recursive update to all child nodes and these can be folders that have been freed in the folder tree rebuild. So it must be like this folder.c: rescans folder tree folder.c: send notify about changed folder tree folderview.c: update ctree to make sure it does not contain invalid pointers folder.c: scan folder folder.c: send content change notify folderview.c: can now safely update child nodes, because it updated it's folderitem pointers before
fixed in 0.9.0claws55