Just installed the new 3.3.0 version on debian lenny from .deb package.
I execute /opt/libreoffice/program/soffice from a terminal (kconsole). After the splash, on the toolbar I select file -> open (or ctrl+O) and nothing happen. Tried a lot of times, but nothing happen.
So I close the main frame (upper right X or ctrl+f4). the main windows disappear, but soffice doesn't free me the shell and I must SIGINT it (via ctrl-c).
I note: in the mean time that I close main windows and ctrl-c the program, the soffice process use the 100% of the cpu.
Tried a lot of time, and always the same behavior.
I don't know if it's interesting, but I have also OOo 3.2.
strace /opt/libreoffice/program/soffice doesn't say me, but I send it if need.
Yes, please do attach the strace - it sure will be useful. and probably a backtrace too (esp. if you can install the debug symbols).
For ref: http://wiki.documentfoundation.org/BugReport
(In reply to comment #1)
> Yes, please do attach the strace - it sure will be useful. and probably a
> backtrace too (esp. if you can install the debug symbols).
> For ref: http://wiki.documentfoundation.org/BugReport
Created attachment 42593 [details]
I seem to be facing the same problem. Details of my set-up:
Architecture: amd64 (mostly stable)
LibreOffice Build: 3.3.0 x86_64
JRE: Sun JDK 220.127.116.11
Please find the attached strace of the process generated with:
strace -f -tt -s 512 libreoffice
Take note of the large number of "read(5, 0x1e2fac4, 4096) = -1 EAGAIN (Resource temporarily unavailable)" messages towards the end of file (no idea if those could be related in any way).
Created attachment 43299 [details]
Strace when trying to perform "Open File" operation followed by closing the application
For what it's worth, I've tested this out a bit further.
I made a clean install of Debian Lenny on VirtualBox machine, installed LXDE on top of it (minimal installation from the netinstall disc), and installed LibreOffice deb packages afterwards. Both open and save dialogues showed-up ok.
Then I created an entirely new account under my Gentoo desktop, logged in, fired-up the LibreOffice, and once again all worked fine. Now, the bizarre part is that afterwards I logged in onto my main account, fired-up Nautilus once, then fired-up LibreOffice, and it had _worked_. In other words, I'm starting to believe this might be some kind of weird issue pertaining to configuration settings, and in particular related either to Nautilus, or some settings related to the use of Nautilus or file-selection in general. Another interesting thing is that shutting down Nautilus and any children it had managed to spawn doesn't result in open/save dialogues not being shown, i.e. everything resumes to work fine. Upon log-out and log-in, the dialogues won't show-up until I start Nautilus once again.
Any ideas which configuration file might cause the problems?
I've done some further testing using the working account.
I've tracked the problem to the KeePassX application.
Here are scenarios in which LibreOffice will show open and save dialogues:
1. Start LibreOffice, do not start KeePassX.
2. Start LibreOffice, start KeePassX _afterwards_.
3. Start KeePassX, start Nautilus, start LibreOffice.
Here are scenarios in which LibreOffice will not show open and save dialogues:
1. Don't start Nautilus, start KeePassX, start LibreOffice.
2. Start LibreOffice, start KeePassX, _close_ LibreOffice, start LibreOffice _again_.
I have observed the exact same behaviour on the Debian Lenny (mind you, that's a fresh install), and I'm baffled to say the least. In case of Debian Lenny I didn't even copy over any configuration files, just used it straight with all defaults.
This seems to be some kind of Qt4 weirdness. I've tried the same scenarios on Debian Lenny, this time with qcake application (which is also Qt4-based) instead of KeePassX, and same thing happened. Using a qgit application (which is based on Qt3), the problem was not present.
Ok, finally figured this out. This is related to detection of desktop environment in some way, and by the default file picker which is used for this purpose.
For start, let's take a look at this output (before starting KeePassX):
test@marks ~ $ strace -ff libreoffice 2>&1 | grep kde
[pid 14301] open("libvclplug_kdelx.so", O_RDONLY) = 4
Now, let's take a look at what happens _after_ the KeePassX has been started:
test@marks ~ $ strace -ff libreoffice 2>&1 | grep kde
[pid 14332] open("libvclplug_kdelx.so", O_RDONLY) = 4
[pid 14333] open("/usr/lib64/libreoffice/program/../basis-link/program/kdebe1.uno.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 14333] open("/usr/lib64/libreoffice/program/../basis-link/program/fps_kde.uno.so", O_RDONLY) = 22
[pid 14342] execve("/usr/local/bin/kdefilepicker", ["kdefilepicker", "--winid", "25165939"], [/* 62 vars */] <unfinished ...>
[pid 14342] execve("/usr/bin/kdefilepicker", ["kdefilepicker", "--winid", "25165939"], [/* 62 vars */]) = -1 ENOENT (No such file or directory)
[pid 14342] execve("/bin/kdefilepicker", ["kdefilepicker", "--winid", "25165939"], [/* 62 vars */] <unfinished ...>
[pid 14342] execve("/opt/bin/kdefilepicker", ["kdefilepicker", "--winid", "25165939"], [/* 62 vars */] <unfinished ...>
[pid 14342] execve("/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.4/kdefilepicker", ["kdefilepicker", "--winid", "25165939"], [/* 62 vars */] <unfinished ...>
In other words, it attempts to use the binary /usr/bin/kdefilepicker for selecting a file, and since I have no KDE installed, it fails. And it locks after it cannot find it.
Now, what I did to resolve this issue was to remove the following library from LibreOffice installation:
I'm guessing that library is somehow related to detecting KDE environment.
On further inspection on Debian Lenny, I've discovered that the above library is part of the libobasis3.3-core01 package. When it comes down to RPM's, which are used by the Gentoo, this file is part of the package. Could this be an error in packaging then, since there seems to be a separate package for KDE integration called libobasis3.3-kde-integration?
I'm guessing that in case of "Save" dialogue, the same problem occurs, but I haven't tested it.
Tried the just released 3.3.1 version and the same...
(In reply to comment #10)
> Tried the just released 3.3.1 version and the same...
I also had the same problem. On an earlier release I had the problem described under 32313 - an application crash. The advice given there: Tools>Options>LibreOffice>General and tick Use LibreOffice dialogs fixes it.
Would there be other problems if this option were made the default? If not it might be a quick fix for both problems, especially as 32313 is categorised as a blocker.
(In reply to comment #11)
> (In reply to comment #10)
> > Tried the just released 3.3.1 version and the same...
> I also had the same problem. On an earlier release I had the problem described
> under 32313 - an application crash. The advice given there:
> Tools>Options>LibreOffice>General and tick Use LibreOffice dialogs fixes it.
I can confirm that this does solve the issue even with fps_kde.uno.so in place.
> Would there be other problems if this option were made the default? If not it
> might be a quick fix for both problems, especially as 32313 is categorised as a
That'd be more of a workaround than a real solution. The real solution would probably require having a more reliable way to detect the DE the user is running (for the sake of better desktop integration). For example, the kdefilepicker should be checked for either during start-up or prior to executing it, and using a fallback in case the binary is not present.
Unfortunately, I don't know squat about Java, so no way to supply a patch :)
Maybe this bug should be marked a duplicate of #32313? (noting that the backtraces and comments from this report might be useful)
I installed LibreOffice 3.3.2 on Centos-5.6 with KDE
KDE crashes whenever the save button is pressed.
The solution to this is to put
OOO_FORCE_DESKTOP=gnome ; export OOO_FORCE_DESKTOP
in the file /usr/bin/libreoffice
So that it looks like this
OOO_FORCE_DESKTOP="gnome" ; export OOO_FORCE_DESKTOP
exec /opt/libreoffice/program/soffice "$@"
And everything will be fine.
You can see the snapshots before and after at
The crash screenshot
The modified file screenshot
The result with the save dialog working
Another solution to the problem in Centos 5.6 KDE 3.5.4-25
Tools -> Options -> General -> Use LibreOffice dialogs
Also works without the /usr/bin/libreoffice file being modified.
The problem with this is if there are multiple users on a machine (eg the system is run as a Linux Terminal Server serving many users on thin clients) each user has to do this setting.
The previous way the users don't have to do anything.
Set the options like this
The result with the save dialog working in the KDE mode
*** This bug has been marked as a duplicate of bug 31109 ***