Comment 27 for bug 705689

Michael, yes I am referring to that constuctor; Only QGestureRecognizer is mentioned because the constructor's symbol is not in the binary apparently.
I could only locate the exact spot of the crash in by putting asm volatile("mov r5,r5") and similar eyecatchers, as most functions there are inlined with no symbol info.

The Q_DECLARE_METATYPE macro is defined in this file, and included in several places in gui/ and script/
http://qt.gitorious.org/qt/qt/blobs/4.7/src/corelib/kernel/qmetatype.h

The class with the volatile int field and associated int() operator is here
http://qt.gitorious.org/qt/qt/blobs/4.7/src/corelib/thread/qbasicatomic.h

Initially I saw two crashes, one with a simple hello world type app, mentioned earlier in this bugreport and the unity-2d-launcher crash. Both occurred in this macro expansion but called from different places (qpaintbuffer and qgesturemanager respectively)

My disassembly was only partial, the immediate context of the crash, but it had those 6-7 ldrex/strex pairs as well - those seemed to be atomic sets, called by constructor initialization and parent constructor initialization. Once I saw that a mov r5,r5 palced at the beginning of the constructor body falls after these ldrex/strex pairs I did not concern myself with them (except an easy way of searching for the code block in the .o file)

Once Qt is configured you can get much faster turnaround by going to src/gui and
make .obj/release-shared/qgesturemanager.o (or similar)
then modify that cpp file or any other header included like metatype in corelib/kernel and objdump the resulting o

There's only need to build src/gui if you want to reproduce the crash later, as even if the crash is in a macro from libcore, it being inlined make it end up in libgui.