About QUdpSocket. Maybe a bug of qt 4.7.4
-
The test program architecture is like this:
main UI thread do nothing.
Thread Sender use a QUdpSocket send data to local-host port 6001, then sleeps 1ms.
Thread Receiver use a QUdpSocket receive data on local-host's 6001 port, then sleeps 100us.However, I got a error like this:
*** glibc detected *** double free or corruption (fasttop): 0xb5b01bd8 ***sender part code:
@
Sender::Sender(QObject *parent) :
LoopWorkThread(1,parent)
{
s=new QUdpSocket(this);
s->bind(QHostAddress::LocalHost,6000);
}void Sender::foreverLoop()
{
char buf[]="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
s->writeDatagram(buf,sizeof(buf),QHostAddress::LocalHost,6001);msleep(1);
}
@the receiver part code:
@
Receiver::Receiver(QObject *parent) :
LoopWorkThread(2,parent)
{
r=new QUdpSocket(this);
r->bind(QHostAddress::LocalHost,6001);
}void Receiver::foreverLoop()
{
char buf[512];
static int i=0;
if(r->hasPendingDatagrams())
{
r->readDatagram(buf,512);
i++;
if(i==500)
{
qCritical("receive 500 times.");
i=0;
}
}
usleep(100);
}
@ -
[quote author="ChrisW67" date="1343364375"]All very interesting but you left out the useful information like:
-
When do you receive the error?
-
What is being freed twice?
-
Where is it being freed?
-
Where else is it being freed?
-
How does that related to the code you have shown?
-
etc.
[/quote]The time when I receive the error is not unstable, sometimes after printing two "receive 500 times.", sometimes ten.
"What is being freed twice?"
That's just my question. I neither alloc any resource, nor free resource. I just send and receive static data via QUdpSocket in a thread's forever loop.
-
-
bq. “What is being freed twice?” That’s just my question. I neither alloc any resource, nor free resource.
I asked because you presented no evidence that the double-free is in any way related to the snippets of code you have shown. You do make explicit memory allocations at line 4 of both code snippets but there's no way for us to know if those allocations are related to the failure. Both QObjects are given parents at construction, so they will be deleted when the parent is deleted. The code snippets contain no indication of explicit calls to delete or QObject::deleteLater(), or destructor code, so there's no obvious smoking gun here.
Run the code in your debugger and look at the stack backtrace. You should be able to find the line calling, or triggering a call to, delete on an already deleted object and from that the object.
The problem may be made more complicated by the (probably) unnecessary use of threads. Qt memory management will be impeded by your code never returning to the Qt event loop.