Created attachment 18270 [details] jar that crashes X java jars that contain drag and drop and a splash screen completly freeze xorg. I have provided a jar to show this bug.
Created attachment 18271 [details] [review] xorg log
Hello, I also have this problem with DnD in JTree. Actually it does not crash X, it just locks it up or freezes (you can wigle mouse and processes are running fine, but the picture on screen does not change). One can bail out from this lock by killing java process in textual console (usually reached via Control+Alt+F1 combination). I've put up a slightly smaller test case here: http://forums.sun.com/thread.jspa?messageID=10414412 It is a bizarre problem as it manifests only in this combination: 1) Sun Java 6 (Java 5 does not have TransferHandler class, and OpenJDK 6 does not have this problem at all) 2) classes and splash screen are packed in a jar 3) jar manifest uses SplashScreen-Image attribute 4) the java GUI has not been started before in current user session (if one starts the program via "java -classpath myprogram.jar MainClass", then the bug does not appear any more until X is restarted). I observed this problem on Debian GNU/Linux Gnome (and coworker reproduced it on KDE), but it's not producable on Windows. It is likely that the fault is in a Sun Java native library (I have not seen the source for splash image loading part, and I doubt if its available at all at this time), but the status of the problem is very bad as regular users don't know how to reanimate the system. I would appreciate any tips&hints on how to trace this problem and perhaps create a workaround (e.g. that works similarly to "java -classpath" hack).
The problem is reproducable at least with proprietary NVidia as well as open source Intel drivers. So it looks like the problem is not video driver specific.
Below is a stack trace which shows that java thread is stuck in XlibWrapper XSync method and therefore at least Java GUI is frozen. This method (I think) corresponds to XSync function in /usr/lib/libxcb-xlib.so.0.0.0 (libxcb-xlib0 version 1.1-1.1 in Debian sid). Since the state of "freeze on drag" is kept somewhere in X, I can conclude that the fault is somewhere in libxcb-xlib.so.0.0.0. By "state" I mean that if the very same java program is started via "java -classpath archive.jar MainClass" instead of "java -jar archive.jar", then the bug is no longer reproducible no matter how the program started later, and so on until X session is over. 0xb7faa424 ???????? 0xb7c9b029 ???????? 0xb7cfdb19 ???????? 0xb7cf1157 ???????? 0xb4b8d4d6 Java_sun_awt_X11_XlibWrapper_XSync + 0x26 0xb5047f1d * sun.awt.X11.XlibWrapper.XSync(long, int) bci:0 (Interpreted frame) 0xb5040fcd * sun.awt.X11.XToolkit.XSync() bci:7 line:968 (Interpreted frame) 0xb5040fcd * sun.awt.X11.XToolkit.WITH_XERROR_HANDLER(sun.awt.X11.XToolkit$XErrorHandler) bci:8 line:111 (Interpreted frame) 0xb5040fcd * sun.awt.X11.MotifDnDConstants.createMotifWindow() bci:189 line:174 (Interpreted frame) 0xb5040eeb * sun.awt.X11.MotifDnDConstants.getMotifWindow() bci:10 line:210 (Interpreted frame) 0xb5040eeb * sun.awt.X11.MotifDnDConstants.getIndexForTargetList(long[]) bci:40 line:429 (Interpreted frame) 0xb5040ea9 * sun.awt.X11.MotifDnDDragSourceProtocol.initializeDragImpl(int, java.awt.datatransfer.Transferable, java.util.Map, long[]) bci:7 line:58 (Interpreted frame) 0xb5040fcd * sun.awt.X11.XDragSourceProtocol.initializeDrag(int, java.awt.datatransfer.Transferable, java.util.Map, long[]) bci:26 line:79 (Interpreted frame) 0xb5040fcd * sun.awt.X11.XDragSourceContextPeer.startDrag(java.awt.datatransfer.Transferable, long[], java.util.Map) bci:220 line:153 (Interpreted frame) 0xb5040fcd * sun.awt.dnd.SunDragSourceContextPeer.startDrag(java.awt.dnd.DragSourceContext, java.awt.Cursor, java.awt.Image, java.awt.Point) bci:91 line:111 (Interpreted frame) 0xb50414a9 * java.awt.dnd.DragSource.startDrag(java.awt.dnd.DragGestureEvent, java.awt.Cursor, java.awt.Image, java.awt.Point, java.awt.datatransfer.Transferable, java.awt.dnd.DragSourceListener, java.awt.datatransfer.FlavorMap) bci:66 line:306 (Interpreted frame) 0xb5040fcd * java.awt.dnd.DragSource.startDrag(java.awt.dnd.DragGestureEvent, java.awt.Cursor, java.awt.datatransfer.Transferable, java.awt.dnd.DragSourceListener) bci:9 line:403 (Interpreted frame) 0xb5040fcd * java.awt.dnd.DragGestureEvent.startDrag(java.awt.Cursor, java.awt.datatransfer.Transferable, java.awt.dnd.DragSourceListener) bci:8 line:223 (Interpreted frame) 0xb5040fcd * javax.swing.TransferHandler$DragHandler.dragGestureRecognized(java.awt.dnd.DragGestureEvent) bci:43 line:1530 (Interpreted frame)
we are not alone, here is a discussion at Ubuntu forum: http://ubuntuforums.org/showthread.php?t=645600
Based on the stacktrace, I think it is a problem in XCB. In addition, I am not sure how this can be exploited in real life as a security breach, thus I change component to Lib/Xlib (this is the closest thing I could find), with a hope that the right person can have a look... Anyone?
What's the state of this? Does it still happen? If it really hangs inside of XSync, then this should be reassigned to libX11 (Xorg/Library), because XSync is from that library and not xcb.
it has been fixed (at least for me): http://bugs.sun.com/view_bug.do?bug_id=6397447
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.