Re: g_str_hash() problem

[Brandon Corey]

Brandon Corey <[EMAIL PROTECTED]> 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

_______________________________________________
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list