Bug #429

MT app hangs on main thread

Added by Massimo Del Fedele about 11 years ago. Updated about 11 years ago.

Status:ApprovedStart date:01/24/2013
Priority:ImmediateDue date:
Assignee:Miroslav Fidler% Done:

100%

Category:CtrlCoreSpent 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

GuiLock.zip (1.39 KB) Massimo Del Fedele, 01/25/2013 01:52 PM

GuiLock_GTK.png - Run with GTK flag (4.11 KB) Massimo Del Fedele, 01/25/2013 01:52 PM

GuiLock_WithoutGTK.png - Run without GTK flag (4.22 KB) Massimo Del Fedele, 01/25/2013 01:52 PM

History

#1 Updated by Massimo Del Fedele about 11 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 about 11 years ago

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 11 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 11 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 11 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 11 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 11 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

Also available in: Atom PDF