Description of problem: probably a colateral damage due to a massive atack of x-caja-desktops! Version-Release number of selected component: libreoffice-core-4.1.0.4-6.fc19 Additional info: reporter: libreport-2.1.6 backtrace_rating: 4 cmdline: /usr/lib64/libreoffice/program/soffice.bin --writer --splash-pipe=5 crash_function: __memcpy_ssse3_back executable: /usr/lib64/libreoffice/program/soffice.bin kernel: 3.10.7-200.fc19.x86_64 runlevel: N 5 uid: 1000 Truncated backtrace: Thread no. 1 (5 frames) #0 __memcpy_ssse3_back at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:2171 #1 memcpy at /usr/include/bits/string3.h:51 #2 ICEConnectionWorker at /usr/src/debug/libreoffice-4.1.0.4/vcl/unx/generic/app/sm.cxx:631 #3 osl_thread_start_Impl at /usr/src/debug/libreoffice-4.1.0.4/sal/osl/unx/thread.c:251 #5 capset at ../sysdeps/unix/syscall-template.S:83
Created attachment 789331 [details] File: backtrace
Created attachment 789332 [details] File: cgroup
Created attachment 789333 [details] File: core_backtrace
Created attachment 789334 [details] File: dso_list
Created attachment 789335 [details] File: environ
Created attachment 789336 [details] File: exploitable
Created attachment 789337 [details] File: limits
Created attachment 789338 [details] File: maps
Created attachment 789339 [details] File: open_fds
Created attachment 789340 [details] File: proc_pid_status
Created attachment 789341 [details] File: var_log_messages
(In reply to Nivag from comment #0) > probably a colateral damage due to a massive atack of x-caja-desktops! Yes, one thread getting a fatal XIOError that leads to exit and the atexit handlers being called, while another thread happens to use stuff that is cleaned up by the atexit handlers. I think it would make sense to install an XIOError handler that itself calls _exit or abort, to at least prevent this kind of "collateral" backtrace where the crash happens at another place than where the real problem is.
(In reply to Stephan Bergmann from comment #12) > I think it would make sense to install an XIOError handler that itself calls > _exit or abort, to at least prevent this kind of "collateral" backtrace > where the crash happens at another place than where the real problem is. That will land in libreoffice-4.1.1.2-2.fc19.
libreoffice-4.1.1.2-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/libreoffice-4.1.1.2-2.fc19
*** Bug 1000680 has been marked as a duplicate of this bug. ***
Package libreoffice-4.1.1.2-2.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libreoffice-4.1.1.2-2.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-15304/libreoffice-4.1.1.2-2.fc19 then log in and leave karma (feedback).
# yum update --enablerepo=updates-testing libreoffice-4.1.1.2-2.fc19 Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit No Match for argument: libreoffice-4.1.1.2-2.fc19 No package libreoffice-4.1.1.2-2.fc19 available. No packages marked for update
(In reply to Nivag from comment #17) > # yum update --enablerepo=updates-testing libreoffice-4.1.1.2-2.fc19 > Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit > No Match for argument: libreoffice-4.1.1.2-2.fc19 > No package libreoffice-4.1.1.2-2.fc19 available. > No packages marked for update please note the "should be available at your local mirror within two days" (it did work fine for me right now, though)
# yum update --enablerepo=updates-testing libreoffice-4.1.1.2-2.fc19 Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit Package(s) libreoffice-4.1.1.2-2.fc19 available, but not installed. No packages marked for update # if I try to 'install' rather than 'update', it lists umpteen packages to install/upgrade, but no indication that it will remove the existing 4.1.0 packages - I have 4.1.0.4-6.fc19 currently installed.
libreoffice-4.1.1.2-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.