[Development] crash when activating timers

[Jocelyn Turcotte]

On Wed, Aug 13, 2014 at 08:37:06AM -0700, Thiago Macieira wrote:
> On Wednesday 13 August 2014 17:07:16 Daniel Teske wrote:
> > On Wednesday 13 Aug 2014 08:05:52 Thiago Macieira wrote:
> > > On Wednesday 13 August 2014 14:32:13 Ziller Eike wrote:
> > > > So my question: Does anyone have any idea how this could possibly
> > > > happen,
> > > > how we could reproduce and/or debug and fix it?
> > > 
> > > I also got a bug report that is similar:
> > > https://bugreports.qt-project.org/browse/QTBUG-40636
> > > 
> > > It's right now in "need info" state. There's nothing I can do with what's
> > > reported there or by your backtrace. Any chance we can convince people to
> > > run Creator inside valgrind?
> > > 
> > > Also, please store the debug files from the build somewhere.
> > 
> > There is a valgrind log attached to the creator bug.
> 
> Hmm
> 
> ==10972== Invalid read of size 8                                                                                                  
> ==10972==    at 0x6528718: QCoreApplication::notifyInternal(QObject*, QEvent*) 
> (in /usr/local/Trolltech/5.2.1/gcc_64/lib/libQt5Core.so.5.2.1)
> ==10972==  Address 0x32c86588 is 8 bytes before a block of size 32 free'd
> ==10972==    at 0x4C2B60C: free (in /usr/lib/valgrind/vgpreload_memcheck-
> amd64-linux.so)
> ==10972==    by 0x1606157F: CPlusPlus::CreateBindings::~CreateBindings() 
> (qalgorithms.h:323)
> 
> That doesn't make sense. CPlusPlus::CreateBindings doesn't use any QObject, so 
> it shouldn't affect the event processing.
> 
> Theories so far:
> 1) bug in QSharedPointer, corrupting the pointer to be freed
> 2) bug in QSharedPointer, keeping the pointer past real freeing (dangling 
> pointer, so it freed something it shouldn't have)
> 3) bug in valgrind, reporting bad info
> 4) bug in malloc
> 5) thread-safety problem

The weird thing is that it's always in QTimerInfoList::activateTimers.
Why is it always only QTimerInfo::obj that gets the dangling pointer?

Unless it's a thread-safety issue, the only patch that I found since Qt
5.x that could get between ~QObject and QTimerInfoList::unregisterTimers
would be : https://codereview.qt-project.org/51304

Though I don't see how this specific patch could be a problem, I was just
trying the shotgun approach in git log. Maybe that can give somebody else
some idea.

Cheers,
Jocelyn