-) component is writer (but this is probably a container issue, not a specific component type, my guess) -) OS version = ubuntu 11.04 when using the upper right bi-directional resize grab, and resizing smaller in both directions, at some point, the WM hangs: -) cursor remains as a resize cursor -) mouse is active and can be moved across screen -) all windows, menus, functions are non-responsive, not just libreoffice windows -) rebooting X11 fails, i.e., keyboard input is ignored -) only solution is a hard reboot of entire machine, or -) remote login to kill X11 manually neither solution desired, of course, since any un-saved work in other windows is lost.
Failed to reproduce on LibreOffice 3.4 340m1(Build:12) for OpenSuse Linux. Tried for both the writer and the calc modules. No problems popped up. I know that everything hangs, so this might be ridiculous to ask, but is there anyway you can get some sort of backtrace from the crash? GDB for example?
*** Bug 39089 has been marked as a duplicate of this bug. ***
not so sure it's a duplicate. agreed, there are problems with resizing, but differing symptoms may, or may not, point to the same problem. (i get no bad X message error, for example.) but that's not for me to decide. i'll keep working this bug until something resolves. your test did not mimic my environment (different OS's, thus different WM's, thus different). since the problem is WM interaction, it's entirely possible that the problem is being contributed to by the WM itself, and so is critical when attempting to duplicate. in any case, i've managed to get a traceback for you on the hang, hopefully it can shed some light: #0 0x001ee416 in __kernel_vsyscall () #1 0x002b0f76 in __poll (fds=0xbfef1568, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0x051e7fe0 in ?? () from /usr/lib/i386-linux-gnu/libxcb.so.1 #3 0x051e85b5 in ?? () from /usr/lib/i386-linux-gnu/libxcb.so.1 #4 0x051e8667 in xcb_writev () from /usr/lib/i386-linux-gnu/libxcb.so.1 #5 0x0473242b in _XSend () from /usr/lib/i386-linux-gnu/libX11.so.6 #6 0x04732a5a in _XReply () from /usr/lib/i386-linux-gnu/libX11.so.6 #7 0x0472fe32 in XTranslateCoordinates () from /usr/lib/i386-linux-gnu/libX11.so.6 #8 0x0151811e in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #9 0x01518920 in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #10 0x015189df in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #11 0x015f8aa8 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0 #12 0x015f9270 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #13 0x015f9524 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0 #14 0x0147c010 in ?? () from /usr/lib/libreoffice/basis3.3/program/libvclplug_gtkli.so #15 0x08d5f157 in X11SalInstance::Yield(bool, bool) () from /usr/lib/libreoffice/basis3.3/program/libvclplug_genli.so #16 0x086728b0 in Application::Yield(bool) () from /usr/lib/libreoffice/program/../basis-link/program/libvclli.so #17 0x0867297c in Application::Execute() () from /usr/lib/libreoffice/program/../basis-link/program/libvclli.so #18 0x005b22ad in ?? () from /usr/lib/libreoffice/program/../basis-link/program/libsofficeapp.so #19 0x086799b2 in ?? () from /usr/lib/libreoffice/program/../basis-link/program/libvclli.so #20 0x08679a55 in SVMain() () from /usr/lib/libreoffice/program/../basis-link/program/libvclli.so #21 0x005dbd6f in soffice_main () from /usr/lib/libreoffice/program/../basis-link/program/libsofficeapp.so #22 0x08048bc1 in main () (gdb)
this is pretty critical, keeps hanging the WM where the only possibility to recover is to hard power-down the whole computer, losing everything. it's confusing to me that there was activity on 9-july asking for a traceback, provided the next day, and then nothing. what's the point of reporting bugs when they go untreated?
We know that the problem is critical to you but the number of developers is limited. I am not able to reproduce this. Also I am not aware about similar bugreports. It is most likely related to your particular setup, e.g. graphics card, driver. Note that these type of bugs are very hard to debug, especially when developers are not able to reproduce it on their machines. Any provided backtrace or interesting symptom might help but it need not help at all. LO-3.3.2 is pretty old. How you tried to update to 3.3.4 or 3.4.2? You might try to uninstall the GNOME integration (libreoffice-gnome) subpackage. You might try to update your system. BTW: Do you use the official LO build or the packages provided by Ubuntu package maintainers? Anyway, I lover the severity because this bugs is not widely reproducible and can't block the release of the product.
i am a programmer myself of 30+ years, so i understand all implications of bug-reproduction and bug-solving. the blocker assignation was an attempt to get someone's attention. i was using the packages provided by ubuntu, the most recent being 3.3.3. i updated to 3.4.2 using the LO download and now the problem's actually worse, now the WM completely crashes (not sure if this is X or the WM itself), but from the previous traceback, it looks like it's X that's crapping out. my setup is not so abnormal: 1) OS = Ubuntu 11.04 2) LO = v3.4.2 3) NVidia graphics card and driver system is bleeding-edge, everything is updated as per Ubuntu's latest availability. libreoffice-gnome is not installed. on a possibly related note, i think the design of the resize functionality could be improved. as it is, re-draw commands (both container widgets and container contents) occur as the re-size is happening, i.e., re-draw commands are interleaved with user-provided re-size actions (user is still resizing). in my experience of GUI design and coding thereof, there is a better solution: 1) do not issue a container re-draw command until the user either: 1.1) briefly stops dragging 1.2) stops dragging altogether, i.e., mouse-click UP i would guarantee that when the re-draw commands are not mixed with the user's re-size requests coming in at the same time, this problem would disappear. to re-iterate how to reproduce: use either upper or lower right resize handles and attempt to make the container smaller in both extents at the same time (diagonal) in a relatively quick manner.
Window resizing is handled by the WM, and if it locks up, it's primarily a WM problem. Please report the problem to developers of the WM.