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
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 ...