Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | mixing neon and the hidden embedded contents old another neon inside libhttp.so of gnome-vfs2 is unreliable | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | ucb | Reporter: | stress4ever <stressfreechozeme> | ||||||||
Component: | code | Assignee: | tkr <tobias.krause> | ||||||||
Status: | CLOSED FIXED | QA Contact: | issues@ucb <issues> | ||||||||
Severity: | Trivial | ||||||||||
Priority: | P3 | CC: | caolanm, issues, mmeeks, philipp.lohmann | ||||||||
Version: | OOo 2.3.1 | ||||||||||
Target Milestone: | OOo 3.0 | ||||||||||
Hardware: | All | ||||||||||
OS: | Linux, all | ||||||||||
Issue Type: | PATCH | Latest Confirmation in: | --- | ||||||||
Developer Difficulty: | --- | ||||||||||
Attachments: |
|
Description
stress4ever
2007-12-18 03:41:02 UTC
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. *** |