QT4 and GLib

[pdoria]

Hi all,

About Qt4 and GLib ...

I've written a multi-threaded app with PGSQL support and have noticed that, although having the app heavily and thoroughly scrutinized with the help of Valgrind to cover for any possible memory leaks there's still some segfaults.

Things I've noticed:
- the pgsql lib tends to leak...
- no matter how thoroughly you've debugged your app there's always space for the infamous "double free or memory corruption" crash...

I've been launching my app preceded with GSLICE=always_malloc and ever since not a single crash yet...
So I can only assume there's something very wrong with QT and GLib ...

There also a reference about disabling GLib at http://qtnode.net/wiki?title=Glib_Event_Loop

So the point here is:
Should one always resort to the above envvar or simply disable GLib altogether when running multi-threaded apps?

And more importantly:
Could someone share his/hers experience and insight in the matter and possibly some tips?

Thanks in advance,
Pedro Doria Meunier.

[jacek]

What do you use threads for?

[pdoria]

Hey Jacek,

Basically for dispatching devices input through sockets...
One thread per processor (ideally), the others remain queued.
The idea here is having the tcp socket server as responsive as possible.

Regards,
Pedro.

[jacek]

Are these QThreads? Do you create any objects in their constructors?

[pdoria]

Hi Jacek,

Yes, they're QThreads.

I create objects, such as QSqlDatabase in their declarations, otherwise there's nothing created in their constructors.

class myUnit : public QThread
{
Q_OBJECT
// ...
 
protected:
QSqlDatabase myDB;
}
 
myUnit::myUnit ( int socketDescriptor, Server *parent ) : QThread ( parent )
{
// no objects declared here
}

class myUnit : public QThread
{
Q_OBJECT
// ...

protected:
QSqlDatabase myDB;
}

myUnit::myUnit ( int socketDescriptor, Server *parent ) : QThread ( parent )
{
// no objects declared here
}

To copy to clipboard, switch view to plain text mode 

Regards,
Pedro.

[jacek]

Do you make any connections between myUnit instance and some other object?

[pdoria]

hey Jacek,

I appreciate you debugging techniques ... and the answer is no.
However I feel we're missing the point here...

Point:
GLib + QT4 still unreliable?

Personal exp: at least with QApplication it *seems* to be, especially so with QSqlDatabase (PGSQL driver)

Ever since I switched to QCoreApplication (console-only app) - no more every-week segfaults.
Yes.. I know... I should have been using it all along...

Regards,
Pedro.

[jpn]

Where do you assign to myDB? Be careful, because myUnit::myUnit() and myUnit::run() are executed in different thread context.

[wysota]

However I feel we're missing the point here...

Point:
GLib + QT4 still unreliable?

Memory leaks don't cause segfaults. If you experience them, it means there is something wrong with your code.

[pdoria]

Where do you assign to myDB? Be careful, because myUnit::myUnit() and myUnit::run() are executed in different thread context.

Hi jpn

I initialize myDB parameters (and open it) in myUnit::myUnit() .

Thanks,
Pedro.

[jpn]

I initialize myDB parameters (and open it) in myUnit::myUnit()

Presumably you use it in myUnit::run() too, which means you're using the same database object in multiple threads (which is a no no). The constructor of myUnit is executed in that thread which creates the myUnit object (eg. main thread). However, myUnit::run() gets executed in the "new" thread. For more details, read the detailed description of QThread docs.

[pdoria]

Memory leaks don't cause segfaults. If you experience them, it means there is something wrong with your code.

Hi wysota,

Actually I've thoroughly debugged the app using Valgrind. At the end of the (long) run VG reports 0 lost bytes and 0 errors.
The only (possibly lost) leakage comes from QT's fx members and friends. It's neglectable, however (like 160 bytes or so).

I've also been running the app with G_SLICE=always-malloc

Regards,
Pedro.

[pdoria]

Presumably you use it in myUnit::run() too, which means you're using the same database object in multiple threads (which is a no no). The constructor of myUnit is executed in that thread which creates the myUnit object (eg. main thread). However, myUnit::run() gets executed in the "new" thread. For more details, read the detailed description of QThread docs.

Hi jpn

This is my myUnit::run

