GUI hangs under linux

SGaist

Hi,

Without code it's crystal ball debugging. Can you show your main.cpp for a start ?

SpanishJohn

Yes. Sorry I realize it was a bit vague

Here is my main:

int main(int argc, char *argv[])
{
config_t config;

#ifndef WIN32

// It is only necessary to call this function if multiple threads might use Xlib concurrently (and this should *not* be the case - I think!)
XInitThreads();

#endif

fprintf(stderr, "\n");

if (config_t::load(argc, argv, &config) != 1)
{
    return -1;
}

Q_INIT_RESOURCE(backhaul_gui);

QApplication app(argc, argv);

QCoreApplication::setOrganizationDomain("AlteraDomain");
QCoreApplication::setOrganizationName("Altera");
QCoreApplication::setApplicationName(APP_NAME);
QCoreApplication::setApplicationVersion("1.0.0");

#ifndef WIN32

app.setStyle("windowsxp");

#endif

backhaul_gui backhaul_gui(config);

backhaul_gui.setMinimumSize(1200, 600);

if (!backhaul_gui.initialise())
{
    QMessageBox::warning(NULL, QObject::tr(APP_NAME),
                         QObject::tr("Unable to initialise. Application terminating."),
                         QMessageBox::Ok);

    return -1;
}

// Get the thread ID of the main thread
g_thread_id = QThread::currentThreadId();

return app.exec();

}

The app opens and has the option to open the 'connect with server' dialog. The dialog requires an IP address and a socket number. I only have to press the mouse button in the edit box and she hangs...

BRgds, SJ

SpanishJohn

@int main(int argc, char *argv[])
{
config_t config;

#ifndef WIN32

XInitThreads();

#endif

fprintf(stderr, "\n");


if (config_t::load(argc, argv, &config) != 1)
{
    return -1;
}

Q_INIT_RESOURCE(backhaul_gui);

QApplication app(argc, argv);

QCoreApplication::setOrganizationDomain("AlteraDomain");
QCoreApplication::setOrganizationName("Altera");
QCoreApplication::setApplicationName(APP_NAME);
QCoreApplication::setApplicationVersion("1.0.0");

#ifndef WIN32

app.setStyle("windowsxp");

#endif

backhaul_gui backhaul_gui(config);

backhaul_gui.setMinimumSize(1200, 600);

if (!backhaul_gui.initialise())
{
    QMessageBox::warning(NULL, QObject::tr(APP_NAME),
                         QObject::tr("Unable to initialise. Application terminating."),
                         QMessageBox::Ok);

    return -1;
}

// Get the thread ID of the main thread
g_thread_id = QThread::currentThreadId();

return app.exec&#40;&#41;;

}@
A better main :)

SJ

SpanishJohn

The application is statically built with Qt 4.7.4

SJ

SpanishJohn

Hi again. More details.

The application always hangs when I go to edit the socket number.

here is the code for the corresponding slot:

@void api_connect_t::edit_socket(QString str)
{
if (str.length() > 0)
{
m_socket = str.toInt();
}
}@

If I remove the

@XInitThreads();@

from main and run this is what I get:

bq. X Error: BadImplementation (server does not implement operation) 17
Major opcode: 20 (X_GetProperty)
Resource id: 0x0
Xlib: sequence lost (0x10000 > 0x99eb) in reply type 0x0!
X Error: 0 0
Major opcode: 0 ()
Resource id: 0x2c484d0
X Error: 0 0
Major opcode: 0 ()
Resource id: 0x132
X Error: 0 0
Major opcode: 0 ()
Resource id: 0x0
X Error: 0 0
Major opcode: 0 ()
Resource id: 0x0
Xlib: sequence lost (0x10000 > 0xa9c3) in reply type 0xe7!
Xlib: sequence lost (0x10000 > 0xa9c3) in reply type 0xe7!
Xlib: sequence lost (0x10000 > 0xaa9b) in reply type 0x0!
X Error: 0 0
Major opcode: 0 ()
Resource id: 0x0
Xlib: sequence lost (0x10000 > 0xaa9b) in reply type 0x1!
Xlib: unexpected async reply (sequence 0x0)!
Killed

Now, if I do this to my socket slot the problem appears to go away:

@void api_connect_t::edit_socket(QString str)
{
return;

if (str.length() > 0)
{
    m_socket = str.toInt();
}

}@

Very strange!!

SJ

SGaist

First, why do you need XInitThreads ?

SpanishJohn

Hi.

I use XInitThreads because it makes a bad situation slightly better. However it does not solve the problem so ideally it should not be there. Without it I get the screen dump shown above almost immediately on opening my simple dialog.

My application does implement a worker thread that is used for the client layer of my app, where as all GUI related work is done by the main thread. I have been very careful to avoid the worker thread directly manipulating widgets - on the rare event that such manipulation is required I use the following method to
ensure the worker does not directly drive the widget.

@QCoreApplication::postEvent(g_gui, new progress_event_t(0));@

As it happens the crash shown above happens when the worker thread is idle (running usleep) .

SJ

SGaist

How does your application behave if you don't have that worker thread active ?

SpanishJohn

Hi. OK so I commented out the code that starts the worker thread and -

she hung immediately :(

which confirms its not the worker thread that's causing the problem. I'm out of ideas.

SJ

SGaist

Then start your application from scratch adding one element after another until it hangs