Apache OpenOffice (AOO) Bugzilla – Issue 84676
mixing neon and the hidden embedded contents old another neon inside libhttp.so of gnome-vfs2 is unreliable
Last modified: 2008-07-13 16:39:41 UTC
(I) x.org loaded video driver of... (II) Loading /usr/lib64/xorg/modules//drivers/nvidia_drv.so (--) Depth 24 pixmap format is 32 bpp (III) Desktop is: GNOME (IV) libgcj version is: libgcj-4.1.2-33-x86_64 libgcj-4.1.2-33-i386 (V) kernel is: Linux 2.6.23.8-63.fc8 #1 SMP Wed Nov 21 17:56:40 EST 2007 x86_64 x86_64 x86_64 (VI) OpenOffice.org core rpm version is: openoffice.org-core-2.3.0-6.7.fc8-x86_64 (VII) accessibility is: false (VIII) fedora release is: Fedora release 8 (Werewolf) ...start free space details ... Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 29805520 9186256 19080808 33% / /dev/mapper/VolGroup00-LogVol00 29805520 9186256 19080808 33% / ...end free space details ... ...start sestatus details ... SELinux status: disabled ...end sestatus details ... ...start stackreport details ... 0x0000003735436a64: 0x00000000001ebbe8: /usr/lib64/openoffice.org/program/libuno_sal.so.3 + 0x36a64 0x000000373543785a: 0x00000000001ebbe8: /usr/lib64/openoffice.org/program/libuno_sal.so.3 + 0x3785a 0x000000321920e540: 0x0000000000015da8: /lib64/libpthread.so.0 + 0xe540 0x00002aaabb84d016: 0x0000000000021488: /usr/lib64/libneon.so.27 + 0xc016 0x00002aaabb84d4d6: 0x0000000000021488: /usr/lib64/libneon.so.27 + 0xc4d6 (ne_session_destroy + 0x66) 0x00002aaac2a3a34d: 0x000000000001eb88: /usr/lib64/gnome-vfs-2.0/modules/libhttp.so + 0xc34d 0x0000003731e225a9: 0x00000000000c6a98: /lib64/libglib-2.0.so.0 + 0x225a9 0x0000003731e227af: 0x00000000000c6a98: /lib64/libglib-2.0.so.0 + 0x227af 0x00002aaac2a37b9a: 0x000000000001eb88: /usr/lib64/gnome-vfs-2.0/modules/libhttp.so + 0x9b9a 0x0000003731e2f5db: 0x00000000000c6a98: /lib64/libglib-2.0.so.0 + 0x2f5db 0x0000003731e2eea3: 0x00000000000c6a98: /lib64/libglib-2.0.so.0 + 0x2eea3 (g_main_context_dispatch + 0x1c3) 0x0000003731e3219d: 0x00000000000c6a98: /lib64/libglib-2.0.so.0 + 0x3219d 0x0000003731e326ce: 0x00000000000c6a98: /lib64/libglib-2.0.so.0 + 0x326ce (g_main_context_iteration + 0x6e) 0x00002aaaaf5acb27: 0x000000000004fe68: /usr/lib64/openoffice.org/program/libvclplug_gtk680lx.so + 0x19b27 0x00000037370cffce: 0x00000000003aefe8: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0xcffce (Application::Yield(bool) + 0x3e) 0x00000037370d00a7: 0x00000000003aefe8: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0xd00a7 (Application::Execute() + 0x27) 0x000000373e42d05e: 0x000000000005b458: /usr/lib64/openoffice.org/program/libsoffice.so + 0x2d05e (desktop::Desktop::Main() + 0x13ae) 0x00000037370d5864: 0x00000000003aefe8: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0xd5864 0x00000037370d5955: 0x00000000003aefe8: /usr/lib64/openoffice.org/program/libvcl680lx.so + 0xd5955 (SVMain() + 0x25) 0x000000373e41f65e: 0x000000000005b458: /usr/lib64/openoffice.org/program/libsoffice.so + 0x1f65e (main + 0xae) 0x000000321861e074: 0x0000000000150b60: /lib64/libc.so.6 + 0x1e074 (__libc_start_main + 0xf4) 0x0000000000400639: 0x0000000000000890: /usr/lib64/openoffice.org/program/swriter.bin + 0x639 (main + 0x49) ...end stackreport details ... ...start sample ldd details ... linux-vdso.so.1 => (0x00007fff639fe000) libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x00002aaaaad2d000) libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x00002aaaab31d000) libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x00002aaaab5bd000) libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00002aaaab7dc000) libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00002aaaab9f9000) libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00002aaaabc03000) libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00002aaaabe45000) libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00002aaaac0c3000) libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaac2c6000) libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00002aaaac4ca000) librt.so.1 => /lib64/librt.so.1 (0x00002aaaac6cf000) libdbus-glib-1.so.2 => /usr/lib64/libdbus-glib-1.so.2 (0x00002aaaac8d8000) libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00002aaaacaf7000) libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00002aaaacd33000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00002aaaacf74000) libvclplug_gen680lx.so => /usr/lib64/openoffice.org/program/libvclplug_gen680lx.so (0x00002aaaad23c000) libvcl680lx.so => /usr/lib64/openoffice.org/program/libvcl680lx.so (0x00002aaaad4c7000) libpsp680lx.so => /usr/lib64/openoffice.org/program/libpsp680lx.so (0x00002aaaada81000) libsot680lx.so => /usr/lib64/openoffice.org/program/libsot680lx.so (0x00002aaaadd72000) libutl680lx.so => /usr/lib64/openoffice.org/program/libutl680lx.so (0x00002aaaadfd8000) libtl680lx.so => /usr/lib64/openoffice.org/program/libtl680lx.so (0x00002aaaae277000) libcomphelp4gcc3.so => /usr/lib64/openoffice.org/program/libcomphelp4gcc3.so (0x00002aaaae522000) libucbhelper4gcc3.so => /usr/lib64/openoffice.org/program/libucbhelper4gcc3.so (0x00002aaaae85d000) libuno_cppuhelpergcc3.so.3 => /usr/lib64/openoffice.org/program/libuno_cppuhelpergcc3.so.3 (0x00002aaaaeadb000) libuno_cppu.so.3 => /usr/lib64/openoffice.org/program/libuno_cppu.so.3 (0x00002aaaaed9c000) libvos3gcc3.so => /usr/lib64/openoffice.org/program/libvos3gcc3.so (0x00002aaaaefcc000) libuno_sal.so.3 => /usr/lib64/openoffice.org/program/libuno_sal.so.3 (0x00002aaaaf1f3000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x00002aaaaf5ea000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x00002aaaaf8ef000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaafb00000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002aaaafd1b000) libm.so.6 => /lib64/libm.so.6 (0x00002aaab001c000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002aaab029f000) libc.so.6 => /lib64/libc.so.6 (0x00002aaab04ad000) libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00002aaab0805000) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00002aaab0a0a000) libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00002aaab0c2e000) libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00002aaab0e63000) libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00002aaab106c000) libXi.so.6 => /usr/lib64/libXi.so.6 (0x00002aaab126e000) libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00002aaab1478000) libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00002aaab167f000) libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00002aaab1889000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00002aaab1aba000) libz.so.1 => /lib64/libz.so.1 (0x00002aaab1d49000) /lib64/ld-linux-x86-64.so.2 (0x0000003217400000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00002aaab1f5e000) libcap.so.1 => /lib64/libcap.so.1 (0x00002aaab2176000) libSM.so.6 => /usr/lib64/libSM.so.6 (0x00002aaab237a000) libICE.so.6 => /usr/lib64/libICE.so.6 (0x00002aaab2584000) libi18nisolang1gcc3.so => /usr/lib64/openoffice.org/program/libi18nisolang1gcc3.so (0x00002aaab27a0000) libbasegfx680lx.so => /usr/lib64/openoffice.org/program/libbasegfx680lx.so (0x00002aaab29a5000) libicuuc.so.38 => /usr/lib64/libicuuc.so.38 (0x00002aaab2c11000) libicule.so.38 => /usr/lib64/libicule.so.38 (0x00002aaab2f49000) libjvmaccessgcc3.so.3 => /usr/lib64/openoffice.org/program/libjvmaccessgcc3.so.3 (0x00002aaab317f000) libjvmfwk.so.3 => /usr/lib64/openoffice.org/program/libjvmfwk.so.3 (0x00002aaab3387000) libuno_salhelpergcc3.so.3 => /usr/lib64/openoffice.org/program/libuno_salhelpergcc3.so.3 (0x00002aaab35a4000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002aaab37a8000) libxcb-xlib.so.0 => /usr/lib64/libxcb-xlib.so.0 (0x00002aaab39e1000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00002aaab3be2000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002aaab3dfd000) libexpat.so.1 => /lib64/libexpat.so.1 (0x00002aaab4000000) libicudata.so.38 => /usr/lib64/libicudata.so.38 (0x00002aaab4223000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00002aaab4ecd000) libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00002aaab520c000) ...end sample ldd details ...
MRU->PL: can you please have a look? The crash seems to happen somewhere in gtk stuff of OOo. Maybe the problem is already known...
The stack trace tells differently, namely that this crashes somewhere invoving libgnome-vfs; this is AFAIK only involved in OOo as a UCB service. Nevertheless without a method of reproduction this will not be fixed. Moreover this seems to happen on 64 bit fedora core. Perhaps cmc has an idea, but without a description for reproduction he will not to do much about it either ?
hmm, I'm fairly sure that *I'm* not at fault :-). But I seem to see a whole rats nest of disasters going on. How about this, what happens for others under gnome with soffice davs://www.redhat.com let it load to completion, and then scroll back up to the top of the document ?
https://bugzilla.redhat.com/show_bug.cgi?id=410381 I have a theory, which basically says that any attempt to use libhttp.so from gnome-vfs, e.g. davs:// dav:// https:// is really really unreliable because OOo has either a built-in libneon library or the system one which we dlopen early in our lifetime bring in the neon symbols while gnome-vfs2's libhttp.so has an entire embedded-into-it old copy of neon with the same symbol names which I assume just isn't compatible.
Created attachment 50420 [details] so, given that. Using our neon webdav handler for all such protocols should avoid the brokenness
not a wordprocessor problem anyway, but in the ucb area. Though I'm of the "its all gnome-vfs fault" pov
So any bugs that have libhttp.so *and* libneon.so in the stacktrace are probably all the same collision of version
*** Issue 83765 has been marked as a duplicate of this issue. ***
*** Issue 77361 has been marked as a duplicate of this issue. ***
cmc->ucb maintainer: How about this patch to avoid using gnome-vfs2 for things which gnome-vfs2 uses libhttp and avoid the collision of the ne_* symbols between gnome-vfs2s libhttp.so and our neon
AFAICS gnome-vfs dlopens anything using neon, and it does so in a local / plugin scope: which should be fine - at least, it might mangle gnome-vfs, but shouldn't hurt OO.o (right?). Of course, we have no problems here, but this is most likely down to either using a system neon, or yet another positive side-effect of i#63927# ;-)
What I got here is... nm -D /usr/lib/gnome-vfs-2.0/modules/libhttp.so | grep ne_session_destroy 0000dc10 T ne_session_destroy nm -D /usr/lib/libneon.so.27.0.2 | grep ne_session_destroy 0000abd0 T ne_session_destroy
Sure, it can export those symbols, but if it's loaded RTLD_LOCAL that is rather immaterial, they are loaded into a local scope, OO.o can poison gnome-vfs but not VV. Having said that, it's dead silly to have those plugins exporting symbols at all, we should be using a map-file to remove all but vfs_module_init and vfs_module_shutdown there: that (I guess) might also fix the issue.
Purely by chance I came across this - I assume that nobody complains if I push it to the right owner?
Created attachment 50707 [details] update patch to apply
kso->cmc: The patch is for 2.3.1, right? But IIRC 2.3.1 webdav ucp has no HTTPS support. How should it handle davs-URLs correctly without backporting all HTTPS stuff from src680? Sorry, I see no chance to integrate the patch with the dummy SSL certification callback implementation that always accepts the certificate. No problem to integrate it into 3.x (without the NeonSession.cxx changes, then), though.
The latest patch was against OOH680_m1 ala 2.4.0 branch but sure, 3.x upstream target is fine by me. As you say the accept certificate always is nuts, though that's also effectively what the internal gnome-vfs2 davs/https handler does (!). So this just eventually boils down to a suggestion to add aliases from dav and davs to http and https to handle them the same way.
kso->cmc: > The latest patch was against OOH680_m1 ala 2.4.0 branch but sure, 3.x upstream > target is fine by me. Great. Could you please submit a patch for src680, then. It should be exactly what you already have --with the exception that the NeonSession.cxx changes are not needed. src680 already has a non-dummy SSL certificate validation callback implementation.
Created attachment 50714 [details] this should be sufficient then
kso->cmc: Thanks.
kso->tkr: Please take over. Patch is IMO okay.
.
Tobias is currently on vacation. He will integrate the patch when he is back.
patch applied in cws tkr10
verified
closed
*** Issue 88969 has been marked as a duplicate of this issue. ***
*** Issue 85781 has been marked as a duplicate of this issue. ***