Given "I get many oosplash processes," how exactly do you start LibreOffice.  Repeatedly by typing "soffice" or "libreoffice" into a shell, or by selecting multiple LibreOffice documents in a file manager, or ...?

Also, "soffice.bin cannot be killed"---so there is just a single soffice.bin process, not multiple ones, right?  Do you know whether it is still running from your previous intensive use (so LibreOffice would only have appeared to have terminated, but the process kept running), or did it get started afresh?

Are you comfortable with generating backtraces for running processes via gdb?  If yes, it would be great to get them for the hung soffice.bin: "gdb - <pid>", then at the gdb prompt "thread apply all backtrace", ideally with the the libreoffice-debguinfo package installed.

I used to click on a single file (xlsx or doc) and as Libreoffice didn't start, I clicked on same file many times.

Anyway i find only one soffice.bin process.

I don't find the libreoffice-debuginfo package!!!

I suppose that libreoffice-gdb-debug-support is the correct name!!!

(In reply to comment #3)
> I suppose that libreoffice-gdb-debug-support is the correct name!!!

No, it is not. Debuginfo packages are in extra repository that is not enabled by default. Just run

debuginfo-install libreoffice-core

as root in a terminal.

> I don't find the libreoffice-debuginfo package!!!

"sudo debuginfo-install libreoffice-core" should do the trick.


> I suppose that libreoffice-gdb-debug-support is the correct name!!!

That is another useful package to make the gdb-generated backtraces even nicer: it contains some Python plug-ins that let gdb pretty-print certain LibreOffice-specific data structures.

Created attachment 713733 [details]
File error for libreoffice-debuginfo installation

when I run suggested command I get the output of attached file.
Something is wrong, 1,4 GB installed!!

(In reply to comment #6)
> Created attachment 713733 [details]
> File error for libreoffice-debuginfo installation
> 
> when I run suggested command I get the output of attached file.
> Something is wrong, 1,4 GB installed!!

So you installed libreoffice-3.6.5.2-8.fc18.i686 from updates-testing, so would need to do "sudo debuginfo-install --enablerepo=updates-testing libreoffice-core".  To avoid downloading any dependency debuginfo packages you could do something like "sudo yum install --enablerepo=updates-testing,updates-testing-debuginfo --nodeps libreoffice-debuginfo libreoffice-gdb-debug-support", but even that would amount to a huge download.

If that is not an option for you, it would still be useful to get the gdb backtraces from the soffice.bin process (see comment 1) even without the libreoffice-debuginfo package installed.  Sorry for the trouble this takes.

if soffice is PID 3128
 and I issue gdb - 3128 (after freezing) nothin happens.

or sure, I am not an expert in debugging.

Anyway, I am noting that freeze occurs more frequently on networked files

(In reply to comment #8)
> if soffice is PID 3128

that is the PID of soffice.bin, right?

>  and I issue gdb - 3128 (after freezing) nothin happens.

What exactly do you mean with "nothing happens"?  This should lead to a number of informative lines spit out by gdb as it starts up, and then a line with a "(gdb)" prompt where it waits for your command---where you would enter "thread apply all backtrace" to get the backtraces of all the threads of the hung soffice.bin process (which you can follow by "kill", confirming with "y", to terminate the soffice.bin process, and then "quit" to exit gdb again).

Or does starting gdb hang for you as well (never reach the "(gdb)" prompt line)?

> Anyway, I am noting that freeze occurs more frequently on networked files

So the freeze could also be a network-related long timeout.  Unfortunately hard to tell without further information.

never reach the "(gdb)" prompt line....

gdb - PID works if soffice.bin is not yet frozen

(In reply to comment #10)
> never reach the "(gdb)" prompt line....

So this starts to look rather odd.  The last resort to extract useful information out of this could be if you have a scenario that starts with calling

  soffice

from a shell and reliably leads to a freeze, make sure any soffice, oosplash, soffice.bin processes have been terminated again, then run

  strace -f soffice >LOG 2>&1

from that shell and do anything necessary to get it to freeze, then make available the resulting LOG file (which likely is huge, so you may want to compress it).

(In reply to comment #11)
> gdb - PID works if soffice.bin is not yet frozen

In which case, another line of attack could be to type "continue" at the gdb prompt, carry on using LibreOffice until it freezes, then hit Control-C in the gdb shell to get back the "(gdb)" prompt and type "thread apply all backtrace".

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.