abrt 1.0.0 detected a crash. Comment: I shutdown laptop while openoffice was running. Attached file: backtrace cmdline: /usr/lib/openoffice.org3/program/swriter.bin -writer component: openoffice.org executable: /usr/lib/openoffice.org3/program/swriter.bin kernel: 2.6.31.6-145.fc12.i686.PAE package: openoffice.org-writer-1:3.1.1-19.14.fc12 rating: 4 reason: Process was terminated by signal 6
Created attachment 376344 [details] File: backtrace
So, the crash is deep inside gcc's exception handling code, but the path that lead to it looks rather suspicious. I bet the application was shutting down when a timer updating toolbar controls was triggered and in the state the application was it couldn't finish normally. The timer itself probably came from a volatile slot; that's been fixed by http://www.openoffice.org/issues/show_bug.cgi?id=83195 . There were several documents opened over WebDAV: it may or may not make a difference.
Thread 1 is the one which is raising the signal that creates the crash, that thread comes all the way from SwAsyncRetrieveInputStreamThread and is inside some webdav foo. I see that Thread 6 is *also* from a SwAsyncRetrieveInputStreamThread and is inside some webdav foo. I rather suspect that the webdav foo isn't thread safe. e.g. two documents opened over webdav with graphics (?) or whatever it is that causes writer to use a SwAsyncRetrieveInputStreamThread thing
These are in gnutls, so... http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applications.html "Although the GnuTLS library is thread safe by design, some parts of Libgcrypt, such as the random generator, are not. Applications have to register callback functions to ensure proper locking in the sensitive parts of libgcrypt." neon itself does this when it initializes gnutls, but gnutls + gcrypt are already initialized by the time neon gets used in OOo because cups also uses gnutls and we initialize that earlier in our life-cycle. cups doesn't configure gcrypt to be threadsafe when initializing gnutls. This might not sufficient to fix all of this but I think its likely necessary.
Created attachment 379603 [details] something like so perhaps
Thanks for the patch. Also affects Fedora 11.
cups-1.4.2-20.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
cups-1.4.2-20.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
Um, is this causing bug #553834?
Appears to: Downgrading cups to cups-1.4.2-18.fc13.x86_64.rpm and restarting cups "makes firefox printing work for me". [I didn't try cups-1.4.2-19.fc13 or later.]