Qt applications crash with segfault error on armel when Qt is built with gcc 4.5 on natty

could this be tested on maverick using the same version of Unity-2d to see if it is related to QT/other libs that changed since 10.10 ?

i am using the maverick packages on a daily basis on my ac100 arm netbook and have no issues.

Can also confirm that this issue doesn't happen with Maverick, tested on Panda and Efika.

Full backtrace attached:

(gdb) bt
#0 0x403d1d44 in operator int (this=0xc9cab8,
    parent=<value optimized out>)
    at ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:85
#1 qt_metatype_id (this=0xc9cab8, parent=<value optimized out>)
    at ../../include/QtGui/private/../../../src/gui/kernel/qgesture.h:56
#2 qt_metatype_id (this=0xc9cab8, parent=<value optimized out>)
    at ../../include/QtCore/../../src/corelib/kernel/qmetatype.h:169
#3 qMetaTypeId<Qt::GestureState> (this=0xc9cab8,
    parent=<value optimized out>)
    at ../../include/QtCore/../../src/corelib/kernel/qmetatype.h:230
#4 qRegisterMetaType<Qt::GestureState> (this=0xc9cab8,
    parent=<value optimized out>)
    at ../../include/QtCore/../../src/corelib/kernel/qmetatype.h:243
#5 QGestureManager::QGestureManager (this=0xc9cab8,
    parent=<value optimized out>) at kernel/qgesturemanager.cpp:76
#6 0x4039608e in QGestureManager::instance ()
    at kernel/qapplication.cpp:5849
#7 0x403c5e82 in QWidget::grabGesture (this=<value optimized out>,
    gesture=Qt::PanGesture, flags=...) at kernel/qwidget.cpp:12079
#8 0x4066ecd0 in QAbstractScrollAreaPrivate::init (this=0xca10f0)
    at widgets/qabstractscrollarea.cpp:299
#9 0x4066ed80 in QAbstractScrollArea::QAbstractScrollArea (
    this=0xbe998548, dd=<value optimized out>,
    parent=<value optimized out>) at widgets/qabstractscrollarea.cpp:493
#10 0x4076785c in QGraphicsView::QGraphicsView (this=0xbe998548,
    dd=<value optimized out>, parent=<value optimized out>)
    at graphicsview/qgraphicsview.cpp:1146
#11 0x409c0e56 in QDeclarativeView::QDeclarativeView (this=0xbe998548,
    parent=0x0) at util/qdeclarativeview.cpp:254
#12 0x0000d2e0 in DashDeclarativeView::DashDeclarativeView (this=
    0xbe998548)
    at /build/buildd/unity-2d-3.2/places/app/dashdeclarativeview.cpp:31
#13 0x0000c362 in main (argc=1, argv=0xbe9987a4)
    at /build/buildd/unity-2d-3.2/places/app/places.cpp:126

After some careful back-porting and kludging, I was able to running natty's unity-2d-launcher against maverick's Qt, which rules out a possible header problem, and isolates the problem to Qt itself instead of inlined code in unity-2d pulled in from Qt.

Reassigning to qt4-x11, this is not a unity-2d bug.

On a hunch that we're looking at a possible compiler regression, I recompiled the maverick Qt 4.7.0 source package against natty (and added the thumb2 patch attached below from the 4.7.1 package) and installed it on a working natty system which still developed a segfault.

Backtrace with 4.7.0 built on natty.

Program received signal SIGSEGV, Segmentation fault.
0x404695ba in operator int (this=0xe0ab10, parent=<value optimized out>)
    at ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:85
85 return _q_value;
(gdb) bt
#0 0x404695ba in operator int (this=0xe0ab10,
    parent=<value optimized out>)
    at ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:85
#1 qt_metatype_id (this=0xe0ab10, parent=<value optimized out>)
    at ../../include/QtGui/private/../../../src/gui/kernel/qgesture.h:56
#2 qt_metatype_id (this=0xe0ab10, parent=<value optimized out>)
    at ../../include/QtCore/../../src/corelib/kernel/qmetatype.h:222
#3 qMetaTypeId<Qt::GestureState> (this=0xe0ab10,
    parent=<value optimized out>)
    at ../../include/QtCore/../../src/corelib/kernel/qmetatype.h:232
#4 qRegisterMetaType<Qt::GestureState> (this=0xe0ab10,
    parent=<value optimized out>)
    at ../../include/QtCore/../../src/corelib/kernel/qmetatype.h:245
