On Fri, 2011-04-29 at 10:48 +0200, Matthias Apitz wrote:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 29804300 (LWP 101032/initial thread)]
> 0x29e55d87 in ?? ()
> (gdb) bt
> #0 0x29e55d87 in ?? ()
> #1 0x2910fb4d in g_hash_table_lookup_node (hash_table=0x29850e90,
> key=0x29ffc520) at ghash.c:252
OK, gdb lies about line numbers sometimes, and often you have to read
between the lines of what it's telling you. What we *can* trust, mostly,
is that g_hash_table_lookup_node()¹ called into some unknown function at
0x29e55d87.
> (gdb) p *hash_table
> $15 = {size = 8, mod = 7, mask = 7, nnodes = 0, noccupied = 0,
> nodes = 0x2a7f9b20, hash_func = 0x29e55d87, key_equal_func = 0x29e55d55,
> ref_count = 1, version = 0, key_destroy_func = 0, value_destroy_func = 0}
Oh look, 0x29e55d87 is what's set as the hash function in your hash
table. And that's where we ended up when we crashed?
Would be interesting to know where this *is*, given that gdb doesn't
seem to have a clue. In Linux I'd ask you to 'cat /proc/$PID/maps' and
see which mmap region it lies within.
> I *think* there is no correct function pointer in the hash_table because #0 is
> pointing in the air; but read_config() inserts one as:
>
> config_options = g_hash_table_new (e2k_ascii_strcase_hash,
> e2k_ascii_strcase_equal);
>
> (gdb) p e2k_ascii_strcase_hash
> $17 = {guint (gconstpointer)} 0x29fe16b7 <e2k_ascii_strcase_hash>
> (gdb) p e2k_ascii_strcase_equal
> $18 = {gint (gconstpointer,
> gconstpointer)} 0x29fe1685 <e2k_ascii_strcase_equal>
So how in hell did your hash_func get set to 0x29e55d87 <wtf> instead of
0x29fe16b7 <e2k_ascii_strcase_hash>?
(That isn't g_direct_hash(), is it?)
I'd put a breakpoint on read_config(), then step through until
immediately after the g_hash_table_new() call. Make sure the hash_func
and key_equal_func have been set to the correct values. If *not* then
dig deeper into g_hash_table_new() of course. But if they *are* OK, then
stick a hardware watchpoint on the hash_func and let it run.
If you get to the same crash, the actual hash table pointer is the same,
and the hash_func is *still* not what you set it to, call a priest.
It *could* be memory corruption; you could try running under valgrind
(make sure you set GSLICE=always-malloc or it gets horridly confused
with the gslice allocator).
--
dwmw2
¹ Or a static function that got inlined into g_hash_table_lookup_node()
but that wasn't it in this case, so I'm mentioning it just for
future reference.
_______________________________________________
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-list
