Crash in QML compiler if terminated whilst compiling asynchronous components
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
camera-app (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
qtdeclarative-opensource-src (Ubuntu) |
Fix Released
|
High
|
Lorn Potter |
Bug Description
Reproducible on mako and krillin using devel-proposed r248 or rtm r50
This is easiest to reproduce with the camera-app, as this has a number of large components that get loaded asynchronously on start-up, however I believe it should be possible to trigger in any app that contains asynchronous Loaders.
Steps to reproduce
1. Start camera-app
2. Whilst loading, swipe to the app switcher.
3. Close camera-app.
Expected result
App closes cleanly
Actual result
Sometimes the app segfaults whilst closing
It may take multiple attempts to cause a crash, as the SIGTERM signal has to be received at a certain point during the compilation process for the crash to occur.
Back trace of an example crash:
"There are still "1" items in the process of being created at engine destruction."
[Thread 0xac267450 (LWP 5576) exited]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb1a3e450 (LWP 5561)]
0xb6618dd6 in createNode (left=false, parent=0x0, v=@0x31: <error reading variable>, k=@0x2d: <error reading variable>, this=0xae598538)
at /usr/include/
216 new (&n->key) Key(k);
(gdb) bt
#0 0xb6618dd6 in createNode (left=false, parent=0x0, v=@0x31: <error reading variable>, k=@0x2d: <error reading variable>, this=0xae598538)
at /usr/include/
#1 QMapNode<unsigned int, QV4::Executable
at /usr/include/
#2 0xb6618e02 in QMapNode<unsigned int, QV4::Executable
at /usr/include/
#3 0xb6618e02 in QMapNode<unsigned int, QV4::Executable
at /usr/include/
#4 0xb6618e4e in QMap<unsigned int, QV4::Executable
at /usr/include/
#5 0xb6618950 in detach (this=0x6ae34) at /usr/include/
#6 insert (avalue=<synthetic pointer>, akey=<optimized out>, this=0x6ae34) at /usr/include/
#7 QV4::Executable
#8 0xb65bc900 in ExecutableMemor
#9 allocate (size=578, this=0xb1a3cfbc) at ../3rdparty/
#10 JSC::LinkBuffer
at ../3rdparty/
#11 0xb65b18de in LinkBuffer (effort=
at ../3rdparty/
#12 QV4::JIT:
#13 0xb65b2918 in QV4::JIT:
#14 0xb65658f0 in QV4::EvalInstru
at compiler/
#15 0xb6617608 in QV4::Script:
url=..., source=..., reportedErrors=
#16 0xb666b5ac in QQmlScriptBlob:
#17 0xb66650ac in QQmlDataLoader:
#18 0xb6665292 in QQmlDataLoader:
at qml/qqmltypeloa
#19 0xb66679f8 in QQmlDataLoader:
#20 0xb6667dd2 in QQmlDataLoader:
#21 0xb6667fc2 in QQmlTypeLoader:
#22 0xb666a818 in QQmlTypeLoader:
at qml/qqmltypeloa
#23 0xb666aaa8 in QQmlTypeData:
#24 0xb666afda in QQmlTypeData:
#25 0xb66650ac in QQmlDataLoader:
#26 0xb6665292 in QQmlDataLoader:
at qml/qqmltypeloa
#27 0xb66679f8 in QQmlDataLoader:
#28 0xb6667dd2 in QQmlDataLoader:
#29 0xb6667eaa in QQmlTypeLoader:
at qml/qqmltypeloa
#30 0xb666912c in QQmlTypeData:
#31 0xb6669710 in QQmlTypeData:
#32 0xb666510e in QQmlDataLoader:
#33 0xb6665292 in QQmlDataLoader:
at qml/qqmltypeloa
#34 0xb66679f8 in QQmlDataLoader:
#35 0xb6667dd2 in QQmlDataLoader:
#36 0xb6667eaa in QQmlTypeLoader:
at qml/qqmltypeloa
#37 0xb666912c in QQmlTypeData:
#38 0xb6669710 in QQmlTypeData:
#39 0xb666510e in QQmlDataLoader:
#40 0xb6665292 in QQmlDataLoader:
at qml/qqmltypeloa
#41 0xb66679f8 in QQmlDataLoader:
#42 0xb6667d32 in QQmlDataLoaderT
#43 0xb66a2320 in QQmlThreadPriva
#44 0xb66a26e8 in QQmlThreadPriva
#45 0xb6e11f92 in QCoreApplicatio
#46 0xb6e11d88 in QCoreApplicatio
#47 0xb6e138ae in QCoreApplicatio
#48 0xb6e4bea8 in ?? () from /usr/lib/
#49 0xb5facf58 in g_main_
#50 0xb5fad104 in ?? () from /lib/arm-
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Related branches
- PS Jenkins bot: Needs Fixing (continuous-integration)
- Timo Jyrinki: Approve
-
Diff: 275 lines (+250/-0)4 files modifieddebian/changelog (+9/-0)
debian/patches/Avoid-race-condition-in-QQmlEngine-on-shutdown.patch (+84/-0)
debian/patches/Fix-crashes-when-calling-Array.sort-with-imperfect-s.patch (+155/-0)
debian/patches/series (+2/-0)
tags: | added: qa-daily-testing rtm14 |
tags: | added: qasoak |
Changed in qtdeclarative-opensource-src (Ubuntu): | |
status: | Incomplete → Confirmed |
Changed in qtdeclarative-opensource-src (Ubuntu): | |
importance: | Undecided → Critical |
Changed in qtdeclarative-opensource-src (Ubuntu): | |
assignee: | Albert Astals Cid (aacid) → Lorn Potter (lorn-potter) |
I found one commit from the 5.3 branch that sounds possibly associated - https:/ /codereview. qt-project. org/#/c/ 88153/ - and I've built it so that you can test it by:
sudo apt-add-repository ppa:canonical- qt5-edgers/ qt5-daily
sudo apt update
sudo apt dist-upgrade
It should work both on rtm and utopic images.
In a certainly promising way I was able to crash it once before upgrading, and I don't get it to crash after updating, but it might be luck also.
Can you confirm Michael if that helps with the issue? If so, we don't need actual development resources allocated and I can start landing/testing process for that backported patch.