GNOME Bugzilla – Bug 76382
dnd deadlock when stress-testing
Last modified: 2011-02-04 16:09:56 UTC
When I stress-test DND by starting and receiving many DND-operations at a short time it deadlocks, you end up with the mouse grabbed and in DND-mode. One way to trigger it is to use the clist in testgtk. Here I go nuts on the mouse for a while starting as many DND I can while moving the mouse around and after 30s or something I usually triggers the bug. This has nothing to do with clist however bacause I've triggered it in several applications, including a small test program I wrote that is just a drawing area where I do some DND when you press left mouse button. But it seems to be reproducable in any code using DND. So far i've only seen it on programs that are dnd-recievers. When I just start new dnd-operations I have not managed to trigger it. Also, a couple of times it have not only deadlocked gtk but also managed to crash X. I don't know if the X bug is in fact the only one but I believe it's just a bug triggered by another gtk+ bug. In 99% of the cases I can log in to the machine and kill the deadlocked process, the grab is released and everything works again. I'm using rh72, XFree 4.1.0, gtk 2.0.0. Would be nice if someone else could confirm this, maybe using an other version of X.
I was able to trigger this with the clist a couple of times, but not reproducibly, and my drag fixger is getting very tired :-) If you could: a) Produce a test case simpler than the CList b) Figure out under what conditions it happens more exactly (double click twice, touch your elbow, then release, or whatever) That would be _very_ useful.
Created attachment 7399 [details] testcase
I've made a small testcase. I don't know all the ins and outs with dnd in gtk+, but I think it's correct. And it's "easy" to trigger the bug with it. I have not managed to find out exactly what it is that's wrong and how to trigger it. I've noticed that you can start several dnd-operations at the same time which sounds like an error if you ask me. Also you get drag-motion messages after drag-end (or drag-drop) sometimes which sounds strange. That is probably an effect of the above of having several dnd going att the same time. Unfortunatly the signal trace does not always show this. Maybe the stdout/stderr is not flushed so I just don't see this before X freezes. But sometimes when I run the test program I see strange traces of drag signal emissions. You can not trigger it by just pressing the mousebutton, you have to move the mouse around. So there is something with drag-motion, that's my guess and that's where I would start looking for the bug. I got this error under normal usage the first time I saw it. That's why I started to stress test it. This is a bug that can bite newcomers quite hard, since the computer acts like it's dead afterwards.
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
I'm marking this (tentatively, as a dup of 80420) since after fixing 80420, I can't reproduce it any more. Of course, it took me 2 or 3 minutes the first time to reproduce, it, so... *** This bug has been marked as a duplicate of 80420 ***