Never mind. I put it in a debugger and figured out exactly what was happening. XNextEvent() is being called by glib, within the body of QEventDispatcherGlib::processEvents(). XNextEvent() locks the display, then calls xcb_wait_for_event(), which was previously querying the atom on the same display connection and causing the deadlock.
On 11/23/14 12:58 PM, DRC wrote: > I reproduced the deadlock using my build of Qt 5.3.1 on RHEL 6 and > checked in a patch to trunk that addresses the issue, but I'm still > tripping up on exactly how that deadlock is occurring. Qt5 doesn't ever > call XPending(). It uses the XCB event handling functions directly. > > > On 11/20/14 5:28 PM, Nathan Kidd wrote: >> A couple quick and rough notes: >> >> >> 1. Deadlock >> >> I was recently playing with the new XCB support for QT5 and found an >> issue. >> >> The current xcb event handler tries to query an atom on the same >> connection the event was polled from. >> >> Modern libX11 (at least what was on my Ubuntu 14.04 box) implements >> XPending like: >> >> lock connection >> xcb_poll_event_etc. >> vgl event handler tries to query atom which attempts to get the >> connection mutex, deadlocks. >> >> How I repoed: >> - run fluxbox or Unity (probably any WM would do) >> - run the QT5 hellogl example app >> - click on the GL window >> >> I worked around this by querying the relevant atoms at XOpenDisplay time >> (storing them along with the xcb_connection_t* -> Display * hash map). >> >> I don't attach a patch because I'd backported the XCB code to my >> pre-refactor-everything 2.3.4 branch and made the patch there. >> >> If interested I can post it. Otherwise I'll try and get time to make a >> patch for trunk eventually, if I'm not beaten to it. >> >> 2. Dynamic (link) XCB support >> >> I really hated the idea of shipping two versions of the gl faker. (One >> with XCB support, one without), so I implemented XCB support >> dynamically, so it can build and run on e.g. RHEL5 or earlier. (RHEL5 >> can yum install xcb libs, but they aren't installed by default, in my >> observation, and I don't want to break existing installations) >> >> If interested I can post that patch also. Ideally this would wait to >> load the xcb libs till it sees an xcb symbol that needs faking used. >> Unfortunately we need the xcb_connection_t->Display hash map built from >> the beginning so for now I'm unconditionally loading the xcb symbols >> into the app symbol namespace. Hmmm, I suppose that could be worked >> around by building a Display hash list that's used to generate the xcb >> conn hash on first xcb use. >> >> I'm curious if you had any thoughts on this when you implemented. >> >> >> -Nathan >> >> ------------------------------------------------------------------------------ >> >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> with Interactivity, Sharing, Native Excel Exports, App Integration & more >> Get technology previously reserved for billion-dollar corporations, FREE >> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> VirtualGL-Devel mailing list >> VirtualGL-Devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel >> ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
