Bug #429
MT app hangs on main thread
| Status: | Approved | Start date: | 01/24/2013 | |
|---|---|---|---|---|
| Priority: | Immediate | Due date: | ||
| Assignee: | Miroslav Fidler | % Done: | 100% | |
| Category: | CtrlCore | Spent time: | - | |
| Target version: | - |
Description
App hangs inside X11 code, sometimes on loading inside Chamaleon code and sometimes just in the middle
of some operation; main thread backtrace is :
#0 0x00007ffff47c7303 in GIpoll (fds=<optimized out>,
nfds=<optimized out>, timeout=<optimized out>)
at ../sysdeps/unix/sysv/linux/poll.c:87
#1 0x00007ffff1e67972 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2 0x00007ffff1e68e47 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3 0x00007ffff1e6906b in xcb_wait_for_reply ()
from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#4 0x00007ffff6992289 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffff6988159 in XQueryPointer ()
from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x00000000008e9605 in Upp::Ctrl::SyncMousePos ()
at /home/massimo/sources/upp-svn/uppsrc/CtrlCore/X11Proc.cpp:34
#7 0x00000000008e6127 in Upp::Ctrl::EventLoop0 (ctrl=0x7fffffffb270)
at /home/massimo/sources/upp-svn/uppsrc/CtrlCore/X11Wnd.cpp:438
#8 0x0000000000914c95 in Upp::CallbackActionCallArg<void ()(Upp::Ctrl), Upp::Ctrl*, unsigned long>::Execute (this=0x7fffd771d440)
at /home/massimo/sources/upp-svn/uppsrc/Core/Callback1.h:48
#9 0x00000000009be259 in Upp::Callback::Execute (this=0x7fffffffa140)
at /home/massimo/sources/upp-svn/uppsrc/Core/Callback.cpp:7
#10 0x00000000004cff1e in Upp::Callback::operator() (this=0x7fffffffa140)
at /home/massimo/sources/upp-svn/uppsrc/Core/Cbgen.h:32
---Type <return> to continue, or q <return> to quit---
#11 0x00000000008bf31f in Upp::Ctrl::Call (cb=...)
at /home/massimo/sources/upp-svn/uppsrc/CtrlCore/CtrlMt.cpp:71
#12 0x00000000008bf938 in Upp::Ctrl::EventLoop (ctrl=0x7fffffffb270)
at /home/massimo/sources/upp-svn/uppsrc/CtrlCore/CtrlMt.cpp:157
#13 0x00000000008d87d4 in Upp::TopWindow::Run (this=0x7fffffffb270,
appmodal=false)
at /home/massimo/sources/upp-svn/uppsrc/CtrlCore/TopWindow.cpp:327
#14 0x0000000000416bc3 in GuiMainFn ()
at /home/massimo/sources/upp-svn/TimberStruct/TimberStruct/TimberStruct.cpp:976
#15 0x00000000009aa278 in Upp::AppExecute__ (app=0x4162c7 <GuiMainFn_()>)
at /home/massimo/sources/upp-svn/uppsrc/Core/App.cpp:322
#16 0x00000000004162b6 in main (argc=1, argv=0x7fffffffe0c8,
envptr=0x7fffffffe0d8)
at /home/massimo/sources/upp-svn/TimberStruct/TimberStruct/TimberStruct.cpp:829
It hangs always on xcb_wait_for_retry inside X11 code
History
#1 Updated by Massimo Del Fedele over 12 years ago
(gdb) bt
#0 0x00007ffff47c7303 in GIpoll (fds=<optimized out>, nfds=<optimized out>,
timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
#1 0x00007ffff1e67972 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2 0x00007ffff1e68e47 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3 0x00007ffff1e6906b in xcb_wait_for_reply () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#4 0x00007ffff6992289 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffff698dd3d in XSync () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x00000000008e5b22 in Upp::Ctrl::TimerAndPaint ()
at /home/massimo/sources/upp-svn/uppsrc/CtrlCore/X11Wnd.cpp:341
#7 0x00000000008e615f in Upp::Ctrl::EventLoop0 (ctrl=0x7fffffffb230)
at /home/massimo/sources/upp-svn/uppsrc/CtrlCore/X11Wnd.cpp:444
#8 0x0000000000914c95 in Upp::CallbackActionCallArg<void ()(Upp::Ctrl), Upp::Ctrl*, unsigned long>::Execute (this=0x7fffd76fd440)
at /home/massimo/sources/upp-svn/uppsrc/Core/Callback1.h:48
#9 0x00000000009be259 in Upp::Callback::Execute (this=0x7fffffffa100)
at /home/massimo/sources/upp-svn/uppsrc/Core/Callback.cpp:7
#10 0x00000000004cff1e in Upp::Callback::operator() (this=0x7fffffffa100)
at /home/massimo/sources/upp-svn/uppsrc/Core/Cbgen.h:32
#11 0x00000000008bf31f in Upp::Ctrl::Call (cb=...)
at /home/massimo/sources/upp-svn/uppsrc/CtrlCore/CtrlMt.cpp:71
#12 0x00000000008bf938 in Upp::Ctrl::EventLoop (ctrl=0x7fffffffb230)
at /home/massimo/sources/upp-svn/uppsrc/CtrlCore/CtrlMt.cpp:157
#13 0x00000000008d87d4 in Upp::TopWindow::Run (this=0x7fffffffb230, appmodal=false)
at /home/massimo/sources/upp-svn/uppsrc/CtrlCore/TopWindow.cpp:327
#14 0x0000000000416bc3 in GuiMainFn ()
at /home/massimo/sources/upp-svn/TimberStruct/TimberStruct/TimberStruct.cpp:976
#15 0x00000000009aa278 in Upp::AppExecute__ (app=0x4162c7 <GuiMainFn_()>)
at /home/massimo/sources/upp-svn/uppsrc/Core/App.cpp:322
#16 0x00000000004162b6 in main (argc=1, argv=0x7fffffffe088, envptr=0x7fffffffe098)
at /home/massimo/sources/upp-svn/TimberStruct/TimberStruct/TimberStruct.cpp:829
Hangs on same x11 code.
#2 Updated by Massimo Del Fedele over 12 years ago
- File GuiLock.zip added
- File GuiLock_GTK.png added
- File GuiLock_WithoutGTK.png added
A small testcase with output results; attached is the complete package, here just a couple of notes :
#include <CtrlLib/CtrlLib.h>
using namespace Upp;
#define LAYOUTFILE <GuiLock/GuiLock.lay>
#include <CtrlCore/lay.h>
class GuiLockTest : public WithGuiLockLayout<TopWindow>
{
void threadCb(void);
int i;
Thread th;
public:
typedef GuiLockTest CLASSNAME;
GuiLockTest();
};
void GuiLockTest::threadCb(void)
{
GuiLock __;
docEdit.Set(docEdit.Get() + Format("\n%d", i++));
}
GuiLockTest::GuiLockTest()
{
CtrlLayout(*this, "Window title");
i = 0;
for(int j = 0; j < 2; j++)
th.Start(THISBACK(threadCb));
}
GUI_APP_MAIN
{
GuiLockTest().Run();
}
The app should run 2 threads which fill the DocEdit control with sequential numbers; the GuiLock there should do the serialization too.
Result without GTK flag is ok, it shows numbers 0 and 1; with GTK flag it shows just number 0 and then the second thread is waiting in GuiLock to be freed.
The same if I increase the number of threads; it runs correctly all of them but last one, probably because then the main thread (after the constructor) locks
gui and don't free it.
Result with GTK flag is the same as my app; without GTK flag my app crashes, here is all ok, but I suppose that's because the example il too simple.
#3 Updated by Massimo Del Fedele about 12 years ago
Adding a
Sleep(10)
at thread function start makes the bug more evident; ALL threads are then stopped at GuiLock in GTK mode probably
because main thread don't release the lock.
Without GTK the app seems work ok.
#4 Updated by Massimo Del Fedele about 12 years ago
Another backtrace, now crashing (sometimes hangs, sometimes crash, always in X11 code) :
Starting program: /home/massimo/sources/upp-svn/out/TimberStruct/GCC.Debug.Debug_Full.Gui.Mt.Shared/TimberStruct
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffde3ff700 (LWP 26633)]
[New Thread 0x7fffdcecb700 (LWP 26634)]
[New Thread 0x7fffd723a700 (LWP 26638)]
[New Thread 0x7fffd61b6700 (LWP 26639)]
[Thread 0x7fffd61b6700 (LWP 26639) exited]
[New Thread 0x7fffd51e8700 (LWP 26643)]
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
TimberStruct: ../../src/xcb_io.c:273: poll_for_event: asserzione "!xcb_xlib_threads_sequence_lost" non riuscita.
Program received signal SIGABRT, Aborted.
Really weird....
#5 Updated by Massimo Del Fedele about 12 years ago
As suggested by last crash report, I added
XInitThreads();
in an INITBLOCK (so it's called before any gui stuff...) just to test and... now it's all ok, no crash anymore.
Shouldn't be there ? I didn't find it in Upp code.
#6 Updated by Miroslav Fidler about 12 years ago
- Status changed from New to Ready for QA
- Assignee changed from Miroslav Fidler to Massimo Del Fedele
I believe that both modes should be now fixed.
#7 Updated by Massimo Del Fedele about 12 years ago
- Status changed from Ready for QA to Approved
- Assignee changed from Massimo Del Fedele to Miroslav Fidler
- % Done changed from 0 to 100