It's not unlikely that this crash is related to Pango not being able
to resolve your fonts. The default fonts are:

    "sans bold 11"
    "sans 11"
    "courier 11"

Could you check your pango config (/etc/pango/pangox.aliases) and see
if  these resolve to existing fonts ?

Also, are you running Pan on a remote display by any chance ?

If you mean by that, can I find those strings in pangox.aliases
(which, in my case, is really in /usr/local/etc/pango), the answer
is no.  They're not in there.

Jim

Hahaha.  Crossing responses...

No, running on local console.

Jim

:-)

Regarding pango:  I'm no Pango expert, but here's the entries from my
pangox.aliases file:

sans normal normal normal normal \
    "-*-helvetica-medium-r-normal--*-*-*-*-*-*-*-*,\
    ...

sans normal normal bold normal \
    "-*-helvetica-bold-r-normal--*-*-*-*-*-*-*-*,\
    ...

which tells Pango how to map the generic 'sans' font name into real
fonts.  Your file should have similar entries, and at least one of the
listed real fonts should exist on your system.

BTW, one of our users had crashes with a similar backtrace on FreeBSD.
He managed to fix them by removing the following flag:

    -Wl,--export-dynamic

http://mail.freesoftware.fsf.org/pipermail/pan-users/2002-August/001827.html

Okay.  I have the same or similar entries.  As far as the listed real
fonts, it'll take me some time to verify those.  (Being as I don't
know where to start.  I'll figure it out.)

As to the flags: color me clueless, but remove "-Wl, --export-dynamic"
from *what*?

Jim

Going from Pan to Pango in the hopes that
someone there is more clueful than us bozos
on the Pan team. :)

*** Bug 94188 has been marked as a duplicate of this bug. ***

*** Bug 97657 has been marked as a duplicate of this bug. ***

*** Bug 98612 has been marked as a duplicate of this bug. ***

Frankly, I have to suspect a Pan bud here since we've had no 
duplicates of this reported for other software. Maybe there 
is a missing gdk_threads_enter()/leave() somewhere? This
looks like a plausible crash if GTK+ was using Pango from
two threads simultaneously.

(I recall that Pan uses GTK+'s thread support, which is a
bit unusual in the general scheme of GTK+ programs)

I wanted to add that I'm having the exact same problem running with Irix on the newest 
version (0.13.2.90):

 ****  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 found out from the above BSD link, that the same thing was possible to fix on this end.  
The --export-dynamic flag to the linker is not set by default on Linux or BSD.  However, on 
Solaris and Irix, the equivalent of that is set by default.  As a side note, on Irix, I 
added the flag -Wl,-exported_symbol (which as listed with no params after hides all 
symbols) to the link line.  After that fix, it runs fine.

Again, this definitely 
points to a symbol conflict with pan and one of the gtk libraries (possibly pango).

If you have a version of Pango before Pango-1.0.5 or
Pango-1.1.1, you may be running into a bug that has
been since fixed:

Tue Aug 20 15:42:33 2002  Owen Taylor  <otaylor@redhat.com>

        * modules/indic/indic-xft.c (maybe_add_SUB_feature):
          modules/indic/indic-xft.c (maybe_add_GPOS_feature):
          modules/indic/indic-ot.c (getOutputIndex)
          modules/hebrew/hebrew-x.c (get_glyph_num)
          modules/basic/basic-x.c (find_char): Fix missing
         statics.

Do you have the current Pango, Brandon?

I've been using pango-1.0.4, but I'll try out 1.0.5 and see how that works.  Do you know if 
1.0.5 is stable?

I think it can be assumed that if I put out a release
in the 1.0.x series (the _stable_ branch of Pango) that
I think it is stable...

Brandon: ping

Sorry I'm taking so long.  I'll get it tried out ASAP and get back
to you.

I've tested this, and the issue has been resolved when using Pango 1.0.5.

Thanks for the update. Closing.


*** This bug has been marked as a duplicate of 100398 ***

*** Bug 100897 has been marked as a duplicate of this bug. ***