I just downloaded SceneBuilder-15.0.0-RC1.msi from gluon website, installed it. When starting, nothing happens, no message whatsoever. When starting as administrator, basically the same, but I discovered in the installation folder a file is created named hs_err_pidxxxxx.log, containing the following
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000000000000, pid=16520, tid=3752
#
# JRE version: (15.0.1+9) (build )
# Java VM: OpenJDK 64-Bit Server VM (15.0.1+9, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C 0x0000000000000000
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
#
--------------- S U M M A R Y ------------
Command Line: --add-opens=javafx.fxml/javafx.fxml=ALL-UNNAMED --module-path=C:\Program Files\SceneBuilder\app\mods com.oracle.javafx.scenebuilder.app.SceneBuilderApp
Host: Intel(R) Core(TM) i7-4790K CPU # 4.00GHz, 8 cores, 15G, Windows 10 , 64 bit Build 19041 (10.0.19041.662)
Time: Sun Jan 10 15:57:12 2021 Mitteleuropäische Zeit elapsed time: 0.051742 seconds (0d 0h 0m 0s)
--------------- T H R E A D ---------------
Current thread (0x000001fee94fb5f0): JavaThread "Unknown thread" [_thread_in_vm, id=3752, stack(0x000000f58ac00000,0x000000f58ad00000)]
Stack: [0x000000f58ac00000,0x000000f58ad00000], sp=0x000000f58acfea98, free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), data execution prevention violation at address 0x0000000000000000
Registers:
RAX=0x000001fee9c0fe08, RBX=0x000001fe86f28090, RCX=0x000001fee9c0fe08, RDX=0x000000000000034b
RSP=0x000000f58acfea98, RBP=0x000000f58acfebb0, RSI=0x000001fee9c0fdeb, RDI=0x000001fee9c0fdeb
R8 =0x000001fe86f28090, R9 =0x00000000000005ce, R10=0x000000f58acfeb10, R11=0x45f1c7cf10132c67
R12=0x00000000000005ce, R13=0x000001fee94fd810, R14=0x000001fee94fdb50, R15=0x000001fee94fdb50
RIP=0x0000000000000000, EFLAGS=0x0000000000010246
Top of Stack: (sp=0x000000f58acfea98)
0x000000f58acfea98: 00007fff44431833 000001fe86f28090
0x000000f58acfeaa8: 00007fff44431877 00000000000005ce
0x000000f58acfeab8: 0000000000000000 000000f58acfeaf8
0x000000f58acfeac8: 0000000000000000 000001fee9c0fdeb
0x000000f58acfead8: 00007fff44431495 000001fe86f28090
0x000000f58acfeae8: 000000f58acfebb0 000001fee9c0fdeb
0x000000f58acfeaf8: 0000000000000000 000000f58acfebb0
0x000000f58acfeb08: 00007fff0471f74a 000000f5cafefafa
0x000000f58acfeb18: 000000000000034b 00000000000005ce
0x000000f58acfeb28: ffffffff00000007 0000000086183d01
0x000000f58acfeb38: 00005831f7a63934 00000000000005ce
0x000000f58acfeb48: 000001fee94fdb50 000001fee94fbac0
0x000000f58acfeb58: 000001fee738cef0 0000000000525f03
0x000000f58acfeb68: 0000000000000368 000001fee9c0fdeb
0x000000f58acfeb78: 00007fff44431ed7 000001fe86717450
0x000000f58acfeb88: 0000000000000016 0000000000000001
Instructions: (pc=0x0000000000000000)
0xffffffffffffff00:
--------------- P R O C E S S ---------------
Threads class SMR info:
_java_thread_list=0x00007fff04affa50, length=0, elements={
}
Java Threads: ( => current thread )
Other Threads:
0x000001fee954ee10 GCTaskThread "GC Thread#0" [stack: 0x000000f58ad00000,0x000000f58ae00000] [id=1668]
0x000001fee9560520 ConcurrentGCThread "G1 Main Marker" [stack: 0x000000f58ae00000,0x000000f58af00000] [id=1408]
0x000001fee9561020 ConcurrentGCThread "G1 Conc#0" [stack: 0x000000f58af00000,0x000000f58b000000] [id=684]
0x000001fe865a40e0 ConcurrentGCThread "G1 Refine#0" [stack: 0x000000f58b000000,0x000000f58b100000] [id=10684]
0x000001fe865a4bf0 ConcurrentGCThread "G1 Young RemSet Sampling" [stack: 0x000000f58b100000,0x000000f58b200000] [id=572]
=>0x000001fee94fb5f0 (exited) JavaThread "Unknown thread" [_thread_in_vm, id=3752, stack(0x000000f58ac00000,0x000000f58ad00000)]
Threads with active compile tasks:
VM state: not at safepoint (not fully initialized)
VM Mutex/Monitor currently owned by a thread: None
Heap address: 0x0000000700e00000, size: 4082 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
CDS disabled.
Compressed class space mapped at: 0x0000000800000000-0x0000000840000000, size: 1073741824
Narrow klass base: 0x0000000800000000, Narrow klass shift: 0, Narrow klass range: 0x40000000
GC Precious Log:
CPUs: 8 total, 8 available
Memory: 16322M
Large Page Support: Disabled
NUMA Support: Disabled
Compressed Oops: Enabled (Zero based)
Heap Region Size: 2M
Heap Min Capacity: 8M
Heap Initial Capacity: 256M
Heap Max Capacity: 4082M
Pre-touch: Disabled
Parallel Workers: 8
Concurrent Workers: 2
Concurrent Refinement Workers: 8
Periodic GC: Disabled
Heap:
garbage-first heap total 262144K, used 0K [0x0000000700e00000, 0x0000000800000000)
region size 2048K, 1 young (2048K), 0 survivors (0K)
Metaspace used 4K, capacity 4480K, committed 4480K, reserved 1056768K
class space used 3K, capacity 384K, committed 384K, reserved 1048576K
'''
(skipping rest of log file)
any ideas?
I have a hung python (CPython 3.6) process. From a gdb backtrace, a forked process waits indefinitely for a mutex held by a LWP/Thread which no longer exists. After some debugging, I can see that after join() returns on the blocking Thread, its LWP is still active, with its stack unwinding with a backtrace like this:
#0 dl_open_worker (a=a#entry=0x7fffefb0eb90) at dl-open.c:515
#1 0x00007ffff7b4b2df in __GI__dl_catch_exception (exception=0x7fffefb0eb70, operate=0x7ffff7de9dc0 <dl_open_worker>, args=0x7fffefb0eb90) at dl-error-skeleton.c:196
#2 0x00007ffff7de97ca in _dl_open (file=0x7ffff77d9bc0 "libgcc_s.so.1", mode=-2147483646, caller_dlopen=0x7ffff77d7deb <pthread_cancel_init+43>, nsid=<optimised out>, argc=9, argv=<optimised out>, env=0x7fffffffe318) at dl-open.c:605
#3 0x00007ffff7b4a3ad in do_dlopen (ptr=ptr#entry=0x7fffefb0edc0) at dl-libc.c:96
#4 0x00007ffff7b4b2df in __GI__dl_catch_exception (exception=exception#entry=0x7fffefb0ed60, operate=operate#entry=0x7ffff7b4a370 <do_dlopen>, args=args#entry=0x7fffefb0edc0) at dl-error-skeleton.c:196
#5 0x00007ffff7b4b36f in __GI__dl_catch_error (objname=objname#entry=0x7fffefb0edb0, errstring=errstring#entry=0x7fffefb0edb8, mallocedp=mallocedp#entry=0x7fffefb0edaf, operate=operate#entry=0x7ffff7b4a370 <do_dlopen>, args=args#entry=0x7fffefb0edc0) at dl-error-skeleton.c:215
#6 0x00007ffff7b4a4d9 in dlerror_run (args=0x7fffefb0edc0, operate=0x7ffff7b4a370 <do_dlopen>) at dl-libc.c:46
#7 __GI___libc_dlopen_mode (name=name#entry=0x7ffff77d9bc0 "libgcc_s.so.1", mode=mode#entry=-2147483646) at dl-libc.c:195
#8 0x00007ffff77d7deb in pthread_cancel_init () at ../sysdeps/nptl/unwind-forcedunwind.c:52
#9 0x00007ffff77d7fd4 in _Unwind_ForcedUnwind (exc=0x7fffefb0fd70, stop=stop#entry=0x7ffff77d5d80 <unwind_stop>, stop_argument=0x7fffefb0ef10) at ../sysdeps/nptl/unwind-forcedunwind.c:126
#10 0x00007ffff77d5f10 in __GI___pthread_unwind (buf=<optimised out>) at unwind.c:121
#11 0x00007ffff77cdae5 in __do_cancel () at pthreadP.h:297
#12 __pthread_exit (value=<optimised out>) at pthread_exit.c:28
#13 0x00007ffff7b14504 in __pthread_exit (retval=<optimised out>) at forward.c:173
#14 0x00000000006383c5 in PyThread_exit_thread () at ../Python/thread_pthread.h:300
#15 0x00000000005e5f0f in t_bootstrap () at ../Modules/_threadmodule.c:1030
#16 0x0000000000638084 in pythread_wrapper (arg=<optimised out>) at ../Python/thread_pthread.h:205
#17 0x00007ffff77cc6db in start_thread (arg=0x7fffefb0f700) at pthread_create.c:463
#18 0x00007ffff7b0588f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Should this LWP be there at all or should it terminate before join()? If the latter, am I looking at a CPython bug?
From inspection of the source code, it seems that this is expected. From https://github.com/python/cpython/blob/master/Modules/_threadmodule.c#L1028, when a thread has finished its work, these two calls are made:
PyThreadState_DeleteCurrent();
PyThread_exit_thread();
The first ends up releasing the lock which allows join() to return; the second results in the LWP unwinding its stack.
Debugging a trivial test python script which starts a Thread, join()s it and then sends a signal to itself (which provides a convenient breakpoint which gdb can understand) shows a similar backtrace to the one in the original post, which further supports this conclusion.
My Qt application is locking up with high cpu usage after running correctly for a few hours, and I'm trying to figure out why. This is on an embedded linux system.
The first thing I did was attach gdb and look at a stack backtrace. It shows the lockup occurring in ptmalloc_lock_all(), which is called by fork(). The application uses system() to play a video, and periodically uses QProcess to check whether a USB drive is mounted.
I don't intentionally use multiple threads in my application, but gdb shows 4 threads at the point where the freeze occurs. I've included the backtrace for all 4 threads:
(gdb) thread apply all backtrace
Thread 4 (Thread 995):
#0 0x4282dc50 in select () from /opt/filesys/fs/lib/libc.so.6
#1 0x4246a768 in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timeval const*) ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
#2 0x4246f2a8 in QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timeval*) ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
#3 0x4246f6e0 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
#4 0x42435898 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
#5 0x42435bac in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
#6 0x42317834 in QThread::exec() ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
#7 0x4231aaf8 in ?? ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
Cannot access memory at address 0x0
#8 0x4231aaf8 in ?? ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
Cannot access memory at address 0x0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 3 (Thread 973):
#0 0x425c64bc in pthread_cond_wait##GLIBC_2.4 () from /opt/filesys/fs/lib/libpthread.so.0
#1 0x413f8688 in ?? ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtWebKit.so.4
Cannot access memory at address 0x0
#2 0x413f8688 in ?? ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtWebKit.so.4
Cannot access memory at address 0x0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 2 (Thread 949):
#0 0x4282dc50 in select () from /opt/filesys/fs/lib/libc.so.6
#1 0x4240c16c in ?? ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
Cannot access memory at address 0x3054
#2 0x4240c16c in ?? ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
Cannot access memory at address 0x3054
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 1 (Thread 720):
#0 0x427e1194 in ptmalloc_lock_all () from /opt/filesys/fs/lib/libc.so.6
#1 0x428041c4 in fork () from /opt/filesys/fs/lib/libc.so.6
#2 0x4240fce8 in ?? ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
#3 0x4240fce8 in ?? ()
from /opt/filesys/fs/opt/filesys/fs/opt/qt/lib/libQtCore.so.4
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
I'm not very experienced with multithreaded programming, but from reading online it sounds like it can be dangerous to use fork() in a multithreaded application. I'm not sure what to do as an alternative though.
Any input would be greatly appreciated!
Marlon
I'm struggling with this problem for more than a week now, and still can't find a solution...
I'm trying to cross-compile Qt 4.7 embedded open-source version for an ARM device. The build process itself completes without problems, but the generated binaries seem to contain instructions that the processor does not understand.
Build host is Debian 5 (Etch) on i386 (running on a virtual PC)
The device is a Trimble Nomad handheld with an ARM processor (see full cpuinfo and kernel configuration)
I use the original build toolchain that was made for the device and that worked fine to date (even could build Gnash successfully) - see compiler settings and version
I'm using a custom qmake.conf based on linux-arm-gnueabi-g++ and adapted to use the correct toolchain - see source code here
I had a partial improvement by adding -msoft-float -D__GCC_FLOAT_NOT_NEEDED to the compiler flags but I still get "Illegal instruction" errors in some situations (but at least this was a big improvement)
The binaries themselves basically work, but in certain situations the program crashes with the "Illegal instruction" error. I believe this happens during certain floating point operations while doing graphics stuff.
Adding -mcpu=xscale, -march=armv4, -O0, -march=armv4, -mtune=arm920t (not all at the same time) did not help in any way.
Building Qt with the --debug flag appears to resolve all problems but adding the -O2 flag reintroduces them. Strangely the -O0 setting without --debug does not help.
The compilete configure and make output can be seen here. There are lots of alignment warnings but they are said to be false warnings of the compiler.
there must have been some change in Qt 4.7.2 because earlier versions (4.7.1, 4.7.0) do run fine.
configure settings:
./configure \
-embedded arm \
-xplatform qws/linux-arm-angstrom-gnueabi-g++ \
-debug \
-no-largefile \
-no-multimedia \
-no-audio-backend \
-no-phonon \
-no-phonon-backend \
-webkit \
-javascript-jit \
-no-xshape \
-no-xvideo \
-no-xsync \
-no-xinerama \
-no-xcursor \
-no-xfixes \
-no-xrandr \
-no-xrender \
-no-xinput \
-no-xkb \
-no-opengl \
-nomake docs \
-nomake examples \
-nomake tools \
-nomake demos \
-nomake translations \
-opensource \
-qt-mouse-tslib \
-qt-libjpeg \
-qt-gif
strace before the crash:
$ LD_LIBRARY_PATH=. QT_QWS_FONTDIR=$PWD/fonts QT_PLUGIN_PATH=$PWD/plugins QWS_MOUSE_PROTO=tslib:/dev/input/touchscreen0 strace ./digitalclock -qws test.htm
...
lseek(15, 0, SEEK_END) = 16998
write(15, "\t\n\f\0\367\t", 6) = 6
write(15, "\0\0+\234\325\343\306{\3\0\0\0\0J\370\377\351\301\336\377"..., 120) = 120
lseek(15, 0, SEEK_END) = 17124
write(15, "\10\10\10\0\371\10", 6) = 6
write(15, "\0\6j\251\260\201\27\0\2\276\377\351\334\377\346\32K\377"..., 64) = 64
lseek(15, 0, SEEK_END) = 17194
write(15, "\7\10\10\0\371\7", 6) = 6
write(15, "\0\4c\245\263\224 \0\1\271\377\367\315\356P\0I\377\364"..., 64) = 64
lseek(15, 0, SEEK_END) = 17264
write(15, "\10\n\10\1\366\10", 6) = 6
write(15, "\37 \3\0\0\0\0\0\374\377\34\0\0\0\0\0\374\377\34\0\0\0"..., 80) = 80
fcntl64(15, F_SETLK, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
lseek(15, 0, SEEK_END) = 17350
mremap(0x415f5000, 16552, 17350, MREMAP_MAYMOVE) = 0x415f5000
--- SIGILL (Illegal instruction) # 0 (0) ---
rt_sigaction(SIGILL, {SIG_DFL}, {0x401b7d34, [ILL], SA_RESTART|0x4000000}, 8) = 0
socket_subcall(0x1f8004, 0, 0x100, 0, 0, 0x18844, 0x18840, 0x12c) = 0
ioctl(12, KDSKBMODE, 0x2) = 0
ioctl(12, SNDCTL_TMR_START or TCSETS, {B38400 -opost -isig -icanon -echo ...}) = 0
close(12) = 0
ioctl(10, KDSETMODE, 0x1) = 0
write(10, "\33[9;15]\33[?33h\33[?25h\33[?0c\0", 25) = 25
close(10) = 0
statfs64(umovestr: Input/output error
0x6d4f, 27983, {???}) = 0
sigreturn() = ? (mask now [ILL ABRT BUS FPE USR1 SEGV USR2 PIPE STKFLT CHLD CONT STOP TTOU URG XCPU VTALRM PROF WINCH IO PWR RTMIN])
--- SIGILL (Illegal instruction) # 0 (0) ---
+++ killed by SIGILL +++
Process 27983 detached
gdb backtrace of the crash (I'm missing debug symbols since compiling with debug information resolves the problem):
(gdb) run -qws
Starting program: /home/.qt-test2/digitalclock -qws
Program received signal SIGILL, Illegal instruction.
0x4130268c in __sigsetjmp () from /lib/libc.so.6
(gdb) bt
#0 0x4130268c in __sigsetjmp () from /lib/libc.so.6
#1 0x4046ee5c in ?? () from ./libQtGui.so.4
(gdb)
Note the device comes with Qtopia 4.3 preinstalled and the vendor can't explain the problem with my build either.
Update
With help from Igor Skochinsky I could find the exact assembler instruction that is causing the SIGILL. For some reason the instruction works fine for 47 times before causing the error. See gdb output below (note I'm not familiar with ARM assembler at all ):
$ LD_LIBRARY_PATH=. QT_QWS_FONTDIR=$PWD/fonts QT_PLUGIN_PATH=$PWD/plugins QWS_MOUSE_PROTO=tslib:/dev/input/touchscreen0 gdb ./digitalclock
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "arm-angstrom-linux-gnueabi"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) start -qws
Breakpoint 1 at 0xaa58: file main.cpp, line 47.
Starting program: /home/.qt-test2/digitalclock -qws
[Thread debugging using libthread_db enabled]
[New Thread 1073870720 (LWP 2799)]
[Switching to Thread 1073870720 (LWP 2799)]
main (argc=2, argv=0xbea17d04) at main.cpp:47
47 main.cpp: No such file or directory.
in main.cpp
(gdb) display/i $pc
1: x/i $pc 0xaa58 <main+24>: sub r3, r11, #28 ; 0x1c
(gdb) display/x $r2
2: /x $r2 = 0xbea17d10
(gdb) display/x $f2
3: /x $f2 = 0x0
(gdb) b *0x41302684
Breakpoint 2 at 0x41302684
(gdb) continue
Continuing.
---> no problem here:
Breakpoint 2, 0x41302684 in __sigsetjmp () from /lib/libc.so.6
3: /x $f2 = 0x0
2: /x $r2 = 0x293
1: x/i $pc 0x41302684 <__sigsetjmp+52>: beq 0x413026a0 <Lno_iwmmxt>
(gdb) si
0x41302688 in __sigsetjmp () from /lib/libc.so.6
3: /x $f2 = 0x0
2: /x $r2 = 0x293
1: x/i $pc 0x41302688 <__sigsetjmp+56>: stfp f2, [r12], #8
(gdb) si
0x4130268c in __sigsetjmp () from /lib/libc.so.6
3: /x $f2 = 0x0
2: /x $r2 = 0x293
1: x/i $pc 0x4130268c <__sigsetjmp+60>: stfp f3, [r12], #8
(gdb) si
0x41302690 in __sigsetjmp () from /lib/libc.so.6
3: /x $f2 = 0x0
2: /x $r2 = 0x293
1: x/i $pc 0x41302690 <__sigsetjmp+64>: stfp f4, [r12], #8
(gdb) continue
Continuing.
Breakpoint 2, 0x41302684 in __sigsetjmp () from /lib/libc.so.6
3: /x $f2 = 0x0
2: /x $r2 = 0x293
1: x/i $pc 0x41302684 <__sigsetjmp+52>: beq 0x413026a0 <Lno_iwmmxt>
(gdb) continue 46
Will ignore next 45 crossings of breakpoint 2. Continuing.
---> __sigsetjmp still working fine, but then:
Breakpoint 2, 0x41302684 in __sigsetjmp () from /lib/libc.so.6
3: /x $f2 = 0x0
2: /x $r2 = 0x293
1: x/i $pc 0x41302684 <__sigsetjmp+52>: beq 0x413026a0 <Lno_iwmmxt>
(gdb) si
0x41302688 in __sigsetjmp () from /lib/libc.so.6
3: /x $f2 = 0x0
2: /x $r2 = 0x293
1: x/i $pc 0x41302688 <__sigsetjmp+56>: stfp f2, [r12], #8
(gdb) si
Program received signal SIGILL, Illegal instruction.
0x4130268c in __sigsetjmp () from /lib/libc.so.6
3: /x $f2 = 0x0
2: /x $r2 = 0x293
1: x/i $pc 0x4130268c <__sigsetjmp+60>: stfp f3, [r12], #8
Any suggestions what I could try next?
The posted disassembly is quite interesting.
0x41302678 <__sigsetjmp+40>: fmrx r2, fpscr
0x4130267c <__sigsetjmp+44>: str r2, [r12], #4
0x41302680 <__sigsetjmp+48>: tst r2, #512 ; 0x200
0x41302684 <__sigsetjmp+52>: beq 0x413026a0 <__sigsetjmp+80>
0x41302688 <__sigsetjmp+56>: stfp f2, [r12], #8
*0x4130268c <__sigsetjmp+60>: stfp f3, [r12], #8*
0x41302690 <__sigsetjmp+64>: stfp f4, [r12], #8
0x41302694 <__sigsetjmp+68>: stfp f5, [r12], #8
0x41302698 <__sigsetjmp+72>: stfp f6, [r12], #8
0x4130269c <__sigsetjmp+76>: stfp f7, [r12], #8
The code checks for bit 9 in fpscr, and, if set, tries to save registers f2-f7. What are those? I've never seen them in recent processors, but I think those are FPA ("Floating Point Accelerator") registers, implemented in a few old cores, and used for soft FP before VFP appeared.
So, here's what I think happens:
The libc on your device was compiled
with FPA support, probably by
mistake.
In FPA processors bit 9
meant "FPA enabled" or something
similar
In the debug version of Qt
the bit 9 of FPSCR (DZE = Division
by Zero exception enable bit) is not
set, so they don't try to save FPA
registers. However, it gets set in
the release version.
I see here two options:
Rebuild libc without FPA support
Find where DZE gets set in the release ver (not sure how to do that)
Update: I was wrong. The gdb disassembly confused me. I found the source of setjmp.S, here's the relevant part:
tst a3, #HWCAP_ARM_VFP
beq Lno_vfp
/* Store the VFP registers. */
/* Following instruction is fstmiax ip!, {d8-d15}. */
stc p11, cr8, [r12], #68
/* Store the floating-point status register. */
/* Following instruction is fmrx r2, fpscr. */
mrc p10, 7, r2, cr1, cr0, 0
str r2, [ip], #4
Lno_vfp:
tst a3, #HWCAP_ARM_IWMMXT
beq Lno_iwmmxt
/* Save the call-preserved iWMMXt registers. */
/* Following instructions are wstrd wr10, [ip], #8 (etc.) */
stcl p1, cr10, [r12], #8
stcl p1, cr11, [r12], #8
stcl p1, cr12, [r12], #8
stcl p1, cr13, [r12], #8
stcl p1, cr14, [r12], #8
stcl p1, cr15, [r12], #8
Lno_iwmmxt:
So, it's trying to store WMMXt registers, not FPA. However, there is a bug here. It's using r2 to temporarily store fpscr, but that ovewrites the previously loaded hwcap value in a3 (a3 is the APCS name for r2). Maybe the author meant to use a2, not r2, or maybe the two parts were done by different people. In either case, somehow the release version of Qt changes FPSCR (which is most likely emulated by the kernel) and the code storing iwmmxt regs is triggered.
Still, that's not the whole story. The hwcaps you pasted claim that the CPU does support iWMMXt, so I'm not sure why those instructions would be giving trouble. Maybe the reported PC value is wrong somehow. I think you should try putting breakpoint on __sigsetjmp and stepping through it by instruction (stepi), to see where exactly it crashes.
Hello I had similar problem few days ago... But I run Qt Creator 5.7 on my Slackware Linux in VMware player (not ARM device).
After successful installation I could not start Qt Creator. I tried to run Qt Creator with the following terminal command /opt/Qt5.7.0/Tools/QtCreator/bin/qtcreator and it gave me an error Illegal instruction.
After few hours spent with Google, I tried to run Qt Creator with this terminal commands /opt/Qt5.7.0/Tools/QtCreator/bin/qtcreator -noload Welcome and this worked for me.
Hope this helps someone. Sorry for late response.