Created attachment 125018 [details]
Another debug output

Reporter: could you install the abiword-debug rpm as well, to get a more
interesting stack trace?

I would if yum could find one in fedora-extras :-)

[root@localhost ~]# yum install abiword-debuginfo
Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
development                                                          [1/2]
development               100% |=========================| 1.1 kB    00:00
extras-development                                                   [2/2]
extras-development        100% |=========================| 1.1 kB    00:00
Reading repository metadata in from local files
Parsing package install arguments
No Match for argument: abiword-debuginfo
Nothing to do
[root@localhost ~]# yum install abiword-debug
Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
development                                                          [1/2]
extras-development                                                   [2/2]
Reading repository metadata in from local files
Parsing package install arguments
No Match for argument: abiword-debug
Nothing to do

Oops ignore that last comment.... found them :-)

OK here you go... let me know if you need any more debuginfo packages installed.

Backtrace was generated from '/usr/bin/AbiWord-2.4'

Using host libthread_db library "/lib/libthread_db.so.1".
`shared object read from target memory' has disappeared; keeping its symbols.
[Thread debugging using libthread_db enabled]
[New Thread -1209067856 (LWP 18301)]
0x002fe402 in __kernel_vsyscall ()
#0  0x002fe402 in __kernel_vsyscall ()
#1  0x002c2a13 in ?? () from /lib/libpthread.so.0
#2  0x04af2086 in libgnomeui_segv_handle (signum=6) at gnome-ui-init.c:792
#3  <signal handler called>
#4  0x002fe402 in __kernel_vsyscall ()
#5  0x00b36159 in *__GI_raise (sig=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#6  0x00b376e3 in *__GI_abort () at abort.c:88
#7  0x00b6aa1b in __libc_message (do_abort=2, 
    fmt=0xc27c74 "*** glibc detected *** %s: %s: 0x%s ***\n")
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:170
#8  0x00b7551f in *__GI___libc_free (mem=0xa38b748) at malloc.c:5608
#9  0x057ca9ad in FcStrFree () from /usr/lib/libfontconfig.so.1
#10 0x057c52a7 in FcValueListDestroy () from /usr/lib/libfontconfig.so.1
#11 0x057c55cb in FcPatternDestroy () from /usr/lib/libfontconfig.so.1
#12 0x00a7c7af in XftInitFtLibrary () from /usr/lib/libXft.so.2
#13 0x00a7c9a4 in XftFontManageMemory () from /usr/lib/libXft.so.2
#14 0x00a7ca5f in XftFontClose () from /usr/lib/libXft.so.2
#15 0x0824b930 in ~XAP_UnixFont (this=0xa21feb8) at xap_UnixFont.cpp:272
#16 0x0823d74b in ~XAP_UnixFontManager (this=0xa21e070)
    at ../../../../src/af/util/xp/ut_hash.h:145
#17 0x082392b4 in ~XAP_UnixApp (this=0xa190148) at xap_UnixApp.cpp:140
#18 0x0813e5d4 in ~AP_UnixApp (this=0xa190148) at ap_UnixApp.cpp:184
#19 0x0814005f in AP_UnixApp::main (szAppName=0x83ec743 "AbiWord", argc=1, 
    argv=0xbfd18e04) at ap_UnixApp.cpp:1545
#20 0x0813bcca in main (argc=) at UnixMain.cpp:26

Thread 1 (Thread -1209067856 (LWP 18301)):
#0  0x002fe402 in __kernel_vsyscall ()
No symbol table info available.
#1  0x002c2a13 in ?? () from /lib/libpthread.so.0
No symbol table info available.
#2  0x04af2086 in libgnomeui_segv_handle (signum=6) at gnome-ui-init.c:792
	estatus = 84
	sa = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
  sa_mask = {__val = {0, 170428032, 77201410, 0, 77256380, 11637252, 5906392, 
      3085945192, 3218178036, 3218178056, 5838185, 3218178036, 5908496, 46, 
      3085906080, 1, 0, 1, 0, 0, 0, 4294967292, 1, 5837431, 2859049, 
      77213710, 77246900, 3218178040, 77211540, 16825381, 77213710, 0}}, 
  sa_flags = 5908496, sa_restorer = 0}
	pid = 

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

I am seeing this bug with abiword-2.4.4-2.fc5 (line offsets on a backtrace
are slightly different).  It looks like that a reliable way to reproduce it
is to open two (existing?) files and then to quit the application.

Besides the following complaints show often in the situation described above:

(AbiWord-2.4:1877): GModule-CRITICAL **: g_module_close: assertion `module !=
NULL' failed
(AbiWord-2.4:1877): libgsf:msole-CRITICAL **: ole_get_block: assertion `block <
ole->info->max_block' failed

A complaint from glibc is slightly different that the one quoted in the
original report:

*** glibc detected *** abiword: munmap_chunk(): invalid pointer:
0x0000000001084b60 ***

but maybe this is x86_64 specific?

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

Nope, it's not x86_64 specific. 

FIXED in abiword-2_4_4-4_fc5, which is being built at this very moment.

While I still see in abiword-2.4.4-4.fc5 messages like:

(AbiWord-2.4:1877): GModule-CRITICAL **: g_module_close: assertion
`module != NULL' failed
(AbiWord-2.4:1877): libgsf:msole-CRITICAL **: ole_get_block: assertion 
`block < ole->info->max_block' failed

a crash reported in the original report indeed looks like gone.  Thanks!

Should these "CRITICAL" get their own bugzilla entry or there is no point?

The first is bug 190579.

The second is the wordperfect importer, where we 'abuse' libgsf to scan for WP
documents in a partial OLE stream. You can ignore that one.