Heya, abiword should not call xmlCleanupParser(), otherwise it will break PA because it deletes TLS variables that do not belong to it. See the end of this clone bug report:

+++ This bug was initially created as a clone of Bug #532307 +++


abrt detected a crash.


How to reproduce
-----
1.
2.
3.


Comment
-----
I was not working with Empathy when this crash happened, it ran on background.

Additional information
======


Attached files
----
backtrace

cmdline
-----
empathy 


component
-----
empathy


executable
-----
/usr/bin/empathy


kernel
-----
2.6.31.5-96.fc12.i686.PAE


package
-----
empathy-2.28.1.1-3.fc12


reason
-----
Process was terminated by signal 6

--- Additional comment from <email address hidden> on 2009-11-01 14:14:52 CET ---

Created an attachment (id=367009)
File: backtrace

--- Additional comment from <email address hidden> on 2009-11-04 14:24:14 CET ---

Again the same crash today.

--- Additional comment from <email address hidden> on 2009-11-04 19:24:45 CET ---

Looking at the backtrace it looks like this crash is caused by pulseaudio.  Reassigning bug.

--- Additional comment from <email address hidden> on 2009-11-05 02:49:33 CET ---

Hmm, that's pthread_setspecific() failing. I don't see how that could ever fail, especially since we call pthread_getspecific() right before.

Is there any reliable way to reproduce this? I'd be very interested in the exact return value if pthread_setspecific() there.

--- Additional comment from <email address hidden> on 2009-11-05 07:27:51 CET ---

It crashes about once a day. I'll try get the return value.

--- Additional comment from <email address hidden> on 2009-11-08 21:39:43 CET ---

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

--- Additional comment from <email address hidden> on 2009-11-08 21:44:31 CET ---

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

--- Additional comment from <email address hidden> on 2009-11-09 20:55:44 CET ---

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

--- Additional comment from <email address hidden> on 2009-11-10 03:41:15 CET ---

Any luck so far?

--- Additional comment from <email address hidden> on 2009-11-10 09:58:10 CET ---

It seems this bug is triggered much less when Empathy runs within gdb.
It crashed on Friday, but I failed to get the pthread_setspecific() return value (gdb crashed when I tried to reload debug infos).

I still run Empathy with gdb. 

I'll try to add some debugging output to PulseAudio and recompile it. Then I can run it without gdb.

--- Additional comment from <email address hidden> on 2009-11-11 21:20:46 CET ---

When I download pulseaudio fedora CVS repository, run "make local" in F-12 and install the result (all rpms, or just the pulseaudio-0.9.19-2 rpm, or just libpulsecore-*.so), the pulseaudio daemon cannot start.

Nov 11 21:03:33 localhost pulseaudio[2718]: fdsem.c: Assertion 'pa_atomic_dec(&f
->data->waiting) >= 1' failed at pulsecore/fdsem.c:283, function pa_fdsem_before
_poll(). Aborting.

Is there some other way to run the patched version?

--- Additional comment from <email address hidden> on 2009-11-16 15:49:16 CET ---


This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from <email address hidden> on 2009-11-16 16:36:26 CET ---

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

--- Additional comment from <email address hidden> on 2009-11-17 20:37:26 CET ---

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

--- Additional comment from <email address hidden> on 2009-11-17 20:38:40 CET ---

Created an attachment (id=369945)
Another backtrace

--- Additional comment from <email address hidden> on 2009-11-20 18:11:51 CET ---

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

--- Additional comment from <email address hidden> on 2009-11-21 21:19:33 CET ---

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

--- Additional comment from <email address hidden> on 2009-11-24 15:00:42 CET ---

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

--- Additional comment from <email address hidden> on 2009-11-25 01:05:07 CET ---

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

--- Additional comment from <email address hidden> on 2009-11-25 22:13:24 CET ---

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

--- Additional comment from <email address hidden> on 2009-11-26 14:37:10 CET ---

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

