Hello Dominik, I'm not sure I agree with your conclusion. In my opinion an application, no matter how broken, should never be able to compromise the window manager like this - just like it never should be able to freeze the Kernel itself. The window manager must be able to deal with freaked-out applications. And, in this case, Fvwm seems to be the only one that doesn't. To make sure, I just tried the Awesome WM, and didn't experience any problems with Eclipse at all. I know Eclipse is (and always was) buggy as hell, but Fvwm is badly in need of some fix nevertheless.
Regards, Tobias On Tue, Aug 12, 2014, at 21:45, Dominik Vogt wrote: > On Sun, Aug 10, 2014 at 10:42:12AM +0200, Tobias Landes wrote: > > For some time I thought it was a bug in Eclipse, but now I > > noticed that using no window manager at all makes the problem > > disappear, > > Of course this proves nothing. Applications can behave totally > differently under different window managers or plain X. > > > Just download any recent version of Eclipse, extract, and start > > it. Then try dragging a view tab from one place to another inside > > Eclipse. Fvwm will hang completely, one CPU core running at 100%; > > I have to switch to a console and kill the Java VM to make things > > work again. > > I have a better test that proves that there is a bad bug in > Eclipse: > > * With the recent Java VM and Eclipse downloaded today and the > current fvwm from CVS (all Linux, i586, 32 bit, Debian stable). > > * Use an almost empty config file for fvwm with just this line: > > destroyfunc ewmhactivatewindowfunc > > * Start fvwm on some X server. It may be useful to start a > separate X server (e.g. :1) for this and run fvwm with something > like > > $ fvwm -d :1 -f <configfile> > > * Attach a debugger to fvwm (from a console): > > $ gdb fvwm <fvwm's pid> > ctrl-c > (gdb) continue > > * Then start eclipse and drag as you described. Fvwm will > freeze. > > * Switch to a console and run top: Eclipse is using 100% cpu. > > * Now go back to the gdb session and Interrupt fvwm. You'll see > that fvwm is waiting for events in its main loop: > > (gdb) bt > #0 0xb70b8458 in select () from /lib/i386-linux-gnu/libc.so.6 > #1 0x080eb57c in fvwmSelect (nfds=1024, > readfds=readfds@entry=0xbfffce40, writefds=writefds@entry=0xbfffcec0, > exceptfds=exceptfds@entry=0x0, timeout=0x0) at fvwmsignal.c:216 > #2 0x08072d25 in My_XNextEvent (dpy=0x8a7d7d8, > event=event@entry=0xbfffcf70) at events.c:4359 > #3 0x08073302 in HandleEvents () at events.c:4220 > #4 0x08050f85 in main (argc=<optimized out>, argv=0xbfffd654) at > fvwm.c:2591 > > Enter > > (gdb) next > > to let fvwm wait for the next event. You'll see that no event > ever arrives. > > Conclusion: Eclipse has grabbed the X server or keyboard or mouse > and frozen all other X clients (including fvwm). But instead of > doing something, it just burns cpu and never releases the grab. I > think the whole situation might be related to Eclipse grabbing the > X server and then trying to communicate with the window manager > under the grab. Of course this won't work because the window > manager does not receive any events during the grab. > > Sample stack trace from Eclipse: > > -- snip -- > #0 0xb77381d4 in __pthread_mutex_unlock_usercnt () > from /lib/i386-linux-gnu/libpthread.so.0 > #1 0xb6b82980 in g_mutex_unlock () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #2 0xb6b428df in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #3 0xb6b42b51 in g_main_context_iteration () > from /lib/i386-linux-gnu/libglib-2.0.so.0 > #4 0x823b7962 in > Java_org_eclipse_swt_internal_gtk_OS__1g_1main_1context_1iteration () > from > /home/luthien/tmp/eclipse/configuration/org.eclipse.osgi/211/0/.cp/libswt-pi3-gtk-4427.so > #5 0xb3d7ac66 in ?? () > #6 0xb3ddde9c in ?? () > #7 0xb3932207 in ?? () > #8 0xb3932207 in ?? () > #9 0xb3932207 in ?? () > #10 0xb393247b in ?? () > #11 0xb3932207 in ?? () > #12 0xb3932207 in ?? () > #13 0xb3d31564 in ?? () > #14 0xb3932207 in ?? () > #15 0xb3932207 in ?? () > #16 0xb3d1f4b0 in ?? () > #17 0xb3932207 in ?? () > #18 0xb393234f in ?? () > #19 0xb3d9ae64 in ?? () > #20 0xb5c2d025 in JavaCalls::call_helper(JavaValue*, methodHandle*, > JavaCallArguments*, Thread*) () > from /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so > #21 0xb5d820b9 in os::os_exception_wrapper(void (*)(JavaValue*, > methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, > JavaCallArguments*, Thread*) () from > /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so > #22 0xb5c2bc9f in JavaCalls::call(JavaValue*, methodHandle, > JavaCallArguments*, Thread*) () from > /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so > #23 0xb5c69715 in jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, > JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) () > from /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so > #24 0xb5c6ffac in jni_CallIntMethodV () > from /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so > #25 0x82f2d2cd in callback () > from > /home/luthien/tmp/eclipse/configuration/org.eclipse.osgi/211/0/.cp/libswt-gtk-4427.so > #26 0x82a510d2 in ?? () > #27 0xb71c99ac in ?? () from /usr/lib/i386-linux-gnu/libgdk-3.so.0 > #28 0xb71f2ad8 in ?? () from /usr/lib/i386-linux-gnu/libgdk-3.so.0 > #29 0xb6b426d3 in g_main_context_dispatch () > from /lib/i386-linux-gnu/libglib-2.0.so.0 > #30 0xb6b42a70 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #31 0xb6b42b51 in g_main_context_iteration () > from /lib/i386-linux-gnu/libglib-2.0.so.0 > #32 0x823b7962 in > Java_org_eclipse_swt_internal_gtk_OS__1g_1main_1context_1iteration () > from > /home/luthien/tmp/eclipse/configuration/org.eclipse.osgi/211/0/.cp/libswt-pi3-gtk-4427.so > #33 0xb3d7ac66 in ?? () > #34 0xb3db89c8 in ?? () > #35 0xb3932207 in ?? () > #36 0xb3932785 in ?? () > #37 0xb3d1f4b0 in ?? () > #38 0xb3932785 in ?? () > #39 0xb3932207 in ?? () > #40 0xb3932918 in ?? () > #41 0xb3932207 in ?? () > #42 0xb3932785 in ?? () > #43 0xb3932207 in ?? () > #44 0xb393234f in ?? () > #45 0xb393234f in ?? () > #46 0xb3932918 in ?? () > #47 0xb3932918 in ?? () > #48 0xb393239a in ?? () > #49 0xb393239a in ?? () > #50 0xb393239a in ?? () > #51 0xb392f3d9 in ?? () > #52 0xb5c2d025 in JavaCalls::call_helper(JavaValue*, methodHandle*, > JavaCallArguments*, Thread*) () > from /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so > #53 0xb5d820b9 in os::os_exception_wrapper(void (*)(JavaValue*, > methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, > JavaCallArguments*, Thread*) () from > /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so > #54 0xb5c2bc9f in JavaCalls::call(JavaValue*, methodHandle, > JavaCallArguments*, Thread*) () from > /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so > #55 0xb5dc7fbe in Reflection::invoke(instanceKlassHandle, methodHandle, > Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, Thread*) () > from /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so > #56 0xb5dc8a7a in Reflection::invoke_method(oopDesc*, Handle, objArrayHandle, > Thread*) () from /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so > #57 0xb5cb04d9 in JVM_InvokeMethod () > from /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so > #58 0xb59641c2 in Java_sun_reflect_NativeMethodAccessorImpl_invoke0 () > from /home/luthien/jre1.7.0_67/lib/i386/libjava.so > #59 0xb3939bf3 in ?? () > #60 0xb393239a in ?? () > #61 0xb393239a in ?? () > ---Type <return> to continue, or q <return> to quit--- > #62 0xb3932918 in ?? () > #63 0xb393239a in ?? () > #64 0xb3932207 in ?? () > #65 0xb3932207 in ?? () > #66 0xb392f3d9 in ?? () > #67 0xb5c2d025 in JavaCalls::call_helper(JavaValue*, methodHandle*, > JavaCallArguments*, Thread*) () > from /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so > #68 0xb5d820b9 in os::os_exception_wrapper(void (*)(JavaValue*, > methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, > JavaCallArguments*, Thread*) () from > /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so > #69 0xb5c2bc9f in JavaCalls::call(JavaValue*, methodHandle, > JavaCallArguments*, Thread*) () from > /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so > #70 0xb5c69715 in jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, > JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) () > from /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so > #71 0xb5c7015c in jni_CallIntMethod () > from /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so > #72 0xb72403f9 in startJavaJNI ( > libPath=0x87141f8 > "/home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so", > vmArgs=0x877da20, progArgs=0x8780348, > jarFile=0x8712c98 > "/home/luthien/tmp/eclipse//plugins/org.eclipse.equinox.launcher_1.3.0.v20140415-2008.jar") > at ../eclipseJNI.c:386 > ---Type <return> to continue, or q <return> to quit--- > #73 0xb7241898 in startJavaVM ( > libPath=0x87141f8 > "/home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so", > vmArgs=0x877da20, progArgs=0x8780348, > jarFile=0x8712c98 > "/home/luthien/tmp/eclipse//plugins/org.eclipse.equinox.launcher_1.3.0.v20140415-2008.jar") > at ../eclipseNix.c:174 > #74 0xb723b1f6 in _run (argc=3, argv=0x87140f0, vmArgs=0x87144e0) > at ../eclipse.c:629 > #75 0xb723ac03 in run (argc=3, argv=0x87140f0, vmArgs=0x8712ed0) > at ../eclipse.c:465 > #76 0x08049214 in main (argc=16, argv=0x87140f0) at ../eclipseMain.c:214 > -- snip -- > > Notes: > > 1) Prior to freaking out completely, Eclipse does an extreme > number of redraws. Window contents are flashing all the time. > 2) If the drag action ends quicky, Eclipse does not freak out. > > I think you should report this to the Eclipse people. There is > definitely a very bad bug in Eclipse, and while that is not fixed > it's very difficult to tell whether fvwm is doing something wrong > too. Chances are that Eclipse cannot handle the stream of events > that fvwm causes in response to Eclipse's requests. If the > Eclipse people need help with reproducing this, they can contact > me via the mailing list. > > Ciao > > Dominik ^_^ ^_^ > > -- > > Dominik Vogt >