#5 QGestureManager::QGestureManager (this=0xe0ab10,
    parent=<value optimized out>) at kernel/qgesturemanager.cpp:76
#6 0x4042e0d2 in QGestureManager::instance ()
    at kernel/qapplication.cpp:5798
#7 0x4045dece in QWidget::grabGesture (this=<value optimized out>,
    gesture=Qt::PanGesture, flags=...) at kernel/qwidget.cpp:12066
#8 0x40705d18 in QAbstractScrollAreaPrivate::init (this=0xe1f4c0)
    at widgets/qabstractscrollarea.cpp:299
#9 0x40705dc8 in QAbstractScrollArea::QAbstractScrollArea (
    this=0xbe8d65b0, dd=<value optimized out>,
    parent=<value optimized out>) at widgets/qabstractscrollarea.cpp:493
#10 0x407ff78c in QGraphicsView::QGraphicsView (this=0xbe8d65b0,
    dd=<value optimized out>, parent=<value optimized out>)
    at graphicsview/qgraphicsview.cpp:1146
#11 0x40a07a8e in QDeclarativeView::QDeclarativeView (this=0xbe8d65b0,
    parent=0x0) at util/qdeclarativeview.cpp:254
#12 0x0000c796 in LauncherView::LauncherView() ()
#13 0x0000c050 in main ()