void myUnit::run()
{
	QString dt = getDateTime();
	this->peerAddress = tcpSocket.peerAddress().toString();
	textcolor ( DIM, CYAN, BLACK );
	printf ("%s: Incoming connection from [%s] - Active clients: %d - DB conn: %s\r\n", qPrintable(dt), qPrintable(peerAddress), server->nbrClients, dbUnique);
	textcolor ( BRIGHT, WHITE, BLACK );
	exec();
	return;
}

void myUnit::run()
{
	QString dt = getDateTime();
	this->peerAddress = tcpSocket.peerAddress().toString();
	textcolor ( DIM, CYAN, BLACK );
	printf ("%s: Incoming connection from [%s] - Active clients: %d - DB conn: %s\r\n", qPrintable(dt), qPrintable(peerAddress), server->nbrClients, dbUnique);
	textcolor ( BRIGHT, WHITE, BLACK );
	exec();
	return;
}

To copy to clipboard, switch view to plain text mode 

As you can see, no access to the DB here...
Are you saying that I should initialize the DB in myUnit::run ?

Thanks,
Pedro.

[jpn]

So where is myDB used elsewhere than the constructor?

[pdoria]

So where is myDB used elsewhere than the constructor?

In members
myUnit::updateUnitRecord
myUnit::updateUnitHistory

and only as an argument

QSqlQuery query(myDB);

QSqlQuery query(myDB);

To copy to clipboard, switch view to plain text mode 

Thanks,
Pedro.

[jpn]

And those are called from?

[pdoria]

And those are called from?

void myUnit::parseFM4Recs ( quint8 nRecs, QDataStream & records )

void myUnit::parseFM4Recs ( quint8 nRecs, QDataStream & records )

To copy to clipboard, switch view to plain text mode 

Thanks,
Pedro.

[jpn]

Ok, remember that we know nothing about all the functions you have in myUnit. I was basically tracking where does the execution come from. A slot? An event handler? It might be easier to track the problem if you provide a little bit more information. Could you perhaps attach myunit.h and myunit.cpp?

[pdoria]

Ok, remember that we know nothing about all the functions you have in myUnit. I was basically tracking where does the execution come from. A slot? An event handler? It might be easier to track the problem if you provide a little bit more information. Could you perhaps attach myunit.h and myunit.cpp?

Hey jpn,

I know that and really appreciate all your care.
As to attaching the code... alas... there are portions of it containing too much proprietary information, which I cannot disclose (protected by NDA).

The app, however, is a simple one:

- A new thread gets fired upon an incoming tcp connection

void Server::incomingConnection ( int socketDescriptor )
{
	nbrClients++;
	myUnit *tunit = new myUnit ( socketDescriptor,this );
	connect ( tunit, SIGNAL ( finished() ), tunit, SLOT ( deleteLater() ) );
	tunit->start();
	return;
}

void Server::incomingConnection ( int socketDescriptor )
{
	nbrClients++;
	myUnit *tunit = new myUnit ( socketDescriptor,this );
	connect ( tunit, SIGNAL ( finished() ), tunit, SLOT ( deleteLater() ) );
	tunit->start();
	return;
}

To copy to clipboard, switch view to plain text mode 

- I link signals and slots like this (in myUnit::myUnit):

// link socket signals to this thread's slots.
connect ( &tcpSocket, SIGNAL ( readyRead() ), this, SLOT ( incomingData() ) );
connect ( &tcpSocket, SIGNAL ( disconnected() ), this, SLOT ( disconnected() ) );

// link socket signals to this thread's slots.
connect ( &tcpSocket, SIGNAL ( readyRead() ), this, SLOT ( incomingData() ) );
connect ( &tcpSocket, SIGNAL ( disconnected() ), this, SLOT ( disconnected() ) );

To copy to clipboard, switch view to plain text mode 

- this is my incomingData() :

