On Monday, 21 August 2023 17:52:36 PDT MAX ERENBERG via subsurface wrote:
> VM Region Info: 0x58 is not in any region. Bytes before following region:
> 140737487097768
> 0 QtCore 0x10b61bdaa
> QCoreApplication::notifyInternal2(QObject*, QEvent*) + 138
> 1 QtCore 0x10b7a7a01 QTimerInfoList::activateTimers() + 961
This is a null-pointer dereference activating a timer. The crash is 0x58 past
the null pointer. Comparing to my local build and assuming the structures in
question haven't changed sizes between those two versions, offset 0x58 shows
up here:
QObjectPrivate *d = receiver->d_func();
QThreadData *threadData = d->threadData.loadAcquire();
d->threadData is 0x58 bytes into the QObjectPrivate object, which indicates
that d is the null variable.
This is of course not supposed to happen: this receiver object must be a
dangling pointer. The problem is that the receiver is coming from
QTimerInfoList, so it's not the application's fault. Unless it deleted the
object from another thread, but I don't see any of the threads as being the
likely culprit and if this happened, there should be a warning.
I have a vague memory of a bug report like this, but I can't recall the
details. Searching for QTimerInfoList::activateTimers() doesn't find anything
meaningful. What I do remember is that this function has some convoluted code
to deal with reentrancy in the same thread, which turned up in a recent
refactoring but has unfortunately has gone nowhere. I'm not convinced the
current code works.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel DCAI Cloud Engineering
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