mcasadevall@risingsun:~$ cat src/qt4-x11-4.7.0/debian/patches/kubuntu_22_thumb2_support.diff
Provide Thumb2 support on armel - See LP Bug #673085 for details
Index: qt-everywhere-opensource-src-4.7.1/src/corelib/arch/qatomic_armv6.h
===================================================================
--- qt-everywhere-opensource-src-4.7.1.orig/src/corelib/arch/qatomic_armv6.h2010-11-06 01:55:18.000000000 +0000
+++ qt-everywhere-opensource-src-4.7.1/src/corelib/arch/qatomic_armv6.h 2010-11-16 17:58:27.831286420 +0000
@@ -144,6 +144,7 @@
     asm volatile("0:\n"
                  "ldrex %[result], [%[_q_value]]\n"
                  "eors %[result], %[result], %[expectedValue]\n"
+ "itt eq\n"
                  "strexeq %[result], %[newValue], [%[_q_value]]\n"
                  "teqeq %[result], #1\n"
                  "beq 0b\n"
@@ -202,6 +203,7 @@
     asm volatile("0:\n"
                ...

Opening new task on gcc-4.5 due to possibility of compiler regression.

Attempting to build natty's Qt on maverick caused a compiler ICE, but since I was building in sbuild, I lost the build environment when it failed. Will try and rerun build at some point so I can file that bug. I was pointed at unit tests for Qt, so I'm going to run the suite and see if we can isolate the specific problem areas.

Definitely not a unity-2d bug :)

This simple app build on pandaboard and current natty crashes in the same way as the launcher (in QReadUnlock())
Crashes 4 runs out of 5 maybe, built with either g++-4.4 or g++4.5

//to build: c++ -I/usr/include/qt4 -I/usr/include/qt4/QtGui crashercpp -lQtGui -o crasher

#include <qapplication.h>

int main(int argc, char *argv[]) {
        QApplication a(argc, argv);
        return 0;
}

Did another round of tests, with maverick build 4.7.0 with the natty IT patch added (posted above) and I got a segfault similar to the one we got earlier, which leads me to believe we have a bad patch.

 Backtrace is identical to current faults. Looks like this is a bad patch to Qt vs. a gcc regression; closing gcc task.

So after active debugging on #linaro, I tore apart some maverick binaries built against stock-maverick qt4-x11, which has implicate-its enabled, and found the compiler generated an 'itttt' instruciton vs 'ittt'.

I'm currently testbuilding a new version of Qt with this modification.

Test code on maverick (no explicate it block):

mcasadevall@risingsun:/srv/chroots/maverick-armel$ cat test.c
#include <stdio.h>

int _q_value = 10;

inline bool testAndSetOrdered(int expectedValue, int newValue)
{
    register int result;
    asm volatile("0:\n"
                 "ldrex %[result], [%[_q_value]]\n"
                 "eors %[result], %[result], %[expectedValue]\n"
                 "strexeq %[result], %[newValue], [%[_q_value]]\n"
                 "teqeq %[result], #1\n"
                 "beq 0b\n"
                 : [result] "=&r" (result),
                   "+m" (_q_value)
                 : [expectedValue] "r" (expectedValue),
                   [newValue] "r" (newValue),
                   [_q_value] "r" (&_q_value)
                 : "cc", "memory");
    return result == 0;
}

int main() {
        return testAndSetOrdered(1, 1);
}

Relevant disassembly from objdump:

00008378 <_Z17testAndSetOrderedii>:
    8378: b490 push {r4, r7}
    837a: b082 sub sp, #8
    837c: af00 add r7, sp, #0
    837e: 6078 str r0, [r7, #4]
    8380: 6039 str r1, [r7, #0]
    8382: f241 0124 movw r1, #4132 ; 0x1024
    8386: f2c0 0101 movt r1, #1
    838a: 6878 ldr r0, [r7, #4]
    838c: f8d7 c000 ldr.w ip, [r7]
    8390: f241 0324 movw r3, #4132 ; 0x1024
    8394: f2c0 0301 movt r3, #1
    8398: f241 0224 movw r2, #4132 ; 0x1024
    839c: f2c0 0201 movt r2, #1
    83a0: e853 4f00 ldrex r4, [r3]
    83a4: 4044 eors r4, r0
    83a6: bf02 ittt eq
    83a8: e843 c400 strexeq r4, ip, [r3]
    83ac: f094 0f01 teqeq r4, #1
    83b0: e7f6 beq.n 83a0 <_Z17testAndSetOrderedii+0x28>
    83b2: 2c00 cmp r4, #0
    83b4: bf14 ite ne
    83b6: 2300 movne r3, #0
    83b8: 2301 moveq r3, #1
    83ba: b2db uxtb r3, r3
    83bc: 4618 mov r0, r3
    83be: f107 0708 add.w r7, r7, #8
    83c2: 46bd mov sp, r7
    83c4: bc90 pop {r4, r7}
    83c6: 4770 bx lr

An alternatve to rebuilding Qt with the patch applied is to binary patch the Qt libs and test:

I copied libQtCore.so and libQtGui.so (the two Qt deps of the simple Qt app which crashes) in the current dir
Then
sed -i 's/\x04\(\xbf.\xe8\x00.\)/\x02\1/' libQtCore.so.4
same on QtGui

export LD_LIBRARY_PATH=.
ldd ./crasherapp (just to confirm it ineed gets the libs from the current dir)

This sed invocation changes itt to ittt in the places where a strexeq follows

The app crashes in the same way so unlikely imho that the patch is the issue, or that indeed the patch is incorrect.

With ittt objdump -d annotates that disas line with
beq.n 1242c8 <_ZN12QApplication11qt_metacastEPKc+0x5c> ; unpredictable <IT:eq>

because it is unclear whether the ittt of the previous teq should affect the conditional bits in the beqeq instruction

Hi Jani,
  Assuming for the moment that sed didn't trip over any other matching chunk of binary, ok, but....

  It's not clear to me why the assembler is warning on that branch; can you disassemble the 4 or 5 instructions leading up to that?
My reading of binutils is that it prints that message for a branch that is not the last element of an IT block, and in the original code quoted the branch should be the last one.

I don't see anything that marks unpredictability due to the shadow of a teq; and I don't see anything in the ARM ARM that says it's unpredictable.

Dave

When disassembling the 10.10 Qt library which has ittt no warning is given, so that was probably a false trail, sorry.

Yeah, I'm agreeing with Jani, that was a false trail. here's the new backtrace with ittt in the patch and unity-2d rebuilt against it:

(gdb) bt
#0 0x404fce2c in operator int (this=0xdf6ce0,
    parent=<value optimized out>)
    at ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:85
#1 qt_metatype_id (this=0xdf6ce0, parent=<value optimized out>)
    at ../../include/QtGui/private/../../../src/gui/kernel/qgesture.h:56
#2 qt_metatype_id (this=0xdf6ce0, parent=<value optimized out>)
    at ../../include/QtCore/../../src/corelib/kernel/qmetatype.h:169
#3 qMetaTypeId<Qt::GestureState> (this=0xdf6ce0,
    parent=<value optimized out>)
    at ../../include/QtCore/../../src/corelib/kernel/qmetatype.h:230
#4 qRegisterMetaType<Qt::GestureState> (this=0xdf6ce0,
    parent=<value optimized out>)
    at ../../include/QtCore/../../src/corelib/kernel/qmetatype.h:243
#5 QGestureManager::QGestureManager (this=0xdf6ce0,
    parent=<value optimized out>) at kernel/qgesturemanager.cpp:76
