Re: g_str_hash() problem

[Brandon Corey <brandon blackboxcentral 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.

Well, after checking the bug link you provided..  I found out that people 
were only getting the problem on other systems when they were using 
--dynamic-export..  which on Linux, is not the default..   However, on 
Solaris and Irix, the linker's equivalent form of --dynamic-export is set 
by default.

After adding the equivalent to the linkline of the Makefile, everything 
seems to work..

That being said, it seems like the problem is a symbol conflict between Pan 
and one of the gtk libraries (most people from the bug report seem to think 
Pango).

Brandon