Crash on QHostAddress::setAddress()... Possibly?

vveloso

Hi,

I'm seeing random crashes in my application when listening for TCP/IP data that is received at random intervals from other devices on the network. These crashes occur after the application has been running for some time, mostly hours.

The application is running under OSX Snow Leopard and I'm using Qt 4.7.2.

The thing is, the sequence of calls in the crash report doesn't seem to make much sense (see below). Does this sequence of calls ring a bell in someone's mind that could provide a clue as to where to search?

Thanks in advance.... Here's the crash log:

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 QtNetwork 0x00ef04c6 QHostAddress::setAddress(QIPv6Address const&) + 166
1 QtNetwork 0x00f1456f QAbstractSocket::disconnectFromHostImplementation() + 223
2 QtNetwork 0x00f161cd QAbstractSocket::qt_metacall(QMetaObject::Call, int, void**) + 429
3 QtCore 0x00261735 QMetaMethod::invoke(QObject*, Qt::ConnectionType, QGenericReturnArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument) const + 1413
4 QtCore 0x0026352f QMetaObject::invokeMethod(QObject*, char const*, Qt::ConnectionType, QGenericReturnArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument) + 1007
5 QtNetwork 0x00f11b19 QAbstractSocket::disconnectFromHost() + 329
6 QtNetwork 0x00f1253b QAbstractSocket::close() + 2011
7 QtNetwork 0x00f0244b QNetworkProxyFactory::systemProxyForQuery(QNetworkProxyQuery const&) + 4283
8 QtGui 0x0044f19c QApplicationPrivate::notify_helper(QObject*, QEvent*) + 188
9 QtGui 0x004557e9 QApplication::notify(QObject*, QEvent*) + 2041
10 QtCore 0x0016c35c QCoreApplication::notifyInternal(QObject*, QEvent*) + 108
11 QtGui 0x00405d1a QDesktopWidget::resizeEvent(QResizeEvent*) + 6698
12 com.apple.CoreFoundation 0x97d42e2e __CFSocketDoCallback + 702
13 com.apple.CoreFoundation 0x97d427b7 __CFSocketPerformV0 + 311
14 com.apple.CoreFoundation 0x97cfc4cb __CFRunLoopDoSources0 + 1563
15 com.apple.CoreFoundation 0x97cf9f8f __CFRunLoopRun + 1071
16 com.apple.CoreFoundation 0x97cf9464 CFRunLoopRunSpecific + 452
17 com.apple.CoreFoundation 0x97cf9291 CFRunLoopRunInMode + 97
18 com.apple.HIToolbox 0x98615e04 RunCurrentEventLoopInMode + 392
19 com.apple.HIToolbox 0x98615bb9 ReceiveNextEventCommon + 354
20 com.apple.HIToolbox 0x98615a3e BlockUntilNextEventMatchingListInMode + 81
21 com.apple.AppKit 0x9677e78d _DPSNextEvent + 847
22 com.apple.AppKit 0x9677dfce -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
23 com.apple.AppKit 0x96740247 -[NSApplication run] + 821
24 QtGui 0x004073c0 QDesktopWidget::resizeEvent(QResizeEvent*) + 12496
25 QtCore 0x0025bbb1 QEventLoop::processEvents(QFlagsQEventLoop::ProcessEventsFlag) + 65
26 QtCore 0x0025befa QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) + 170
27 QtCore 0x0025d576 QCoreApplication::exec() + 182
28 com.Terminal 0x00012921 main + 84
29 com.Terminal 0x00004131 _start + 208
30 com.Terminal 0x00004060 start + 40

Regards,

Veloso

andre

Did you try a memory checker to see if your memory management is sane?

vveloso

Thank you for your insight.

No, I did not... And I was wondering how I'd keep track of what happens to my objects.

Do you have any suggestion as to what (free) memory checker would be the best option to use under OSX?

secretNinja

Hasn't QtCreator 2.2 implemented some support for "Valgrind":http://valgrind.org/ in OS X and Linux. I haven't used it myself but I have heard good reviews of it.

EDIT:
Yes, it has:

bq. New Valgrind/memcheck based memory debugger integration added (Debug->Analyzer) for Linux and Mac.

goetz

From a quick look at the stack trace, I might suspect that the QHostAddress object is already destroyed when something tries to call that method.

Can you create a small, yet complete test program that demonstrates the error, pleas.

BTW: Chances are good that you stumble over a rather simple mistake while preparing the test case ;-)

vveloso

Thank you for your suggestions, guys.

Valgrind didn't appear to run well on my system, but I changed a delete socket; to socket->deleteLater(); whilst processing a signal and apparently the problem has gone away (at least nobody complained yet).