Bug 410381 - mixing neon and gnome-vfs2 libhttp.so usage is incredibly unreliable
mixing neon and gnome-vfs2 libhttp.so usage is incredibly unreliable
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gnome-vfs2 (Show other bugs)
8
i386 Linux
low Severity low
: ---
: ---
Assigned To: Alexander Larsson
Fedora Extras Quality Assurance
:
: 212761 234487 448649 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-04 08:33 EST by Gary Caldwell
Modified: 2008-05-29 22:14 EDT (History)
6 users (show)

See Also:
Fixed In Version: 2.3.0-6.11.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-22 10:42:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
OO generated bug report (14.47 KB, application/vnd.oasis.opendocument.text)
2007-12-04 08:33 EST, Gary Caldwell
no flags Details
valgrind log for reference (3.53 KB, text/plain)
2007-12-06 08:53 EST, Caolan McNamara
no flags Details
and the patch to neon to not crash (1.38 KB, patch)
2007-12-06 08:55 EST, Caolan McNamara
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 77361 None None None Never
OpenOffice.org 83765 None None None Never
OpenOffice.org 84676 None None None Never

  None (edit)
Description Gary Caldwell 2007-12-04 08:33:18 EST
Description of problem:
When copying text from an internet site to a OO document, OO Writer crashes


Version-Release number of selected component (if applicable):

OO 2.3

How reproducible:

Open a OO document in word format (.doc), go to a website, highlight and copy
text and insert into existing document


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info: Bug Report file attached
Comment 1 Gary Caldwell 2007-12-04 08:33:18 EST
Created attachment 277011 [details]
OO generated bug report
Comment 2 Caolan McNamara 2007-12-04 08:52:08 EST
This was reported before and upstream thought it was fixed. Can you tell me from
what website the content was pasted, I've never been able to reproduce this.
Comment 3 Caolan McNamara 2007-12-05 11:07:26 EST
Can you reproduce this ? And if you can, can you share with me from where I
could paste data to reproduce this myself.
Comment 4 Caolan McNamara 2007-12-06 08:52:36 EST
gotcha, its when there is a non-existing https:// address... i.e.

==31191== Invalid write of size 4
==31191==    at 0xF366F3D: ne_ssl_context_create (in /usr/lib/libneon.so.27.0.2)
==31191==    by 0xF357725: ne_session_create (in /usr/lib/libneon.so.27.0.2)
==31191==    by 0x106C1E98: http_acquire_connection (http-neon-method.c:1613)
==31191==    by 0x106C2DA6: http_context_open (http-neon-method.c:1756)
==31191==    by 0x106C3831: do_get_file_info (http-neon-method.c:2947)
==31191==    by 0xBAC6C49: gnome_vfs_get_file_info_uri_cancellable
(gnome-vfs-cancellable-ops.c:202)
==31191==    by 0xBADA392: gnome_vfs_get_file_info_uri (gnome-vfs-ops.c:332)
==31191==    by 0xBADA445: gnome_vfs_get_file_info (gnome-vfs-ops.c:309)
Comment 5 Caolan McNamara 2007-12-06 08:53:25 EST
Created attachment 279721 [details]
valgrind log for reference
Comment 6 Caolan McNamara 2007-12-06 08:55:43 EST
Created attachment 279731 [details]
and the patch to neon to not crash
Comment 7 Joe Orton 2007-12-06 16:22:54 EST
What do you mean by "non-existing" here exactly?  SSL_CTX_new() should only fail
if OpenSSL is not initialized correctly (i.e. ne_sock_init() not called), or on
OOM; both of these are fatal errors.
Comment 8 Joe Orton 2007-12-06 16:27:23 EST
Oh, and w.r.t to the sess->socket = NULL hunk, I'm not sure why that would be
necessary; sess->socket should only subsequently be referenced if
sess->connected were non-zero, which it won't be on that error path.
Comment 9 Caolan McNamara 2007-12-18 08:18:00 EST
Wasn't CC'ed so didn't see comments. Lemesee, looking a little bit deeper this
happens due to a bit of a three car pileup between OOo, neon and gnome-vfs2. I
can't quite get the same problem this time, but I think I can see why it
happened, and why it's sort of difficult to reproduce. This might work...

> /usr/lib/openoffice.org/program/soffice.bin davs://www.redhat.com

let it load and scroll back to the top of the document

OOo effectively links against neon (indirectly dlopens it) so it can handle
http:// links natively. Everything else that OOo doesn't know will be passed to
gnome-vfs2 and in this case gnome-vfs libhttp.so handles davs:// dav:// and
https:// on our behalf. libhttp.so sort of uses neon, but actually just embeds
an old version of neon into itself.

In this case the ne_foo symbols are provided by /usr/lib/libneon... and not the
internal gnome-vfs2 older copy of neon which is the normal case for gnome-vfs2.
At some stage something hideous will happen as they're apparently not
interoperable. 

Assuming I'm right (this time) then there's damn little that neon can do here.

quick solution a) is to short-circuit in OOo all urls which might get sent to
gnome-vfs2 and trigger use of the libhttp.so library, i.e. davs:// dav://
https:// and http://
quick solution b) is to make gnome-vfs2 use the system neon (#416571), or force
the link to the internal neon symbols always, e.g. mangle the function names
Comment 10 Caolan McNamara 2007-12-18 08:54:30 EST
*** Bug 212761 has been marked as a duplicate of this bug. ***
Comment 11 Caolan McNamara 2007-12-18 08:54:57 EST
*** Bug 234487 has been marked as a duplicate of this bug. ***
Comment 12 Caolan McNamara 2007-12-18 09:05:24 EST
Anyway, lets go on that assumption for the moment. Effectively a dup to bugzilla
416571 if its possible to use system neon in gnome-vfs2, otherwise rename/hide
the symbols I guess.
Comment 13 Alexander Larsson 2007-12-19 04:20:45 EST
I think we need to do the rename, as the gnome-vfs copy of neon has a few local
modifications that can't be supported by the system copy of neon.
Comment 14 Joe Orton 2007-12-20 05:44:56 EST
I thought those symbols were hidden already :(

What symbols need to be exposed from libhttp.so in gnome-vfs?  Just
vfs_module_*?  If so just pass -export-symbols-regex '^vfs_module_' to libtool
when linking it, that will hide the neon symbols and should fix this problem.
Comment 15 Fedora Update System 2008-01-06 20:19:08 EST
openoffice.org-2.3.0-6.10.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update openoffice.org'
Comment 16 Fedora Update System 2008-01-15 18:06:34 EST
openoffice.org-2.3.0-6.11.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update openoffice.org'
Comment 17 Fedora Update System 2008-01-22 10:41:56 EST
openoffice.org-2.3.0-6.11.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 18 Caolan McNamara 2008-05-29 15:15:35 EDT
*** Bug 448649 has been marked as a duplicate of this bug. ***
Comment 19 Austin 2008-05-29 22:14:04 EDT
Why wasn't this released back for the Fedora 7 repos too? It exists in
v2.3.0-6.8.fc7 ...

Note You need to log in before you can comment on or make changes to this bug.