--- Additional comment from <email address hidden> on 2009-11-27 17:55:57 CET ---

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

--- Additional comment from <email address hidden> on 2009-11-29 21:12:19 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-01 18:13:01 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-03 15:32:54 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-03 19:11:19 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-04 00:11:04 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-04 23:54:59 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-05 00:11:26 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-06 15:27:32 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-06 20:20:58 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-07 23:47:30 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-08 16:07:07 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-08 17:13:07 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-09 00:33:22 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-09 16:55:25 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-10 00:06:11 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-10 04:15:41 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-10 18:19:21 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-10 18:28:51 CET ---

(In reply to comment #9)
> Any luck so far?  

Lennart,

I'm also getting this crash daily, and by the looks of it, so are a bunch of other people.

I've just installed a patched version of pulseaudio which should give the return value of pthread_setspecific when it inevitably crashes tomorrow. However, I'm going to go out on a limb and say that from the 2 possibilities (ENOMEM and EINVAL), it's going to be EINVAL. Looking at the code in thread.h, the most obvious reason for this would be use of the thread local object after its destructor had been called. Not being familiar at all with this codebase myself, does that sound right? What additional debug info would you want?

Matt

--- Additional comment from <email address hidden> on 2009-12-11 13:03:31 CET ---

Created an attachment (id=377717)
Patch to collect requested debug information when pthread_setspecific() fails

--- Additional comment from <email address hidden> on 2009-12-11 13:06:33 CET ---

Right on cue, it crashed again this morning. This time I'd applied the patch from Comment #41 and rebuild pulseaudio. As expected, output was:

22: Invalid argument

--- Additional comment from <email address hidden> on 2009-12-12 19:04:05 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-13 14:21:16 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-14 19:01:34 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-14 19:05:13 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-14 19:08:20 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-14 19:14:33 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-14 19:16:12 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-14 19:16:25 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-14 19:18:27 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-14 19:19:41 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-14 19:22:10 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-14 19:28:18 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-14 22:42:35 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-15 20:56:56 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-16 00:01:53 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-16 12:32:36 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-17 15:19:10 CET ---

(In reply to comment #40)
> (In reply to comment #9)
> > Any luck so far?  
> 
> Lennart,
> 
> I'm also getting this crash daily, and by the looks of it, so are a bunch of
> other people.
> 
> I've just installed a patched version of pulseaudio which should give the
> return value of pthread_setspecific when it inevitably crashes tomorrow.
> However, I'm going to go out on a limb and say that from the 2 possibilities
> (ENOMEM and EINVAL), it's going to be EINVAL. Looking at the code in thread.h,
> the most obvious reason for this would be use of the thread local object after
> its destructor had been called. 

That is unlikely. We actually build the library with -z nodelete precisely to avoid issues like that. 

Thanks for figuring out that EINVAL is the error cause, unfortunately this still is not precise enough to figure out fully what is going on here...

--- Additional comment from <email address hidden> on 2009-12-18 01:35:21 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-19 17:20:12 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-19 17:22:43 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-20 15:46:24 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-20 16:54:43 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-21 02:53:08 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-21 02:53:47 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-21 02:54:20 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-22 05:53:17 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-22 15:42:17 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-22 15:44:03 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-23 03:46:09 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-23 18:41:36 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-24 02:46:05 CET ---

I found something that may be of interest.  I have had Abiword crash and the traceback always referred to Pulse Audio.  My bug report got marked as a duplicate of this bug, so I am providing input here.

On a whim, I selected Preferences/Sound.  On the Sound Effects tab, I had previously selected the checkbox for Enable window and button sounds.  I decided to uncheck the box and try the same operation (paste text into Abiword, then select it and attempt to resize it) that would previously cause Abiword to abend immediately.  This time, however, Abiword completed the operations without fault.

To summarize:
Sound Preferences "Enable window and button sounds enabled--Abiword crashes
Sound Preferences "Enable window and button sounds disabled--Abiword works.

--- Additional comment from <email address hidden> on 2009-12-25 23:30:43 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-28 18:00:56 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-28 18:02:20 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-29 21:25:28 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-29 23:18:38 CET ---

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

--- Additional comment from <email address hidden> on 2009-12-31 23:02:55 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-01 05:28:56 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-01 05:32:13 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-01 05:32:20 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-01 18:36:53 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-02 06:38:12 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-02 22:37:59 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-02 22:41:00 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-02 22:42:43 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-02 22:45:19 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-02 22:57:13 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-02 22:58:40 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-03 23:27:23 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-04 15:33:10 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-04 17:30:13 CET ---

I can confirm Stephen Haffly's steps to reproduce and make them more specific.
This is 100% reproducible for me:
1. Make sure you have "Enable window and button sounds" enabled in gnome-volume-control.
2. Run "abiword".
3. Paste a text into Abiword from Firefox or OpenOffice.org Writer.
   (Use one of these two applications in order to have the text copied as rich text with formatting. Pasting simple text from gedit or gnome-terminal won't reproduce the bug. It does not matter whether you use select and middle-click or CTRL+C, CTRL+V.)
4. Now almost any action (resize text, clicking in menus, ...) in Abiword will crash it with:

Assertion 'pthread_setspecific(t->key, userdata) == 0' failed at pulsecore/thread-posix.c:200, function pa_tls_set(). Aborting.

--- Additional comment from <email address hidden> on 2010-01-04 21:36:02 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-04 23:56:41 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-05 15:10:34 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-05 17:21:52 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-06 02:13:24 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-06 16:25:07 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-06 22:07:05 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-07 04:49:37 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-07 14:37:27 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-07 14:59:52 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-07 19:28:27 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-12 00:13:53 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-12 00:26:46 CET ---

Oh man this is so stupid. I just dropped the majority of the duplicates from this bug again because they have NOTHING to do with PA. Guys, this is not a dumpster for your bugs you don't have any use for anymore.

Please, from now on this bug should be only about PA related crashes, more specifically about pthread_setspecific() failing in pa_tls_set(), nothing else. If you get an abort() in the pa_tls_set() stack frame this is where to duplicate it to, but please, don't dup any other bugs on this, I have a hard time reading through all the noise here. Thanks.

--- Additional comment from <email address hidden> on 2010-01-12 00:28:46 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-12 00:29:19 CET ---

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

--- Additional comment from <email address hidden> on 2010-01-12 03:34:04 CET ---

Hmm, I have not been able to reproduce this unfortunately. Not sure where to begin debugging. The hints in #93 did not cause this issue to be hit for me. Michal, is that on 32bit or 64bit?

Anyone else has a good idea how I could reproduce this issue?

--- Additional comment from <email address hidden> on 2010-01-12 15:10:23 CET ---

(In reply to comment #109)
> Hmm, I have not been able to reproduce this unfortunately. Not sure where to
> begin debugging. The hints in #93 did not cause this issue to be hit for me.
> Michal, is that on 32bit or 64bit?

I'm using x86_64. F12 with updates-testing enabled.

--- Additional comment from <email address hidden> on 2010-01-12 22:58:03 CET ---

I added a few debug prints in src/pulsecore/thread-posix.c to debug PA's TLS usage.
When running the steps to reproduce using abiword, the results was this:

pa_tls_new, pthread=0x7fb5dde4d710, tid=3045: created key 4
pa_tls_set, pthread=0x7fb5dde4d710, tid=3045: replacing value for key 4. previous=(nil) new=0x1d29fb0
pa_tls_get, pthread=0x7fb5f33867c0, tid=3044: got value for key 4, it's (nil)
pa_tls_set, pthread=0x7fb5f33867c0, tid=3044: replacing value for key 4. previous=(nil) new=0x1d36c80
pa_tls_get, pthread=0x7fb5f33867c0, tid=3044: got value for key 4, it's 0x1d36c80
pa_tls_get, pthread=0x7fb5f33867c0, tid=3044: got value for key 4, it's 0x1d36c80
pa_tls_get, pthread=0x7fb5f33867c0, tid=3044: got value for key 4, it's 0x1d36c80
pa_tls_get, pthread=0x7fb5f33867c0, tid=3044: got value for key 4, it's 0x1d36c80
pa_tls_get, pthread=0x7fb5f33867c0, tid=3044: got value for key 4, it's 0x1d36c80
pa_tls_get, pthread=0x7fb5f33867c0, tid=3044: got value for key 4, it's 0x1d36c80
pa_tls_get, pthread=0x7fb5f33867c0, tid=3044: got value for key 4, it's 0x1d36c80
pa_tls_get, pthread=0x7fb5f33867c0, tid=3044: got value for key 4, it's 0x1d36c80
### this is when I pasted some text from OOo ###
pa_tls_get, pthread=0x7fb5f33867c0, tid=3044: got value for key 4, it's (nil)
pa_tls_set, pthread=0x7fb5f33867c0, tid=3044: replacing value for key 4. previous=(nil) new=0x1d463f0
Assertion 'pthread_setspecific(t->key, userdata) == 0' failed at pulsecore/thread-posix.c:216, function pa_tls_set(). Aborting.

Notice how the value for key 4 got erased suddenly without any pa_tls_*() calls in between the two consecutive calls to pa_tls_get(). This tells me that something else than PA fiddles with thread-specific data. A possible explanation could be that something called pthread_key_delete() in between and destroyed key 4.

So I ran abiword under gdb, placing breakpoints at pthread_key_create() and pthread_key_delete(). And really, this revealed about 80 calls to pthread_key_delete(), all with a backtrace like this:

Breakpoint 2, pthread_key_delete (key=4) at pthread_key_delete.c:31
31	  if (__builtin_expect (key < PTHREAD_KEYS_MAX, 1))
#0  pthread_key_delete (key=4) at pthread_key_delete.c:31
#1  0x0000003d24038085 in xmlCleanupParser__internal_alias () at parser.c:14044
#2  0x0000003d2363da57 in UT_XML::~UT_XML() () from /usr/lib64/libabiword-2.8.so
#3  0x0000003d2363de0a in UT_XML_Decode(char const*) () from /usr/lib64/libabiword-2.8.so
#4  0x0000003d235370b7 in AP_Prefs::loadBuiltinPrefs() () from /usr/lib64/libabiword-2.8.so
#5  0x0000003d23537172 in AP_Prefs::fullInit() () from /usr/lib64/libabiword-2.8.so
#6  0x0000003d23497ae7 in AP_UnixApp::initialize(bool) () from /usr/lib64/libabiword-2.8.so
#7  0x0000003d23498169 in AP_UnixApp::main(char const*, int, char**) () from /usr/lib64/libabiword-2.8.so
#8  0x0000003d1841eb1d in __libc_start_main (main=<value optimized out>, argc=<value optimized out>, ubp_av=<value optimized out>, 
    init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=<value optimized out>) at libc-start.c:226
#9  0x0000000000400889 in _start ()

Deleting an already deleted key is clearly a bug. I believe this specific case is a bug in abiword - it should not call libxml2's xmlCleanupParser() unless it's going to exit really soon (a source comment in libxml2 has a big WARNING about it).

What does anything from what I wrote to do with empathy? I don't know. Maybe empathy misuses libxml2 in a similar way. I don't use empathy. And right now I'm on an extremely crippled Internet connection to even download it.

--- Additional comment from <email address hidden> on 2010-01-12 23:50:39 CET ---

Ah, wonderful. That could be it. Empathy in fact *does* call that function quite often, judging by the code:

http://git.gnome.org/browse/gossip/tree/src/gossip-contact-groups.c#n224

Will reassign to empathy again.

--- Additional comment from <email address hidden> on 2010-01-12 23:52:58 CET ---

Hmm, and a google code search kinda suggests that everyone and his dog is calling that function where he shouldn't.