Perhaps I should have explained earlier, my experience with gdb is of the order of epsilon… 
[quote=“fine”]This may explain your observation. To see whether my suspection has any ground I need to see the call stack that I mentioned above. I guess it should reveal the truth, namely, that your code sticks with the “select” within CMS MySQL query code and the QtRoot is innocent.
Can you check that ?[/quote]
Certainly. 
Anyway, here goes. Did the usual “gdb -p ”. I’ve excluded the “Reading symbols” messages for brevity.
code bt 20
#0 0xb67d15c8 in select () from /lib/tls/libc.so.6
#1 0xb6fef258 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3
#2 0xb7062129 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3
#3 0xb7061f4a in QEventLoop::exec () from /usr/lib/libqt-mt.so.3
#4 0xb704976f in QApplication::exec () from /usr/lib/libqt-mt.so.3
#5 0x0805b851 in main (argc=696, argv=0x0) at main.cpp:95[/code]
Had to do a “continue” so that the program could react again…
code continue
Continuing.
Program received signal SIGTTOU, Stopped (tty output).
[Switching to Thread -1234319680 (LWP 6598)]
0xb67cffc9 in tcsetattr () from /lib/tls/libc.so.6
(gdb)
Continuing.
Program received signal SIGTTOU, Stopped (tty output).
0xb67cffc9 in tcsetattr () from /lib/tls/libc.so.6
[/code]
The program hangs at this point, as usual. In gdb, I got the following backtrace:
code bt 40
#0 0xb67cffc9 in tcsetattr () from /lib/tls/libc.so.6
#1 0xb5ae5132 in Gl_histinit () from /usr/lib/root/libCore.so.5.13
#2 0xb5ae534d in Getlinem () from /usr/lib/root/libCore.so.5.13
#3 0xb4886779 in TQtWidget::InitRint () from /usr/lib/root/libGQt.so.5.13
#4 0xb4887226 in TQtWidget::TQtWidget () from /usr/lib/root/libGQt.so.5.13
#5 0xb48e6ba6 in frmroot::frmroot ()
from /home/jbatista/ktidbexplorer/plugins/.libs/ktidbexplgroot.so
#6 0xb48e89b6 in KTIDBExplorerroot::show ()
from /home/jbatista/ktidbexplorer/plugins/.libs/ktidbexplgroot.so
#7 0x080755f6 in CTableWindow::doubleClicked (this=0x81bc608, row=0, col=3,
button=1, mousePos=@0xbf901538) at ctablewindow.cpp:262
#8 0x080760df in CTableWindow::qt_invoke (this=0x81bc608, _id=51,
_o=0xbf90144c) at moc_ctablewindow.cpp:167
#9 0xb70afcb3 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#10 0xb7475650 in QTable::doubleClicked () from /usr/lib/libqt-mt.so.3
#11 0xb72f9f60 in QTable::contentsMouseDoubleClickEvent ()
from /usr/lib/libqt-mt.so.3
#12 0xb71e3cc1 in QScrollView::viewportMouseDoubleClickEvent ()
from /usr/lib/libqt-mt.so.3
#13 0xb71e5370 in QScrollView::eventFilter () from /usr/lib/libqt-mt.so.3
#14 0xb72f9be8 in QTable::eventFilter () from /usr/lib/libqt-mt.so.3
#15 0xb70af266 in QObject::activate_filters () from /usr/lib/libqt-mt.so.3
#16 0xb70af2e4 in QObject::event () from /usr/lib/libqt-mt.so.3
—Type to continue, or q to quit—
#17 0xb70e6576 in QWidget::event () from /usr/lib/libqt-mt.so.3
#18 0xb7047bd6 in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3
#19 0xb7049d79 in QApplication::notify () from /usr/lib/libqt-mt.so.3
#20 0xb77f8e0e in KApplication::notify () from /usr/lib/libkdecore.so.4
#21 0xb6fdb445 in QApplication::sendSpontaneousEvent ()
from /usr/lib/libqt-mt.so.3
#22 0xb6fda0df in QETWidget::translateMouseEvent () from /usr/lib/libqt-mt.so.3
#23 0xb6fd8660 in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3
#24 0xb6feecb2 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3
#25 0xb7062129 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3
#26 0xb7061f4a in QEventLoop::exec () from /usr/lib/libqt-mt.so.3
#27 0xb704976f in QApplication::exec () from /usr/lib/libqt-mt.so.3
#28 0x0805b851 in main (argc=Cannot access memory at address 0x5402
) at main.cpp:95
(gdb)[/code]
At this point, a “continue” in gdb has no effect on the application, unless I go back to the app’s console and issue a “fg” to bring it back to foreground. Then, a “continue” in gdb resumes the app.
[quote=“fine”]I am wondering if your application hang due the non-correct mask set to the “select” 
function invoked from your CMS MySQL code.
I suspect the mask contains the redundant terminal bit. As result the said select is awaiting the socket event as well as the terminal one. In addition I suspect that “culprit” has the unlimited timeout interval set (which is just zero).
This may explain your observation. To see whether my suspection has any ground I need to see the call stack that I mentioned above. I guess it should reveal the truth, namely, that your code sticks with the “select” within CMS MySQL query code and the QtRoot is innocent.[/quote]
I’ll have to look into those two libraries more carefully (I’ve not delved into them so far)…
