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

[Matthias Apitz <guru unixarea de>]

El día Thursday, April 28, 2011 a las 04:13:40PM +0100, David Woodhouse escribió:

> On Thu, 2011-04-28 at 16:54 +0200, Matthias Apitz wrote:
> > I've rebuild glib-2.26.1 and evo-exchange 2.32.3 (removing my changes)
> > with gcc46; the problem remains:
> >
> > Server is up and running...
> > [Thread 2997d200 (LWP 100749/e-calendar-factory) exited]
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 29804300 (LWP 100639/initial thread)]
> > 0x29e28d87 in ?? ()
> > (gdb) bt
> > #0  0x29e28d87 in ?? ()
> > #1  0x290edaf8 in g_hash_table_lookup () from
> > /usr/local/lib/libglib-2.0.so.0
> > #2  0x29f9e43e in e2k_autoconfig_lookup_option (
> >     option=0x29fcf520 "Disable-Plaintext") at _ctype.h:106 
>
> Can you do that with debugging symbols for glib? That just *shouldn't*
> crash; g_hash_table_lookup() is being given a valid, but empty, hash
> table and should return NULL.
>
> The world is broken.

Yes, it seems so.

I've compiled all, in that order: glib20, evo-dataserver 2.32.3 and evo-exchange 
2.32.3 with 'gcc46 -O0 -g' and the bt looks like always:

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
#2  0x2911067b in g_hash_table_lookup (hash_table=0x29850e90, key=0x29ffc520)
    at ghash.c:252
#3  0x29fcb43e in e2k_autoconfig_lookup_option (
    option=0x29ffc520 "Disable-Plaintext") at _ctype.h:106

the key=0x29ffc520 is fine 

(gdb) p (char *)key
$13 = 0x29ffc520 "Disable-Plaintext"

and if one looks into the code for g_hash_table_lookup_node() it reads
glib-2.26.1/glib/ghash.c:

g_hash_table_lookup_node (GHashTable    *hash_table,
                          gconstpointer  key)
{
  ...

  hash_value = (* hash_table->hash_func) (key);
  if (G_UNLIKELY (hash_value <= 1))
    hash_value = 2;

(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}

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>

What I also do not understand is that:

(gdb) up
#1  0x2913ab4d in g_hash_table_lookup_node (hash_table=0x29850e90, 
    key=0x2a087520) at ghash.c:252
252       for (i = 0; i < shift; i++)

i.e. the line number 252 and the code line presented by gdb does not
match the place where g_hash_table_lookup_node() is in ghash.c;

I'm now clueless :-(

        matthias

-- 
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <guru unixarea de> - w http://www.unixarea.de/