Segfault seen in QDateTime::secsTo on MIPS
I'm seeing a consistent crash in my application on the MIPS platform with Qt 4.7.3. The gdb backtrace shows as follows:
#0 0x2b6fd128 in QDateTime::secsTo () from
#1 0x2b9f6028 in QNetworkAccessCache::updateTimer () from
#2 0x2b9f6cb0 in QNetworkAccessCache::timerEvent () from
#3 0x2b83eb34 in QObject::event () from
#4 0x2b829580 in QCoreApplicationPrivate::notify_helper () from
#5 0x2b829604 in QCoreApplication::notify () from
#6 0x2b828fc4 in QCoreApplication::notifyInternal () from
#7 0x2b860bd8 in QTimerInfoList::activateTimers () from
#8 0x2b861a78 in QEventDispatcherUNIX::processEvents () from
#9 0x2b827d68 in QEventLoop::processEvents () from
#10 0x2b827fe0 in QEventLoop::exec () from
#11 0x2b82ab14 in QCoreApplication::exec () from
#12 0x00aeaf08 in QtMainThread ()
#13 0x2bb3df9c in start_thread () from
#14 0x2bb48200 in __thread_start () from /img/lib/libpthread.so.0
Backtrace stopped: frame did not save the PC
Having looked at the code in QDateTime::secsTo and also QNetworkAccessCache::updateTimer I'm at a loss to explain what could go wrong, apart from maybe a stack smash/exhaustion.
I've also tried running the application using the Qt libraries built with debug, but when I do so it does not crash. I guess this would suggest either it's some kind of race condition which is being perturbed by the debug, or that there is some additional level of protection offered when its compiled in this manner.
What's also worrying is that there doesn't appear to be any of my code showing in the backtrace, just core Qt stuff. From what I can understand of the backtrace I believe that Qt is trying to clean up the HTTP cache objects. The application I am writing does use HTTP but I (thought) that I had disabled the cache on the QNetworkAccessManager...
Has anyone else seen anything like this, or can suggest any ways of debugging the problem?
Have you considered to "file a bug report":http://bugreports.qt.nokia.com/?