I have a small application that manages to reproduce that crash quite easily on ubuntu 10.04, but only when running under valgrind. But that application itself behaves quite badly as it calls xlib from different threads using the same "Display*" struct for all threads, so I'm not sure if that might be of any use for tracking this issue. However I think it calls XInitThreads() on startup, so that should allow it to share the same display for all threads, isn't it ?
hellgrind outputs loads of stuff like:
==2950== Possible data race during write of size 4 at 0x44bd06c by thread #1
==2950== at 0x4084764: ??? (in /usr/lib/libX11.so.6.3.0)
==2950== by 0x4069352: XGetWindowProperty (in /usr/lib/libX11.so.6.3.0)
==2950== by 0x81E0F46: juce::LinuxComponentPeer::isMinimised() const (juce_linux_Windowing.cpp:902)
==2950== by 0x8164890: juce::ComponentPeer::handleMovedOrResized() (juce_amalgamated.cpp:71167)
==2950== by 0x81E296B: juce::LinuxComponentPeer::handleWindowMessage(_XEvent*) (juce_linux_Windowing.cpp:1579)
==2950== by 0x81E549F: juce::juce_windowMessageReceive(_XEvent*) (juce_linux_Windowing.cpp:2617)
==2950== by 0x81DE71F: juce::juce_dispatchNextXEvent() (juce_linux_Messaging.cpp:384)
==2950== by 0x81DE899: juce::juce_dispatchNextMessageOnSystemQueue(bool) (juce_linux_Messaging.cpp:431)
==2950== by 0x8137170: juce::MessageManager::dispatchNextMessage(bool, bool*) (juce_amalgamated.cpp:34719)
==2950== by 0x8137204: juce::MessageManager::runDispatchLoop() (juce_amalgamated.cpp:34763)
==2950== by 0x81348A1: juce::JUCEApplication::main(juce::StringArray&, juce::JUCEApplication*) (juce_amalgamated.cpp:14770)
==2950== by 0x8134A7B: juce::JUCEApplication::main(int, char**, juce::JUCEApplication*) (juce_amalgamated.cpp:14859)
==2950== This conflicts with a previous read of size 4 by thread #6
==2950== at 0x4082F0C: _XSetPrivSyncFunction (in /usr/lib/libX11.so.6.3.0)
==2950== by 0x408BBEF: _XAllocID (in /usr/lib/libX11.so.6.3.0)
==2950== by 0x40611A7: XCreatePixmap (in /usr/lib/libX11.so.6.3.0)
==2950== by 0x50BF8ED: XcursorImageLoadCursor (in /usr/lib/libXcursor.so.1.0.2)
==2950== by 0x50C0765: XcursorImagesLoadCursors (in /usr/lib/libXcursor.so.1.0.2)
==2950== by 0x50C0886: XcursorImagesLoadCursor (in /usr/lib/libXcursor.so.1.0.2)
==2950== by 0x50C4187: XcursorTryShapeCursor (in /usr/lib/libXcursor.so.1.0.2)
==2950== by 0x4060C5C: XCreateGlyphCursor (in /usr/lib/libX11.so.6.3.0)
I have a small application that manages to reproduce that crash quite easily on ubuntu 10.04, but only when running under valgrind. But that application itself behaves quite badly as it calls xlib from different threads using the same "Display*" struct for all threads, so I'm not sure if that might be of any use for tracking this issue. However I think it calls XInitThreads() on startup, so that should allow it to share the same display for all threads, isn't it ?
hellgrind outputs loads of stuff like:
==2950== Possible data race during write of size 4 at 0x44bd06c by thread #1 libX11. so.6.3. 0) libX11. so.6.3. 0) onentPeer: :isMinimised( ) const (juce_linux_ Windowing. cpp:902) Peer::handleMov edOrResized( ) (juce_amalgamat ed.cpp: 71167) onentPeer: :handleWindowMe ssage(_ XEvent* ) (juce_linux_ Windowing. cpp:1579) windowMessageRe ceive(_ XEvent* ) (juce_linux_ Windowing. cpp:2617) dispatchNextXEv ent() (juce_linux_ Messaging. cpp:384) dispatchNextMes sageOnSystemQue ue(bool) (juce_linux_ Messaging. cpp:431) nager:: dispatchNextMes sage(bool, bool*) (juce_amalgamat ed.cpp: 34719) nager:: runDispatchLoop () (juce_amalgamat ed.cpp: 34763) cation: :main(juce: :StringArray& , juce::JUCEAppli cation* ) (juce_amalgamat ed.cpp: 14770) cation: :main(int, char**, juce::JUCEAppli cation* ) (juce_amalgamat ed.cpp: 14859) nction (in /usr/lib/ libX11. so.6.3. 0) libX11. so.6.3. 0) libX11. so.6.3. 0) dCursor (in /usr/lib/ libXcursor. so.1.0. 2) adCursors (in /usr/lib/ libXcursor. so.1.0. 2) adCursor (in /usr/lib/ libXcursor. so.1.0. 2) Cursor (in /usr/lib/ libXcursor. so.1.0. 2) libX11. so.6.3. 0)
==2950== at 0x4084764: ??? (in /usr/lib/
==2950== by 0x4069352: XGetWindowProperty (in /usr/lib/
==2950== by 0x81E0F46: juce::LinuxComp
==2950== by 0x8164890: juce::Component
==2950== by 0x81E296B: juce::LinuxComp
==2950== by 0x81E549F: juce::juce_
==2950== by 0x81DE71F: juce::juce_
==2950== by 0x81DE899: juce::juce_
==2950== by 0x8137170: juce::MessageMa
==2950== by 0x8137204: juce::MessageMa
==2950== by 0x81348A1: juce::JUCEAppli
==2950== by 0x8134A7B: juce::JUCEAppli
==2950== This conflicts with a previous read of size 4 by thread #6
==2950== at 0x4082F0C: _XSetPrivSyncFu
==2950== by 0x408BBEF: _XAllocID (in /usr/lib/
==2950== by 0x40611A7: XCreatePixmap (in /usr/lib/
==2950== by 0x50BF8ED: XcursorImageLoa
==2950== by 0x50C0765: XcursorImagesLo
==2950== by 0x50C0886: XcursorImagesLo
==2950== by 0x50C4187: XcursorTryShape
==2950== by 0x4060C5C: XCreateGlyphCursor (in /usr/lib/
before the failed assertion.