GNOME Bugzilla – Bug 537665
Crash in online-prefs-sync-daemon on login
Last modified: 2008-09-14 12:26:54 UTC
When running the whole GNOME session under valgrind I see a crash in online-prefs-sync-daemon in the logs: ==8058== Invalid read of size 1 ==8058== at 0x4186F2A: g_str_hash (gstring.c:95) ==8058== by 0x41508FF: g_hash_table_lookup_node (ghash.c:118) ==8058== by 0x41508BE: g_hash_table_lookup (ghash.c:663) ==8058== by 0x804C8E7: hippo_dbus_helper_filter_message (hippo-dbus-helper.c:1834) ==8058== by 0x407BF24: dbus_connection_dispatch (dbus-connection.c:4393) ==8058== by 0x405708C: message_queue_dispatch (dbus-gmain.c:101) ==8058== by 0x416097F: g_main_dispatch (gmain.c:2063) ==8058== by 0x4161E4F: g_main_context_dispatch (gmain.c:2615) ==8058== by 0x41623A4: g_main_context_iterate (gmain.c:2696) ==8058== by 0x4162B80: g_main_loop_run (gmain.c:2919) ==8058== by 0x804FE10: main (main.c:1196) ==8058== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==8058== ==8058== Process terminating with default action of signal 11 (SIGSEGV) ==8058== Access not within mapped region at address 0x0 ==8058== at 0x4186F2A: g_str_hash (gstring.c:95) ==8058== by 0x41508FF: g_hash_table_lookup_node (ghash.c:118) ==8058== by 0x41508BE: g_hash_table_lookup (ghash.c:663) ==8058== by 0x804C8E7: hippo_dbus_helper_filter_message (hippo-dbus-helper.c:1834) ==8058== by 0x407BF24: dbus_connection_dispatch (dbus-connection.c:4393) ==8058== by 0x405708C: message_queue_dispatch (dbus-gmain.c:101) ==8058== by 0x416097F: g_main_dispatch (gmain.c:2063) ==8058== by 0x4161E4F: g_main_context_dispatch (gmain.c:2615) ==8058== by 0x41623A4: g_main_context_iterate (gmain.c:2696) ==8058== by 0x4162B80: g_main_loop_run (gmain.c:2919) ==8058== by 0x804FE10: main (main.c:1196)
I was fixing another bug from launchpad: https://bugs.launchpad.net/ubuntu/+source/consolekit/+bug/196724 and I came across this. Very interesting. It seems that g_hash_table_lookup_node will do strange things if there are no entries in the table. It seems that if everything is removed, then the "nodes" variable will be a null pointer and will break the lookup as it doesn't check if there is nothing in the table.
hash_table->nodes is never NULL. It is always an array of GHashNode* of size at least HASH_TABLE_MIN_SIZE. The node_ptr in g_hash_table_lookup_node can obviously never be NULL, since it is always set to the address of something.
OK. Perhaps what you should say is that it shouldn't be NULL. There are over 30 duplicates of this kind of problem on Launchpad, plus this one, plus my own one. In my corefile hash_table->nodes = 0x0 and hash_table->nnodes = 0. (gdb) print *hash_table $1 = {size = 6403520, nnodes = 0, nodes = 0x0, hash_func = 0x405738 <g_direct_hash@plt>, key_equal_func = 0x404cd8 <g_direct_equal@plt>, ref_count = 0, version = 66, key_destroy_func = 0, value_destroy_func = 0} The valgrind trace above is consistent with this. So somehow it is possible to remove all nodes from the table and end up with a null pointer to the head node.
I don't see this when running against current 2.23.x built from svn now.