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 <g...@unixarea.de> - w http://www.unixarea.de/
_______________________________________________
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-list
