Apache OpenOffice (AOO) Bugzilla – Issue 41437
Gnome file picker crashes on fedora core 3
Last modified: 2005-02-19 09:32:55 UTC
REPRODUCTION: ============== 1. start OO.o 1.9.74 on FC3. 2. launch File/Open =>crash soffice.bin reports: "symbol lookup error: /usr/lib/libgnomevfs-2.so.0: undefined symbol: xmlTextReaderConstName"
presumably because the libxml2 included in the OOo build itself is missing symbols which gnomevfs hauled in by the fpicker requires. i.e. > cd /opt/openoffice.org1.9.74/program > objdump -T libxml2.so.2.5.11 | grep xmlTextReaderConstName <nothing> > objdump -T /usr/lib/libxml2.so.2 | grep xmlTextReaderConstName 00100972 g DF .text 000000e6 Base xmlTextReaderConstName 00101980 g DF .text 00000085 Base xmlTextReaderConstNamespaceUri try this to verify in the program dir > rm libxml2.so.2.5.11 > cp /usr/lib/libxml2.so.2.6.16 . > ln -sf libxml2.so.2.6.16 libxml2.so.2 if this is the case, then updating libxml2 would resolve the issue
Thanks CMC for the quick response. Indeed as you suggested copying libxml2.so.2.6.14 into the office program dir and symlinking it to libxml2.so.2 solved the problem. How shall we proceed? Hand this issue over to RE folks? US->MH: would it be feasible to update libxml2? Or do we have to face new drawbacks?
Adding owner of libxml2 to list of CC.
For my builds I've been using libxml2.so.2.6.14 for some time, there are no inherent problems with it. I propose simply bumping to 2.6.14 for the P1. Long term I would suggest that rpm packages simply have a "Requires" libxml2 and not include their own libxml2.
This is not Fedora only, I can reproduce this with Debian unstable too. ii libxml2 2.6.11-5 GNOME XML library
bumped libxml2 to version that supports the required api in cmcfixes1
Adagio... Sorry should have made that more clearly: we are not yet decided how to proceed. From what I've learned we have three different possibilities: 1) Fix the gtk file picker in a way that he can run as a different process. Would presumably require a wrapper modul and what ever kind of communication channel (UNO?). 2) Remove libxml2 from OO.o's program dir and make the existence of that lib on the system a *hard* requirement in the respective rpm. 3) (the "libfreetype2 method") Still provide libxml2 in OO.o but extract it to a folder that isn't covered by OO.o's LD_LIBRARY_PATH. Then in rpm-post-install determine whether the system has libxml2 and if not do a symlink to OO.o's program dir. @Caolan: I will provide a pro/cons table later on, but first of all we'd need a rough estimation of efford (in a sense of 1day/week/month) needed if we would go for #1.
Such an external launcher would have to spawned in an environment without the new soffice set LD_LIBRARY_PATH or it would pick up on the libxml2 in the program dir. It would probably take me a week or so to break it up into internal external dir and repipe the logic through yet another channel. A real pain in the ass and fragile sounding. libxml2 is a system component for gnome so if you have gnome you have libxml2, 2 or 3 seem most logical to me.
+----------------------+-----------------------+-----------------------+ | Possible solution | PROs | CONs | +----------------------+-----------------------+-----------------------+ | 1)Fix gtk-file-picker| -no more dependency to| -big efford (~1Week) | | | OO.o's system libs | -fragile | +----------------------+-----------------------+-----------------------+ | 2) Make existence of | -no library version | -possible rejection of| | system library a hard| clash | solution by UE or mar| | requirement | | keting folks (->admin| | | | istration efford) | | | | -big testing efford | | | | for dependent modules| | | | (XMLsecurity, XForms)| | | | -probs w. incompatible| | | | changes on lib | +----------------------+-----------------------+-----------------------+ | 3) "libfreetype2 me- | -use of system lib => | -big testing efford | | thod": only use | no version clash | for dependent modules| | OO.o's version of | -will still work when | (XMLsecurity, XForms)| | libxml2 if not | system lib unavailabl| -OO.o will crash when | | available on systm| | system-libxml is in- | | | | stalled after OO.o | +----------------------+-----------------------+-----------------------+
The above table is just a first shot. Probably many aspects are still missing. There are also more possible solutions. @CMC: be assured that we are going to fix this one before Beta; and that it is probably not you who'll have to fix this. But we need a solution that is accepted by everyone who is affected by libxml2. What we are surely not accepting is a silently increased library version as attempted by issue 41531.
:-), I'd the workspace built so rather than throw it away... 2 looks best to me, if you simply do 2 and in your set of rpms provide a single libxml2 rpm and have a Requires libxml > 2.6.whateveritis in the other rpms, if you're system doesn't provide it then you use that one. easy and safe and libxmls author (employed by us of course) is very careful to avoid incompatible api changes. I'm sure people like the JDS team would prefer not to have multiple libxml2's in their system to worry about if there is e.g. a security fix released for libxml2
The above sounds all very reasonable to me. And it's very likely that we will proceed exactly as you proposed. And for a short time solution for Beta we may also simply increase the library version, but this needs some testing in advance.
To avoid confusion: from what I understand the currently preferred solution is to put the most current libxml2 into a seperate package which would only be installed inside OO.o if not already present on the system. For a short time solution for Beta the installation method wouldn't change but the library would be upgraded to the most current version assuming it wouldn't cause any regression on the depening modules.
Where would our libxml2 rpm install libxml2.so to ? /usr/lib ? If not, it must not claim to provide libxml2.so functionality, because it will fool other packages requiring libxml2. Installing to /usr/lib bears the risk that some linux verndor may choose a different package name than libxml2, do that all rpm checks fail in this regards. However, since even Novell/SuSE installs libxml2.so into /usr/lib with the package name being "libxml2", this risk might be low enough.
If we install inside OOo, we can not have rpm dependencies to libxml2 in any of the core packages.
*** Issue 41590 has been marked as a duplicate of this issue. ***
*** Issue 41531 has been marked as a duplicate of this issue. ***
US->CMC: if you don't mind I'll set back to 'FIXED' an reassign to myself for verification.
damn, forgot to reassign first.
Now, really reassigning.
Setting back to 'FIXED'.
*** Issue 41929 has been marked as a duplicate of this issue. ***
WORKAROUND: =========== /Tools/Options/OpenOffice.org/General Mark the CheckBox "Use OpenOffice dialogs".
Verified in cws 'cmcfixes1'.
*** Issue 42009 has been marked as a duplicate of this issue. ***
*** Issue 42024 has been marked as a duplicate of this issue. ***
Verified the fix on MasterWorkSpace m78. Closing Fixed/Verified issue.
*** Issue 42246 has been marked as a duplicate of this issue. ***
*** Issue 42362 has been marked as a duplicate of this issue. ***
*** Issue 42449 has been marked as a duplicate of this issue. ***
*** Issue 42961 has been marked as a duplicate of this issue. ***
Reopening because it is NOT fixed it m79.
@singelton: could you a bit more specific, pls. * What Linux distri are you using? * Version of libxml2 and libgnomevfs installed on your system? * Which are the concrete steps to reproduce? e.g. does it crash on saving? does it (not) crash if you once open the File/Open and then cancel; before saving * What is the error message displayed in the shell? * Can you debug the problem and provide a call stack?
Ok, the problem seems to be inside libgnomevfs. See issue 43004 and http://bugzilla.gnome.org/show_bug.cgi?id=166852 Closing again as fixed.
Closing Fixed/Verified issue again.
I picked up a new copy of m79 and indeed it behaves. I would recommend some caution though about depending on the gnome bugfix. To quote http://bugzilla.gnome.org/show_bug.cgi?id=166852: "The latest version of gnome-vfs has this sort of fixed. It allows cancellation from multiple threads, but requires some work from the app to handle a possible race. I've also fixed this race in the gnome-vfs file selector backend." Sort of in the above entry make me nervous.
*** Issue 43039 has been marked as a duplicate of this issue. ***
Concerning the entry from Gnome bugzilla: Please note that "the latest version" is probably the 2.9.x version, i.e. the forthcoming 2.10 will be the first stable one to have that fixed.