void myUnit::incomingData ()
{
	QString dt = getDateTime();
	short zerocount=0;	// number of zero header values to check.
	quint16 dataLength=0;
 
	unsigned int totalBytes = 0;		// quick sanity check...
	totalBytes = tcpSocket.bytesAvailable();
	if ( totalBytes < 4 ) return;		// bogus tx...
 
 
	QDataStream inData ( &tcpSocket );
 
	while ( zerocount < 4 && dataLength==0 )
	{
		inData >> dataLength;
		if ( dataLength==0 ) zerocount++;
	}
 
	// sanity checks...
	// exceed number of tries... bogus tx. return.
	if ( zerocount>3 )
	{
		cout << "WAY TOO MUCH ZEROES!" << endl;
		return;
	}
	// we wont have packets bigger than this. so it's a bogus tx.
	if ( dataLength == 0xFFFF || dataLength==0 )
	{
		cout << "DATA LENGTH MISMATCH! [" << dataLength <<"]" << endl;
		return;
	}
 
	// wait for a maximum of 5 secs for data...
	if (tcpSocket.bytesAvailable() < dataLength)
	{
		tcpSocket.waitForReadyRead ( 5000 );
 
	}
	// if 5 secs *still* not enough get out of here!
	if (tcpSocket.bytesAvailable() < dataLength) {
		this->disconnected();
		return;
	}
 
 
	QByteArray avlData;
	avlData=tcpSocket.readAll();
 
	if ( !gotImei )
	{
		checkImei ( avlData );
	}
	else
	{
		parseData ( avlData );
	}
	return;
}

void myUnit::incomingData ()
{
	QString dt = getDateTime();
	short zerocount=0;	// number of zero header values to check.
	quint16 dataLength=0;

	unsigned int totalBytes = 0;		// quick sanity check...
	totalBytes = tcpSocket.bytesAvailable();
	if ( totalBytes < 4 ) return;		// bogus tx...


	QDataStream inData ( &tcpSocket );

	while ( zerocount < 4 && dataLength==0 )
	{
		inData >> dataLength;
		if ( dataLength==0 ) zerocount++;
	}

	// sanity checks...
	// exceed number of tries... bogus tx. return.
	if ( zerocount>3 )
	{
		cout << "WAY TOO MUCH ZEROES!" << endl;
		return;
	}
	// we wont have packets bigger than this. so it's a bogus tx.
	if ( dataLength == 0xFFFF || dataLength==0 )
	{
		cout << "DATA LENGTH MISMATCH! [" << dataLength <<"]" << endl;
		return;
	}

	// wait for a maximum of 5 secs for data...
	if (tcpSocket.bytesAvailable() < dataLength)
	{
		tcpSocket.waitForReadyRead ( 5000 );
		
	}
	// if 5 secs *still* not enough get out of here!
	if (tcpSocket.bytesAvailable() < dataLength) {
		this->disconnected();
		return;
	}


	QByteArray avlData;
	avlData=tcpSocket.readAll();

	if ( !gotImei )
	{
		checkImei ( avlData );
	}
	else
	{
		parseData ( avlData );
	}
	return;
}

To copy to clipboard, switch view to plain text mode 

- This is my disconnected() :

void myUnit::disconnected()
{
	QString dt = getDateTime();
	server->nbrClients--;
	textcolor ( BRIGHT, YELLOW, BLACK );
	cout << qPrintable(dt) << ": Unit [" << imei.data() << "] disconnected." << " active clients: " << server->nbrClients << endl;
	textcolor ( BRIGHT, WHITE, BLACK );
	this->quit();
	return;
}

void myUnit::disconnected()
{
	QString dt = getDateTime();
	server->nbrClients--;
	textcolor ( BRIGHT, YELLOW, BLACK );
	cout << qPrintable(dt) << ": Unit [" << imei.data() << "] disconnected." << " active clients: " << server->nbrClients << endl;
	textcolor ( BRIGHT, WHITE, BLACK );
	this->quit();
	return;
}

To copy to clipboard, switch view to plain text mode 

- Upon getting data (using QDataStream), the app simply parses the records contained therein in a loop that calls updateUnitRecord (db use here) and updateUnitHistory (another db use here)

- After all is done (unit disconnects) the disconnected() fires up and I take care of closing the DB in

myUnit::~myUnit()
{
	this->myDB.close();
}

myUnit::~myUnit()
{
	this->myDB.close();
}

To copy to clipboard, switch view to plain text mode 

Again, thanks for taking a look at it.

Regards,
Pedro.

[jpn]

Well, I'm sorry to say this but you have somewhat severe threading issues there. I strongly recommend reading Multithreading slides from TT DevDays2007 starting from page 33, about thread affinity.