Bug 410381

Created attachment 277011 [details]
OO generated bug report

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.

Can you reproduce this ? And if you can, can you share with me from where I
could paste data to reproduce this myself.

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)

Created attachment 279721 [details]
valgrind log for reference

Created attachment 279731 [details]
and the patch to neon to not crash

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.

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.

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

*** Bug 212761 has been marked as a duplicate of this bug. ***

*** Bug 234487 has been marked as a duplicate of this bug. ***

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.

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.

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.

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'

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'

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.

*** Bug 448649 has been marked as a duplicate of this bug. ***

Why wasn't this released back for the Fedora 7 repos too? It exists in
v2.3.0-6.8.fc7 ...