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
