Description of problem: Starting oowriter from an gnome-terminal today does nothing, not even the splash screen shows up. ps(1) shows (3424 is swriter.bin): $ ps -l 3424 F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 0 S 500 3424 3205 0 80 0 - 21936 wait pts/0 0:00 /bin/sh /usr/lib Version-Release number of selected component (if applicable): openoffice.org-writer-3.0.1-13.2.fc11.x86_64 How reproducible: Always, also oocalc, ooimpress Steps to Reproduce: 1. oowriter 2. 3. Actual results: Hang Expected results: Splash screen, etc Additional info: This is definitely not (directly) OOo's fault, the current version was installed 20081212, and was last used successfully before yesterday's (20081218) updates.
starts for me at the moment, but I'm probably a day behind in rawhide updates and it'll kick in tomorrow :-)
Created attachment 327473 [details] The list of updates (installs, erases, updates) from the last two days One of the updates from yesterday (20081218) is most probably at fault, but I can't see which one...
Created attachment 327487 [details] Output from "strace -f oowriter" The last lines (FUTEX etc) repeat over and over if you let them, here I killed oowriter with ctrl-C.
The changed package which makes a difference seems to be libX11.so.6 Loaded symbols for /usr/lib64/openoffice.org3/program/../basis-link/program/sax.uno.so Reading symbols from /usr/lib64/openoffice.org/basis3.0/program/localebe1.uno.so...done. Loaded symbols for /usr/lib64/openoffice.org3/program/../basis-link/program/localebe1.uno.so Reading symbols from /usr/lib64/openoffice.org/basis3.0/program/libspllx.so...done. Loaded symbols for /usr/lib64/openoffice.org3/program/../basis-link/program/libspllx.so 0x000000303d00db14 in __lll_lock_wait () from /lib64/libpthread.so.0 Missing separate debuginfos, use: debuginfo-install openoffice.org-writer-3.0.1-13.3.fc11.x86_64 (gdb) bt (gdb) bt #0 0x000000303d00db14 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000303d00b850 in pthread_cond_broadcast@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #2 0x00007f0862a1a327 in ?? () from /usr/lib64/libX11.so.6 #3 0x00007f0862a1a69d in ?? () from /usr/lib64/libX11.so.6 #4 0x00007f0862a1af59 in _XReadEvents () from /usr/lib64/libX11.so.6 #5 0x00007f08629f9864 in XIfEvent () from /usr/lib64/libX11.so.6 #6 0x00007f0863a62a94 in gdk_x11_get_server_time () from /usr/lib64/libgdk-x11-2.0.so.0 #7 0x00007f085b6efacd in ?? () from /usr/lib64/openoffice.org/basis3.0/program/libvclplug_gtklx.so
Sigh, gdk_x11_get_server_time always hangs for OOo now. I'll revert back to GDK_CURRENT_TIME for now and take the hit of having metacity mess with our toolbars rather than not starting at all.
Fabulous, export SAL_SYNCHRONIZE=1 to run in synchronous mode works.
Created attachment 327666 [details] hack for gdk to force synchronous on during XChangeProperty of gdk_x11_get_server_time
Why would we do that ?
*shrug*, I'm just the messenger that its hanging in gdk and that it doesn't look like that it should be my bug to work on. FWIW I also see that acroread is hanging in the same place, i.e. #0 0x01b82a54 in _start () from /lib/libpthread.so.0 #1 0x01b80645 in pthread_cond_broadcast@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x03796c2d in ?? () from /usr/lib/libX11.so.6 #3 0x037b0fc5 in ?? () from /usr/lib/libX11.so.6 #4 0x037b12ee in ?? () from /usr/lib/libX11.so.6 #5 0x037b1c0b in _XReadEvents () from /usr/lib/libX11.so.6 #6 0x0379019b in XIfEvent () from /usr/lib/libX11.so.6 #7 0x05139ac7 in gdk_x11_get_server_time () from /usr/lib/libgdk-x11-2.0.so.0 #8 0x05926643 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #9 0x059269f4 in gtk_clipboard_request_contents () from /usr/lib/libgtk-x11-2.0.so.0 #10 0x05927789 in gtk_clipboard_request_text () from /usr/lib/libgtk-x11-2.0.so.0 #11 0x0837ec47 in ?? () #12 0xf4e9f288 in ?? () #13 0x0837ebce in ?? () #14 0x00000000 in ?? ()
I don't see how this can suddenly start blocking. We certainly didn't change the way it works. Is there some other thread stealing X events ? It could also be an X11 / xcb problem.
Assuming this is rawhide, would be worth trying this with F10 libX11 and libxcb. There was a moderately large change to how it handles the socket handoff between the two that could easily affect this.
FWIW gtk/gdk didn't change, while X11/xcb did, i.e. the same OOo/acroread versions worked before the last rawhide X11/xcb. acroread is probably the better test-case as I've muddied the waters by forcing through an otherwise usable OOo.
*** Bug 478358 has been marked as a duplicate of this bug. ***
*** Bug 477555 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > FWIW gtk/gdk didn't change, while X11/xcb did, i.e. the same OOo/acroread > versions worked before the last rawhide X11/xcb. acroread is probably the > better test-case as I've muddied the waters by forcing through an otherwise > usable OOo. It is certainly not "otherwise usable" here... Is there anything else I can do to help fix this mess?
Well at least is *starts*, which is slightly more usable than not starting :-)
I must admire your humor.
Got a better one: Today I tried to edit a .docx file. It opened fine, and I can edit it. Trying to save gives the (by now) bog-standard hang.
*** Bug 480085 has been marked as a duplicate of this bug. ***
Throwing this over to the X side for now.
*** Bug 481711 has been marked as a duplicate of this bug. ***
perhaps http://lists.freedesktop.org/archives/xorg/2009-January/043133.html
That's the one, does the trick
built as libX11-1.1.99.2-3.fc11
*** Bug 483858 has been marked as a duplicate of this bug. ***