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



  • 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



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



  • 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?



  • 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.



  • 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 ;-)



  • 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).


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.