Majic

Seeing that the <a href="http://www.libreoffice.org/">LibreOffice</a> package has been just "soft-masked" as testing in Gentoo, I've decided to uninstall the <a href="http://www.openoffice.org/">OpenOffice.org</a> and give it a go. I was particularly interested about the support for <em>OOXML</em> standard (sic). This started off yesterday in what was supposed to be a simple and fast installation of pre-built binary package through the portage tree. As it turned out, I was in for a surprise...

I fired up the LibreOffice, rather surprised by the speed with which it started-up, created a new OpenOffice.org document, and then tried to open-up the <em>Save As</em> option. And... It froze. Out of the blue sky. I found this quite annoying, and decided to see if I can open up some of my existing <em>odt</em> files, my CV in particular. I killed the runaway process, started LibreOffice again, clicked on the <em>Open</em> button, and... Nothing... Nada... Zilch... It just ignored me. Now this got me a bit worried, to be honest, because if this is what LibreOffice promises to be, we might have a problem... I closed the LibreOffice window only to find it peaking at 100% CPU usage. I had no choice but to kill it once again.

Several quick searches later, and I've run into a bug report on the <a href="http://www.freedesktop.org/wiki/">freedesktop.org</a> site, number <a href="https://bugs.freedesktop.org/show_bug.cgi?id=33575">33575</a>. Seeing nothing useful in the bug report, I created a strace on the LibreOffice process, and attached it to the bug, hoping for some useful input by devs. In the meantime I've had a chat with someone on the #libreoffice channel at <a href="http://freenode.net/">FreeNode</a>, only to discover he had no such troubles, and that the bug sounded rather weird to him. In order to verify that the bug exists, I've decided to test LibreOffice on Debian Lenny as well. I've opted to make a fresh install on top of <a href="http://www.virtualbox.org/">VirtualBox</a>. This lead to a number of restarts due to freezing-up of installer. One VirtualBox upgrade and newer Debian Lenny netinstall disc download later, and I've finally managed to set-up a Debian Lenny machine with LXDE running on top of it. I installed LibreOffice on it, ran it, and found out that it works without a hitch.

Suspecting some kind of configuration mess with my main account on my Gentoo box, I created a fresh user on it, and logged-in into an LXDE environment. And... LibreOffice seemed to work ok in it. This left me a bit wondering, so I tried playing a bit with lots of things within my own account, like removing some settings, testing if I have some stale temporary files and the like. In the end I thought it could be something related to Gnome/GTK+ itself, so I ran nautilus to see if it'll list the files properly. As expected, it worked fine. I fired up LibreOffice again just to give it one final go before giving up, and... The open file dialogue had actually appeared this time! Once again I logged-out of my account, logged-in, started LibreOffice to see if the dialogue will show-up again, it didn't, fired-up Nautilus, then restarted LibreOffice, and file open dialogue worked as expected!

This had certainly left me both dazed and confused, especially since the other account on the same box worked without any Nautilus start-up beforehand. Anyway, it was already quite late at that point, so I opted to go to bed and to post my findings in the morning.

Once I got back to the problem in the morning, I've posted several remarks on what I had tested so far to the bug-tracker, and what had appeared to have solved the issue, and then set-out to figuring out which part of my configuration might be causing the issue. I copied over the entire <em>.config</em> directory to the testing account's home directory, and logged-in with it again. This time around LibreOffice refused to work properly. I've also noticed I had some applications auto-start for me, which annoyed me, so I decided to remove those apps from the autostart. One more log-out and log-in later, and... Suddenly the open dialogue was working in LibreOffice!

I thought I had finally managed to find myself a culprit, so I started firing-up applications one by one, restarting LibreOffice on each occasion, and testing the open file functionality. As it turned out, the application which seems to have caused the issue was the KeePassX, a useful utility for remembering the passwords. The next half an hour or so I spent running straces on LibreOffice and KeePassX, trying to find out if they open any common files and such which could lead to trouble. At some point I was suspecting the Gnome's ORBit2 sockets, but since I wanted to be sure the problem stems from KeePassX I also tried the same set-up on my Debian Lenny virtual machine. As it turns out, the problem appeared there as well, but that version of KeePassX didn't touch ORBit2 sockets at all.

The next thing I wanted to find out is whether the problem happens with all Qt-based applications or not. After asking around on IRC for recommendations on a Qt-based application to try, I found out about qgit (thanks, MinceR). I've noticed the qgit is a Qt3-based application, while the KeePassX was built using Qt4 (same as on Gentoo). Suspecting it might be related to specific version of Qt, I've found another application written for Qt4 in the repository called QCake, and installed it. I've experienced the exact same symptoms as with KeePassX, so next-up for testing was the qgit. As it turned out, qgit didn't cause any trouble, so that ruled-out any issues when it comes down to Qt3 apps.

After that it was back to stracing for me, trying to figure out what in the world might the processes be opening. As I was looking at the binaries coming with LibreOffice, I've noticed something <em>unusual</em> - there was a kdefilepicker binary present. Given the fact that this binary is probably used for picking files under KDE (d'oh), I've decided to run some grep'ing on binaries and the like for a string 'kde'. Nothing useful turned out, but then I opted for grep'ing the strace output for strings like <em>kde</em>, <em>gtk</em>, and <em>gnome</em> in various scenarios I tested so far. Soon I found out that when I start KeePassX prior to LibreOffice, the LibreOffice attempts to execute kdefilepicker in the background through an <em>execve</em> call. Another thing I've noticed is that it really can't do that since I have no KDE, and even the above bundled binary is missing lots of libraries to start-up (which I've also managed to verify by actually running the binary and seeing errors pertaining to loading of KDE libs).

All in all, several quick tests later with different ordering of firing up KeePassX and Nautilus, and I've finally come to conclusion that there seems to be some code that detects the environment in a way, and that KeePassX seems to triggers the change. I was guessing that the whole thing might function completely dynamically, and with some advice from a local IRC user (thanks going to MinceR once again for posting me a link to file list of Debian OpenOffice.org KDE package) I've pinpointed this to a single shared library - <em>fps_kde.uno.so</em>. After renaming that shared library starting KeePassX or any other Qt4-based application didn't bear any consequence on the open/save file dialogue functionality.

And what are the lessons learned from this debugging session? <em>Don't</em> assume everyone is using KDE or Gnome desktop environments when trying to integrate packages more tightly. There are many people out there (like myself) who very often run something thinned-down with a set of applications coming from different desktop environments which can confuse the detection of desktop environment. Or, at the very least, separate packages properly and maybe allow user to override default settings (and don't rely blindly on availability of binaries and libraries if you're loading them dynamically).

Finally, If you're interested you can find some more concrete details at the aforementioned bug report.