#6 0x404c108a in QGestureManager::instance ()
    at kernel/qapplication.cpp:5849
#7 0x404f0f0e in QWidget::grabGesture (this=<value optimized out>,
    gesture=Qt::PanGesture, flags=...) at kernel/qwidget.cpp:12079
#8 0x4079aba8 in QAbstractScrollAreaPrivate::init (this=0xddfd20)
    at widgets/qabstractscrollarea.cpp:299
#9 0x4079ac58 in QAbstractScrollArea::QAbstractScrollArea (
    this=0xbeac75ac, dd=<value optimized out>,
    parent=<value optimized out>) at widgets/qabstractscrollarea.cpp:493
#10 0x40893aac in QGraphicsView::QGraphicsView (this=0xbeac75ac,
    dd=<value optimized out>, parent=<value optimized out>)
    at graphicsview/qgraphicsview.cpp:1146
#11 0x40a96e4e in QDeclarativeView::QDeclarativeView (this=0xbeac75ac,
    parent=0x0) at util/qdeclarativeview.cpp:254
#12 0x0000cc76 in LauncherView::LauncherView() ()
#13 0x0000c2dc in main ()

The unity-2d-launcher crash can be reproduced with a locally built Qt, however the app I pasted in comment #9 works.
I built Qt with regular system libs and not in a chroot so maybe there's a slight difference.

As seen for the sample app, if I built Qt with either g++ or gcc 4.4(there are both C++ and C files in the source) the crash is similar, so I don't think this is a compiler regression.

The bug occurs when accessing a volatile int member of a struct via an int() operator defined on that class and which simply returns the value.

QBasicAtomicInt class in this file
http://qt.gitorious.org/qt/qt/blobs/4.7/src/corelib/thread/qbasicatomic.h

The two crashes I have seen both access that field from within the macro Q_DECLARE_METATYPE at line 265 in
http://qt.gitorious.org/qt/qt/blobs/4.7/src/corelib/kernel/qmetatype.h

That macro is used to define GestureState metatype, the one seen in the stacktraces above.

I'll try to check whether https://bugs.launchpad.net/gcc-linaro/+bug/675347 is related.

Changed the description as I can reproduce this with qt4-demos package.

Attempting a full build of Qt 4.7.1 under GCC 4.4 causes a compiler ICE (also reproducable under maverick).

GCC 4.4 bug here: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/713452

Based off the ICE, I'm rebuilding Qt with both 4.4 and 4.5 with precompiled header support disabled as an additional test.

Update: The GCC 4.4 and 4.5 tests finished today, and I tested the resulting debs. As a reminder, this is the current qt4-x11-4.7.1-0ubuntu8 package in archive with precompiled headers disabled, built against the in-archive versions of gcc.

Qt built against Qt 4.5 with no precompiled headers failed with the same backtrace as before. However, built against 4.4, the segfault vanished, and I was able to launch unity-2d-launcher without issue. I reopened the task against gcc-4.5, as it appears we're looking at a toolchain regression in GCC.

This is what I gathered from disassembling so far: and comparing the maverick and natty QtGui libs, looking at the QGestureManager constructor where the crash occurs. It includes a macro which in turn includes a few nested inline functions.

This is the macro included in the constructor, copied from
http://qt.gitorious.org/qt/qt/blobs/4.7/src/corelib/kernel/qmetatype.h

265 #define Q_DECLARE_METATYPE(TYPE) \
266 QT_BEGIN_NAMESPACE \
267 template <> \
268 struct QMetaTypeId< TYPE > \
269 { \
270 enum { Defined = 1 }; \
271 static int qt_metatype_id() \
272 { \
273 static QBasicAtomicInt metatype_id = Q_BASIC_ATOMIC_INITIALIZER(0); \
274 if (!metatype_id) \
275 metatype_id = qRegisterMetaType< TYPE >(#TYPE, \
276 reinterpret_cast< TYPE *>(quintptr(-1))); \
277 return metatype_id; \
278 } \
279 }; \
280 QT_END_NAMESPACE

