Description of problem: I am attaching a presentation which was created from an earlier version of openoffice. When editing the second slide for changing the the URL underneath the text the app hangs and also partially hangs KDE. The mouse can be moved but has not effect by clicking it anywhere on the desktop but the desktop backgrounds gets changed as per the time slot they are given. I right click on 2nd slide, 2nd link. Then I click on the +hyperlink icon in the bar above. A window opens to input the web address. I put http://192.168.160.1 as soon as I reach .1, I cannot finish the IP address & the whole damn thing hangs. It has happened thrice. The I killed the process with kill -ABRT processID & got this dump. Version-Release number of selected component: libreoffice-core-3.6.5.2-2.fc18 Additional info: backtrace_rating: 4 cmdline: /usr/lib64/libreoffice/program/soffice.bin --impress /home/vikram/Downloads/attachments/Password-Change.ppt --splash-pipe=6 crash_function: pthread_join executable: /usr/lib64/libreoffice/program/soffice.bin kernel: 3.7.9-201.fc18.x86_64 remote_result: NOTFOUND uid: 1000 var_log_messages: Feb 26 16:52:07 mail2 abrt[22809]: Saved core dump of pid 22216 (/usr/lib64/libreoffice/program/soffice.bin) to /var/spool/abrt/ccpp-2013-02-26-16:52:05-22216 (105861120 bytes) Truncated backtrace: Thread no. 1 (10 frames) #0 pthread_join at pthread_join.c:92 #1 SvtURLBox::ProcessKey(KeyCode const&) at /usr/lib64/libreoffice/program/libsvtlo.so #2 SvtURLBox::PreNotify(NotifyEvent&) at /usr/lib64/libreoffice/program/libsvtlo.so #3 Window::PreNotify(NotifyEvent&) at /usr/lib64/libreoffice/program/libvcllo.so #4 ImplHandleKey(Window*, unsigned short, unsigned short, unsigned short, unsigned short, unsigned char) at /usr/lib64/libreoffice/program/libvcllo.so #5 ImplWindowFrameProc(Window*, SalFrame*, unsigned short, void const*) at /usr/lib64/libreoffice/program/libvcllo.so #6 X11SalFrame::HandleKeyEvent(XKeyEvent*) at /usr/lib64/libreoffice/program/libvclplug_genlo.so #7 X11SalFrame::Dispatch(_XEvent*) at /usr/lib64/libreoffice/program/libvclplug_genlo.so #8 SalKDEDisplay::checkDirectInputEvent(_XEvent*) at /usr/lib64/libreoffice/program/libvclplug_kde4lo.so #9 SalKDEDisplay::Yield() at /usr/lib64/libreoffice/program/libvclplug_kde4lo.so
Created attachment 702834 [details] File: backtrace
Created attachment 702835 [details] File: build_ids
Created attachment 702836 [details] File: cgroup
Created attachment 702837 [details] File: core_backtrace
Created attachment 702838 [details] File: dso_list
Created attachment 702839 [details] File: environ
Created attachment 702840 [details] File: limits
Created attachment 702841 [details] File: maps
Created attachment 702842 [details] File: open_fds
Created attachment 702843 [details] File: proc_pid_status
Created attachment 702844 [details] File: Password-Change.pps
How to reproduce: 1. create a new presentation 2. click into the text body 3. go to menu Insert->Hyperlink 4. write http://192.168.1.1 Anyone wants to have a stab on this deadlock? :-)
Rather than being actually deadlocked I think it's that the remote server doesn't exist or respond so the join has to wait a long time until neon timeouts. Maybe it would be better to not join on each keystroke but instead, once a thread is launched don't attempt to join with it but get it to tell the SvtURLBox via onTerminated that it finished the last request and then SvtURLBox can use its results if it still wants them for that url, or launch a new one at that point with a request for the new url.
taking over
Solved for upstream LibreOffice master now as <http://cgit.freedesktop.org/libreoffice/core/commit/?id=c6dfb3825cad9c8f6f87f4afc8fdbc386919e640> "rhbz#915743: Avoid potentially blocking autocompletion for non file URLs," requested backport to upstream libreoffice-3-6 towards 3.6.6 as <https://gerrit.libreoffice.org/#/c/2670/>, so will get into Fedora 18 when it switches from 3.6.5 to 3.6.6.