Re: [Evolution] evolution-2.32.1 (FreeBSD HEAD) && calendar not working

[David Woodhouse <dwmw2 infradead org>]

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.