QBasicAtomicInt has a volatile int _q_value field, which is it's only field, initialized at 0 in line 273.

Line 274 invokes the ! operator in qbasicatomic.h, which is simply { return _q_value == 0;}
Line 277 invokes the int() operator of qbasicatomic.h which is simply { return _q_value;}
Both of the above operators are expanded inline

Here's the disassembly of lines 274-277 in libQtGUI.so.4.7.0 (the working one, built with gcc 4.4)

Check for _q_value 0 using ! operator
 169178: 4e3e ldr r6, [pc, #248] ; (169274 <_ZN18QGestureRecognizerD0Ev+0x348>)
  16917a: 59ab ldr r3, [r5, r6] get _q_value
  16917c: b943 cbnz r3, 169190 <_ZN18QGestureRecognizerD0Ev+0x264>

if zero do the work between the brackets
  16917e: 4b3e ldr r3, [pc, #248] ; (169278 <_ZN18QGestureRecognizerD0Ev+0x34c>)
  169180: 493e ldr r1, [pc, #248] ; (16927c <_ZN18QGestureRecognizerD0Ev+0x350>)
  169182: 4a3f ldr r2, [pc, #252] ; (169280 <_ZN18QGestureRecognizerD0Ev+0x354>)
  169184: 18e8 adds r0, r5, r3
  169186: 1869 adds r1, r5, r1
  169188: 18aa adds r2, r5, r2
  16918a: f7ae ef2a blx 117fe0 <_init+0x2cdc>
  16918e: 51a8 str r0, [r5, r6] set _q_value

return metatype_id - _q_value via the int() operator.

  169190: 2004 movs r0, #4
  169192: 59ab ldr r3, [r5, r6] get _q_value
  169194: f7ae e82c blx 1171f0 <_init+0x1eec>

Notice that _q_value is accessed the same way, at offset r5+r6 in the two ldr and the str inst...

Closed the wrong bug in the changelog, but qt4-x11 0ubuntu9 has a patch to build against gcc 4.4

But shouldn't this bug be kept open to fix qt4-x11 with gcc-4.5? We can't build with gcc-4.4 forever

The bug does not appear with 4.5 if a workaround is used.
At the end of the macro body get the volatile int field explicitely and return that.

--- kernel/qmetatype.h 2011-02-08 14:48:27.000000000 +0200
+++ qmetatype.h 2011-02-08 14:49:14.000000000 +0200
@@ -276,7 +276,8 @@
                 if (!metatype_id) \
                     metatype_id = qRegisterMetaType< TYPE >(#TYPE, \
                                reinterpret_cast< TYPE *>(quintptr(-1))); \
- return metatype_id; \
+ volatile int mid = metatype_id;\
+ return mid; \
             } \
     }; \
     QT_END_NAMESPACE

Hi Jani. Could you clarify some things please?

You mention the QGestureManager constructor, but the disassembly mentions GestureRecognizer. Are you referring to QGestureManager::QGestureManager(QObject *parent) at src/gui/kernel/qgesturemamanger.cpp:73?

You mention Q_DECLARE_METATYPE, but I can't find one near QGestureManager. There is a qRegisterMetaType<Qt::GestureState>() inside QGestureManager::QGestureManager(QObject *parent).

The disassembly given seems wrong, as it's missing any ldrex/strex instructions. I've attached is the disassembly of qt4-x11-4.7.1/src/gui/.obj/release-shared/qgesturemanager.o built with Linaro GCC 4.5-2011.02 for reference.

I'm still building qt4 to see what happens...

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.

Michael, in the disassembly output you have attached the lines starting at 442 are the one comparing metatype_id to 0, then returning metatype_id and that corresponds to the snippets I have pasted earlier.

OK, if I'm disassembling this correctly the output from compiling with -S -dP (thanks Richard) is:

@ 0 "" 2
        .thumb
        ldr r3, .L515+16 @ 152 pic_load_addr_32bit [length = 4]
.LPIC36:
        add r3, pc @ 155 tls_load_dot_plus_four/1 [length = 4]
        ldr r3, [r3]
        cmp r3, #0 @ 157 *thumb2_cbz/1 [length = 8]
        beq .L514
.L496:
        movs r0, #4 @ 420 *thumb2_movsi_shortim [length = 2]
.LPIC39:
        add r3, pc @ 176 tls_load_dot_plus_four/1 [length = 4]
        ldr r3, [r3]
.LEHB27:
        bl operator new(unsigned int)(PLT) @ 178 *call_value_symbol [length = 4]
.LEHE27:
        mov r5, r0 @ 179 *thumb2_movsi_vfp/1 [length = 4]

so it looks like the rtl chunk @176 is the dodgy one?
from the 212r.mach rtl file we have:

(insn:TI 152 147 155 2 ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:80 (set (reg:SI 3 r3 [orig:178 D.147509 ] [178])
        (unspec:SI [
                (mem:SI (const (plus (label_ref 451)
                            (const_int 16 [0x10]))) [0 S4 A32])
            ] 3)) 167 {pic_load_addr_32bit} (expr_list:REG_EQUAL (unspec:SI [
                (const:SI (unspec:SI [
                            (symbol_ref/i:SI ("_ZZN11QMetaTypeIdIN2Qt12GestureStateEE14qt_metatype_idEvE11metatype_id") [flags 0x82] <var_decl 0x410a91e0 metatype_id>)
                            (const:SI (plus:SI (unspec:SI [
                                            (const_int 36 [0x24])
                                        ] 21)
                                    (const_int 4 [0x4])))
                        ] 27))
            ] 3)
        (nil)))

(insn:TI 155 152 157 2 ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:80 (parallel [
            (set (reg:SI 3 r3 [orig:178 D.147509 ] [178])
                (mem/s/v:SI (unspec:SI [
                            (reg:SI 3 r3 [orig:178 D.147509 ] [178])
                            (const_int 4 [0x4])
                            (const_int 36 [0x24])
                        ] 4) [3 metatype_id._q_value+0 S4 A32]))
            (clobber (scratch:SI))
        ]) 666 {tls_load_dot_plus_four} (nil))

(jump_insn:TI 157 155 171 2 ../../include/QtGui/private/../../../src/gui/kernel/qgesture.h:56 (parallel [
            (set (pc)
                (if_then_else (eq (reg:SI 3 r3 [orig:178 D.147509 ] [178])
                        (const_int 0 [0x0]))
                    (label_ref:SI 423)
                    (pc)))
            (clobber (reg:CC 24 cc))
        ]) 721 {*thumb2_cbz} (expr_list:REG_UNUSED (reg:CC 24 cc)
        (expr_list:REG_BR_PROB (const_int 3898 [0xf3a])
            (nil)))
 -> 423)

(code_label 171 157 172 3 496 "" [1 uses])

(note 172 171 174 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(note 174 172 420 3 NOTE_INSN_DELETED)

(insn:TI 420 174 176 3 kernel/qgesturemanager.cpp:85 (parallel [
            (set (reg:SI 0 r0)
                (const_int 4 [0x4]))
            (clobber (reg:CC 24 cc))
        ]) 711 {*thumb2_movsi_shortim} (expr_list:REG_UNUSED (reg:CC 24 cc)
        (nil)))
(insn 176 420 178 3 ../../include/QtCore/../../src/corelib/thread/qbasicatomic....

Thanks to Dave for the excellent debugging work here, pinpointing the RTL instruction that wrongly gets deleted.

The instruction is being deleted by a delete_trivially_dead_insns call during IRA. Surprisingly for such an old function, the bug seems to be in d_t_d_i itself. count_reg_usage counts out how many times each register is used in the entire function, but it tries to ignore uses in self-modifications of the form (set (reg A) (... (reg A) ...)). The problem is that it is ignoring such uses even if the insn has side effects (in this case, an access to volatile memory). insn_live_p rightly returns true for such insns, regardless of register counts, so we end up keeping the self-modification but deleting the instruction that sets its input.

count_reg_usage is set up to predict when insn_live_p would always return true regardless of register usage. It is doing this correctly for instructions that might throw an exception, and for volatile asms. But it is failing to do it for other side-effects that insn_live_p detects. These include volatile MEMs and pre-/post-modifications.

The attached patch seems to fix things (tested on the Linaro sources rather than Ubuntu). I'll run it through a full test cycle.

This is another reason why the CSE code should be using the DF machinery rather than such an ad-hoc approach.

I think I met a similar problem as mentioned in this thread.
What I do:
- use linaro image with toolchain Ubuntu/Linaro 4.5.2-3ubuntu2 on imx51
- apply the IT patch, and build latest mainline qt locally on imx51 with gles2 enabled ("-opengl es2")
- when run qtdemo and some other qt examples, segfault happens (not all qt application crashed, such as hellogl_es2)

But after I replace some qt libraries with debug version (libQtCore, libQtGui, libQtNetwork and libQtScript), the crash disappeared. So I compared the release version and debug version libraries, it seems that there is unpredictable branch in the IT block for release version, but debug version doesn't have that, which is quite strange for me. Take libQtScript for example:

For release version:
root@localhost:/mnt/qt-kde# objdump -d libQtScript.so.4.8.0 |grep unpredictable
   c6cfc: 4770 bxle lr ; unpredictable branch in IT block
   cf608: bf48 it mi ; unpredictable <IT:hi>

For debug version: (with "-debug" configure option when build qt)
root@localhost:/mnt/qt-kde/build/lib# objdump -d libQtScript.so.4.8.0 |grep unpredictable
root@localhost:/mnt/qt-kde/build/lib#

This is a bug fix, can happen after FF, and isn't an a3 release blocker. (Too late for a3 anyway)

Richard's patch has now been committed to Linaro GCC 4.5.

The patch needs to be pushed upstream.

Related: lp:gcc-linaro/4.5,revno=99483

This bug was fixed in the package gcc-4.5 - 4.5.2-5ubuntu1

---------------
gcc-4.5 (4.5.2-5ubuntu1) natty; urgency=low

  * For the natty release, do not pass --as-needed by default to the linker.
    The --as-needed flag will be default again for the o-series.

gcc-4.5 (4.5.2-5) unstable; urgency=low

  * Update to SVN 20110305 (r170696) from the gcc-4_5-branch.
    - Fix PR target/43810, PR fortran/47886, PR tree-optimization/47615,
      PR middle-end/47639, PR tree-optimization/47890, PR libfortran/47830,
      PR tree-optimization/46723, PR target/45261, PR target/45808,
      PR c++/46159, PR c++/47904, PR fortran/47886, PR libstdc++/47433,
      PR target/42240, PR fortran/47878, PR libfortran/47694.
  * Update the Linaro support to the 4.5-2011.03-0 release.
    - Fix LP: #705689, LP: #695302, LP: #710652, LP: #710623, LP: #721021,
      LP: #721021, LP: #709453.

gcc-4.5 (4.5.2-4) unstable; urgency=low

  * Update to SVN 20110222 (r170382) from the gcc-4_5-branch.
    - Fix PR target/43653, PR fortran/47775, PR target/47840,
      PR libfortran/47830.

  [ Matthias Klose ]
  * Don't apply a patch twice.
  * Build libgcc_s with -fno-stack-protector, when not building from the
    Linaro branch.
  * Backport proposed fix for PR tree-optimization/46723 from the trunk.

  [ Steve Langasek ]
  * debian/control.m4: add missing Multi-Arch: same for libgcc4; make sure
    Multi-Arch: same doesn't get set for libmudflap when building an
    Architecture: all cross-compiler package.
  * debian/rules2: use $libdir for libiberty.a.
  * debian/patches/gcc-multiarch-*.diff: make sure we're using the same
    set_multiarch_path definition for all variants.

  [ Sebastian Andrzej Siewior ]
  * PR target/44364
  * Remove -many on powerpcspe (__SPE__)
  * Remove classic FPU opcodes from libgcc if target has no support for them
    (powerpcspe)
 -- Matthias Klose <email address hidden> Sun, 06 Mar 2011 12:22:47 +0100

Soprano needs a rebuild to fix this issue.

Yes, I can reproduce this crash with some kde workspace applications that use the soprano library (kactivitymanagerd, akonadi_nepomuk_contact_feeder, nepomukserver). I did a local rebuild of soprano using the gcc/qt4 versions that ship with natty and the problem was fixed.

Hello Tobin, or anyone else affected,

Accepted soprano into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I can confirm the soprano from natty-proposed works fine. Thanks for taking care of it.

This bug was fixed in the package soprano - 2.5.63+dfsg.1-0ubuntu1.1

---------------
soprano (2.5.63+dfsg.1-0ubuntu1.1) natty-proposed; urgency=low

  * No change rebuild to fix crashes caused by buggy inlined code on armel
    (LP: #705689)
 -- Scott Kitterman <email address hidden> Fri, 01 Jul 2011 09:06:25 -0400