Re: g_str_hash() problem

[Owen Taylor <otaylor redhat com>]

Brandon Corey <brandon blackboxcentral com> writes:

> I'm having a problem while running a program named pan.  It uses the
> entire gtk kit, and crashes while trying to read a null pointer in
> g_str_hash().
> 
> I'm running glib 2.0.6, atk 1.0.3, pango 1.0.4, and gtk 2.0.6.  Here
> is the output from purify:
> 
> ****  Purify instrumented ./pan.pure (pid 17201)  ****
> ZPR: Zero page read:
>    * This is occurring while in thread 65536:
> 	g_str_hash     [gstring.c:75]
> 	g_hash_table_lookup [ghash.c:192]
> 	pango_x_list_subfonts [pangox.c:1116]
> 	find_char      [basic-x.c:254]
> 	basic_engine_get_coverage [basic-x.c:694]
> 	pango_x_face_get_coverage [pangox-fontmap.c:1535]
> 	pango_x_font_get_coverage [pangox.c:1371]
> 	pango_font_get_coverage [fonts.c:1043]
> 	pango_fontset_simple_get_font [pango-fontset.c:364]
> 	pango_fontset_get_font [pango-fontset.c:86]
>    * Reading 1 byte from 0x1
> 
> The actual call that causes the crash is:
> g_str_hash (gconstpointer key)
> {
> 	const char *p = key;
> 	guint h = *p;
> 
> Where the above *p (key) is a NULL pointer.
> So it tries to read the value at the location of NULL pointer p.
> 
> I looked at all of the functions mentioned, and it uses a lot of
> function pointers which purify can't handle..  If anyone could give me
> an idea of what's going on here, I'd definitely appreciate it.
> g_str_hash() obviously doesn't expect the key to be a null pointer
> (since it doesn't check for it)..

Things went wrong long before the call to g_str_hash() - probably
in find_char() call. This is almost certianly the same crash as:

  http://bugzilla.gnome.org/show_bug.cgi?id=91658

My guess on the bug (at the bottom) is that it is some sort
of threading problem in Pan.

Regard,s
                                        Owen