Closed nnkwame closed 1 year ago
Thanks @nnkwame ! I have a similar error in https://github.com/conda-forge/gz-gui-feedstock/issues/9, and I was able to create a 3-lines reproducible example using the qml
QT tool:
wget https://gist.githubusercontent.com/traversaro/43eecd78b6580e54c978c7fe56048518/raw/61cb46d8c456a37adbe7d2dd1c5a632df90f3a73/coldialog.qml
qml coldialog.qml
With qt-main 5.15.4 this exits with:
qml: Did not load any objects, exiting.
while with qt-main 5.15.8 this exists with:
Segmentation fault (core dumped)
where coldialog.qml
is:
import QtQuick.Dialogs 1.0
ColorDialog { }
fyi @conda-forge/qt @conda-forge/qt-main
I have the same... might there be enough motion to at least mark the new packages as broken?
As for the solution: either the compiler/cxx-flags update or the minor update of qt upstream is the problem.. any idea?
I tried to replicate the problem on Windows, but according to my experiments it happens on Linux and not on Windows.
I think there are two options:
.. we should be able to find out which it is by building 5.15.4 (build-locally.py) after re-rendering. if it segfaults it's the re-render..
I can have a look myself, but not before Tuesday.. maybe you can give it a try?
I did a bit of tests on past builds, to understand when it stopped working, this are the results:
Qt Build | Working? |
---|---|
5.15.9=*_9 |
❌ |
5.15.8=*_8 |
❌ |
5.15.6=*_6 |
❌ |
5.15.6=*_4 |
❌ |
5.15.6=*_3 (from ) |
✅ |
5.15.6=*_2 (from ) |
✅ |
The most interesting cases are 5.15.6=*_6
and 5.15.6=*_4
, that depending on the history of how the package has been installed, they work or not. In particular, if I compare two environments in which 5.15.6=*_6
installed, one working and one not, this is the difference:
< List of packages in environment: "/home/traversaro/mambaforge/envs/qtmainnotworking"
---
> List of packages in environment: "/home/traversaro/mambaforge/envs/qtmainworking"
33c33
< jpeg 9e h0b41bf4_3 conda-forge
---
> jpeg 9e h166bdaf_2 conda-forge
55a56
> libjpeg-turbo 2.1.4 h166bdaf_0 conda-forge
56a58
> libllvm16 16.0.1 hadd5161_0 conda-forge
67c69
< libudev1 253 h0b41bf4_1 conda-forge
---
> libudev1 253 h0b41bf4_0 conda-forge
111a114
> xorg-xf86vidmodeproto 2.3.1 h7f98852_1002 conda-forge
So this may be connected to the presence of both jpeg and libjpeg-turbo in the same environment, I will look more into this.
jpeg and libjpeg-turbo must not be installed at the same time, see https://github.com/conda-forge/libjpeg-turbo-feedstock/commit/6cee8324c6109060155cfe31c4175a62f7628eef So this is the likely source of the segfault, as always great debugging @traversaro
I thought @hmaarrfk submitted repodata patches but it seems something was missed.
So this is the likely source of the segfault, as always great debugging @traversaro
Unfortunately, that is not the problem. jpeg
and libjpeg-turbo
are installed side-by-side in the environment that works, not in the one that does not work. I am now able to create two environments, that are exactly the same from the point of view of installed packages and have qt-main 5.15.6=*_6, but one in which qml coldialog.qml
segfaults, and another one in which qml coldialog.qml
works fine. I have no idea why this is happening.
Create working environment:
wget https://gist.githubusercontent.com/traversaro/43eecd78b6580e54c978c7fe56048518/raw/61cb46d8c456a37adbe7d2dd1c5a632df90f3a73/coldialog.qml
mamba create -n working qt-main=5.15.6=*_6 libllvm16 libjpeg-turbo xorg-xf86vidmodeproto libudev1=253=*_0
mamba activate working
mamba install qt-main=5.15.6=*_2
qml coldialog.qml
mamba install qt-main=5.15.6=*_6
# Now qml coldialog.qml does not segfault!
qml coldialog.qml
Create a non-working environment:
wget https://gist.githubusercontent.com/traversaro/43eecd78b6580e54c978c7fe56048518/raw/61cb46d8c456a37adbe7d2dd1c5a632df90f3a73/coldialog.qml
mamba create -n working qt-main=5.15.6=*_6 libllvm16 libjpeg-turbo xorg-xf86vidmodeproto libudev1=253=*_0
mamba activate working
mamba install qt-main=5.15.6=*_2
# Here we do not call qml coldialog.qml with qt-main=5.15.6=*_2
mamba install qt-main=5.15.6=*_6
# Now qml coldialog.qml does not segfault!
qml coldialog.qml
Somehow calling qml coldialog.qml
is changing the environment and make qml coldialog.qml
works also with qt-main=5.15.6=*_6
, but even if you create the environment with the same name and then checked the environment file-by-file and they seem exactly identical, except for some fontconfig cache files, that however does not seem to influence the result (i.e. if I copy in the working environments the files of the notworking environment, the working environment continue to not segfault.
For reference, this is the environment created by this commands as of now:
^C(test1may2) traversaro@IITICUBLAP257:~/test1$ mamba list
List of packages in environment: "/home/traversaro/mambaforge/envs/test1may2"
Name Version Build Channel
────────────────────────────────────────────────────────────────────────────
_libgcc_mutex 0.1 conda_forge conda-forge
_openmp_mutex 4.5 2_gnu conda-forge
alsa-lib 1.2.8 h166bdaf_0 conda-forge
attr 2.5.1 h166bdaf_1 conda-forge
bzip2 1.0.8 h7f98852_4 conda-forge
ca-certificates 2022.12.7 ha878542_0 conda-forge
cairo 1.16.0 ha61ee94_1014 conda-forge
dbus 1.13.6 h5008d03_3 conda-forge
expat 2.5.0 hcb278e6_1 conda-forge
fftw 3.3.10 nompi_hc118613_107 conda-forge
font-ttf-dejavu-sans-mono 2.37 hab24e00_0 conda-forge
font-ttf-inconsolata 3.000 h77eed37_0 conda-forge
font-ttf-source-code-pro 2.038 h77eed37_0 conda-forge
font-ttf-ubuntu 0.83 hab24e00_0 conda-forge
fontconfig 2.14.2 h14ed4e7_0 conda-forge
fonts-conda-ecosystem 1 0 conda-forge
fonts-conda-forge 1 0 conda-forge
freetype 2.12.1 hca18f0e_1 conda-forge
gettext 0.21.1 h27087fc_0 conda-forge
glib 2.76.2 hfc55251_0 conda-forge
glib-tools 2.76.2 hfc55251_0 conda-forge
graphite2 1.3.13 h58526e2_1001 conda-forge
gst-plugins-base 1.21.3 h4243ec0_1 conda-forge
gstreamer 1.21.3 h25f0c4b_1 conda-forge
gstreamer-orc 0.4.33 h166bdaf_0 conda-forge
harfbuzz 6.0.0 h8e241bc_0 conda-forge
icu 70.1 h27087fc_0 conda-forge
jack 1.9.22 h11f4161_0 conda-forge
jpeg 9e h166bdaf_2 conda-forge
keyutils 1.6.1 h166bdaf_0 conda-forge
krb5 1.20.1 h81ceb04_0 conda-forge
lame 3.100 h166bdaf_1003 conda-forge
ld_impl_linux-64 2.40 h41732ed_0 conda-forge
libcap 2.67 he9d0100_0 conda-forge
libclang 15.0.7 default_had23c3d_1 conda-forge
libclang13 15.0.7 default_h3e3d535_1 conda-forge
libcups 2.3.3 h36d4200_3 conda-forge
libdb 6.2.32 h9c3ff4c_0 conda-forge
libedit 3.1.20191231 he28a2e2_2 conda-forge
libevent 2.1.10 h28343ad_4 conda-forge
libexpat 2.5.0 hcb278e6_1 conda-forge
libffi 3.4.2 h7f98852_5 conda-forge
libflac 1.4.2 h27087fc_0 conda-forge
libgcc-ng 12.2.0 h65d4601_19 conda-forge
libgcrypt 1.10.1 h166bdaf_0 conda-forge
libgfortran-ng 12.2.0 h69a702a_19 conda-forge
libgfortran5 12.2.0 h337968e_19 conda-forge
libglib 2.76.2 hebfc3b9_0 conda-forge
libgomp 12.2.0 h65d4601_19 conda-forge
libgpg-error 1.46 h620e276_0 conda-forge
libiconv 1.17 h166bdaf_0 conda-forge
libjpeg-turbo 2.1.4 h166bdaf_0 conda-forge
libllvm15 15.0.7 hadd5161_1 conda-forge
libllvm16 16.0.1 hadd5161_0 conda-forge
libnsl 2.0.0 h7f98852_0 conda-forge
libogg 1.3.4 h7f98852_1 conda-forge
libopus 1.3.1 h7f98852_1 conda-forge
libpng 1.6.39 h753d276_0 conda-forge
libpq 15.2 hb675445_0 conda-forge
libsndfile 1.2.0 hb75c966_0 conda-forge
libsqlite 3.40.0 h753d276_1 conda-forge
libstdcxx-ng 12.2.0 h46fd767_19 conda-forge
libsystemd0 253 h8c4010b_1 conda-forge
libtool 2.4.7 h27087fc_0 conda-forge
libudev1 253 h0b41bf4_0 conda-forge
libuuid 2.38.1 h0b41bf4_0 conda-forge
libvorbis 1.3.7 h9c3ff4c_0 conda-forge
libxcb 1.13 h7f98852_1004 conda-forge
libxkbcommon 1.5.0 h79f4944_1 conda-forge
libxml2 2.10.3 hca2bb57_4 conda-forge
libzlib 1.2.13 h166bdaf_4 conda-forge
lz4-c 1.9.4 hcb278e6_0 conda-forge
mpg123 1.31.3 hcb278e6_0 conda-forge
mysql-common 8.0.32 ha901b37_1 conda-forge
mysql-libs 8.0.32 hd7da12d_1 conda-forge
ncurses 6.3 h27087fc_1 conda-forge
nspr 4.35 h27087fc_0 conda-forge
nss 3.89 he45b914_0 conda-forge
openssl 3.1.0 hd590300_2 conda-forge
pcre2 10.40 hc3806b6_0 conda-forge
pip 23.1.2 pyhd8ed1ab_0 conda-forge
pixman 0.40.0 h36c2ea0_0 conda-forge
pthread-stubs 0.4 h36c2ea0_1001 conda-forge
pulseaudio 16.1 hcb278e6_3 conda-forge
pulseaudio-client 16.1 h5195f5e_3 conda-forge
pulseaudio-daemon 16.1 ha8d29e2_3 conda-forge
python 3.11.3 h2755cc3_0_cpython conda-forge
qt-main 5.15.6 h602db52_6 conda-forge
readline 8.2 h8228510_1 conda-forge
setuptools 67.7.2 pyhd8ed1ab_0 conda-forge
tk 8.6.12 h27826a3_0 conda-forge
tzdata 2023c h71feb2d_0 conda-forge
wheel 0.40.0 pyhd8ed1ab_0 conda-forge
xcb-util 0.4.0 h516909a_0 conda-forge
xcb-util-image 0.4.0 h166bdaf_0 conda-forge
xcb-util-keysyms 0.4.0 h516909a_0 conda-forge
xcb-util-renderutil 0.3.9 h166bdaf_0 conda-forge
xcb-util-wm 0.4.1 h516909a_0 conda-forge
xkeyboard-config 2.38 h0b41bf4_0 conda-forge
xorg-kbproto 1.0.7 h7f98852_1002 conda-forge
xorg-libice 1.0.10 h7f98852_0 conda-forge
xorg-libsm 1.2.3 hd9c2040_1000 conda-forge
xorg-libx11 1.8.4 h0b41bf4_0 conda-forge
xorg-libxau 1.0.9 h7f98852_0 conda-forge
xorg-libxdmcp 1.1.3 h7f98852_0 conda-forge
xorg-libxext 1.3.4 h0b41bf4_2 conda-forge
xorg-libxrender 0.9.10 h7f98852_1003 conda-forge
xorg-renderproto 0.11.1 h7f98852_1002 conda-forge
xorg-xextproto 7.3.0 h0b41bf4_1003 conda-forge
xorg-xf86vidmodeproto 2.3.1 h7f98852_1002 conda-forge
xorg-xproto 7.0.31 h7f98852_1007 conda-forge
xz 5.2.6 h166bdaf_0 conda-forge
zlib 1.2.13 h166bdaf_4 conda-forge
zstd 1.5.2 h3eb15da_6 conda-forge
To further debug the issue, I modified https://github.com/conda-forge/qt-main-feedstock/pull/154 to produce a qt package with included debug symbols.
Two major changes have occurred recently:
Linux is easily buildable locally using docker.
just a thought: jpeg vs libjpeg might also be a question of order of installation (?) and therefore "random"
Two major changes have occurred recently:
* x11 now uses conda forge packages instead of CDTs * jpeg to jpeg turbo.
Interestingly, beside the strange non-determinism behaviour, described in , if one creates a new environment for each test, the issue appears in 5.15.6=*_4
(see https://github.com/conda-forge/qt-feedstock/issues/241#issuecomment-1529503698), that correspond to the change in https://github.com/conda-forge/qt-main-feedstock/pull/77/files , that seems to predate both changes. As suggested by @gabm this may be related to the GCC 10 -> 11 change.
Unfortunately, that is not the problem.
jpeg
andlibjpeg-turbo
are installed side-by-side in the environment that works, not in the one that does not work. I am now able to create two environments, that are exactly the same from the point of view of installed packages and have qt-main 5.15.6=*_6, but one in whichqml coldialog.qml
segfaults, and another one in whichqml coldialog.qml
works fine. I have no idea why this is happening.
I found a simpler way of how to reproduce this strange behaviour, with qt-main=5.15.6=*_3
and qt-main=5.15.6=*_4
:
Create working environment:
wget https://gist.githubusercontent.com/traversaro/43eecd78b6580e54c978c7fe56048518/raw/61cb46d8c456a37adbe7d2dd1c5a632df90f3a73/coldialog.qml
mamba create -n working qt-main=5.15.6=*_4
mamba activate working
# qml coldialog.qml segfaults
qml coldialog.qml
mamba install qt-main=5.15.6=*_3
qml coldialog.qml
mamba install qt-main=5.15.6=*_4
# Now qml coldialog.qml does not segfault!
qml coldialog.qml
Create a non-working environment:
wget https://gist.githubusercontent.com/traversaro/43eecd78b6580e54c978c7fe56048518/raw/61cb46d8c456a37adbe7d2dd1c5a632df90f3a73/coldialog.qml
mamba create -n notworking qt-main=5.15.6=*_4
mamba activate notworking
# qml coldialog.qml segfaults
qml coldialog.qml
mamba install qt-main=5.15.6=*_3
# Here we do not call qml coldialog.qml with qt-main=5.15.6=*_3
mamba install qt-main=5.15.6=*_4
# Now qml coldialog.qml still segfaults
qml coldialog.qml
Env:
(working123) traversaro@IITICUBLAP257:~/test1$ mamba list
List of packages in environment: "/home/traversaro/mambaforge/envs/working123"
Name Version Build Channel
────────────────────────────────────────────────────────────────────────────
_libgcc_mutex 0.1 conda_forge conda-forge
_openmp_mutex 4.5 2_gnu conda-forge
alsa-lib 1.2.8 h166bdaf_0 conda-forge
attr 2.5.1 h166bdaf_1 conda-forge
bzip2 1.0.8 h7f98852_4 conda-forge
ca-certificates 2022.12.7 ha878542_0 conda-forge
dbus 1.13.6 h5008d03_3 conda-forge
expat 2.5.0 hcb278e6_1 conda-forge
fftw 3.3.10 nompi_hc118613_107 conda-forge
font-ttf-dejavu-sans-mono 2.37 hab24e00_0 conda-forge
font-ttf-inconsolata 3.000 h77eed37_0 conda-forge
font-ttf-source-code-pro 2.038 h77eed37_0 conda-forge
font-ttf-ubuntu 0.83 hab24e00_0 conda-forge
fontconfig 2.14.2 h14ed4e7_0 conda-forge
fonts-conda-ecosystem 1 0 conda-forge
fonts-conda-forge 1 0 conda-forge
freetype 2.12.1 hca18f0e_1 conda-forge
gettext 0.21.1 h27087fc_0 conda-forge
glib 2.76.2 hfc55251_0 conda-forge
glib-tools 2.76.2 hfc55251_0 conda-forge
gst-plugins-base 1.21.3 h4243ec0_1 conda-forge
gstreamer 1.21.3 h25f0c4b_1 conda-forge
gstreamer-orc 0.4.33 h166bdaf_0 conda-forge
icu 70.1 h27087fc_0 conda-forge
jack 1.9.22 h11f4161_0 conda-forge
jpeg 9e h0b41bf4_3 conda-forge
keyutils 1.6.1 h166bdaf_0 conda-forge
krb5 1.19.3 h08a2579_0 conda-forge
lame 3.100 h166bdaf_1003 conda-forge
ld_impl_linux-64 2.40 h41732ed_0 conda-forge
libcap 2.67 he9d0100_0 conda-forge
libclang 15.0.7 default_had23c3d_1 conda-forge
libclang13 15.0.7 default_h3e3d535_1 conda-forge
libcups 2.3.3 h3e49a29_2 conda-forge
libdb 6.2.32 h9c3ff4c_0 conda-forge
libedit 3.1.20191231 he28a2e2_2 conda-forge
libevent 2.1.10 h28343ad_4 conda-forge
libexpat 2.5.0 hcb278e6_1 conda-forge
libffi 3.4.2 h7f98852_5 conda-forge
libflac 1.4.2 h27087fc_0 conda-forge
libgcc-ng 12.2.0 h65d4601_19 conda-forge
libgcrypt 1.10.1 h166bdaf_0 conda-forge
libgfortran-ng 12.2.0 h69a702a_19 conda-forge
libgfortran5 12.2.0 h337968e_19 conda-forge
libglib 2.76.2 hebfc3b9_0 conda-forge
libgomp 12.2.0 h65d4601_19 conda-forge
libgpg-error 1.46 h620e276_0 conda-forge
libiconv 1.17 h166bdaf_0 conda-forge
libllvm15 15.0.7 hadd5161_1 conda-forge
libnsl 2.0.0 h7f98852_0 conda-forge
libogg 1.3.4 h7f98852_1 conda-forge
libopus 1.3.1 h7f98852_1 conda-forge
libpng 1.6.39 h753d276_0 conda-forge
libpq 15.1 h67c24c5_1 conda-forge
libsndfile 1.2.0 hb75c966_0 conda-forge
libsqlite 3.40.0 h753d276_1 conda-forge
libstdcxx-ng 12.2.0 h46fd767_19 conda-forge
libsystemd0 253 h8c4010b_1 conda-forge
libtool 2.4.7 h27087fc_0 conda-forge
libudev1 253 h0b41bf4_1 conda-forge
libuuid 2.38.1 h0b41bf4_0 conda-forge
libvorbis 1.3.7 h9c3ff4c_0 conda-forge
libxcb 1.13 h7f98852_1004 conda-forge
libxkbcommon 1.5.0 h79f4944_1 conda-forge
libxml2 2.10.3 hca2bb57_4 conda-forge
libzlib 1.2.13 h166bdaf_4 conda-forge
lz4-c 1.9.4 hcb278e6_0 conda-forge
mpg123 1.31.3 hcb278e6_0 conda-forge
mysql-common 8.0.32 ha901b37_1 conda-forge
mysql-libs 8.0.32 hd7da12d_1 conda-forge
ncurses 6.3 h27087fc_1 conda-forge
nspr 4.35 h27087fc_0 conda-forge
nss 3.89 he45b914_0 conda-forge
openssl 3.1.0 hd590300_2 conda-forge
pcre2 10.40 hc3806b6_0 conda-forge
pip 23.1.2 pyhd8ed1ab_0 conda-forge
pthread-stubs 0.4 h36c2ea0_1001 conda-forge
pulseaudio 16.1 hcb278e6_3 conda-forge
pulseaudio-client 16.1 h5195f5e_3 conda-forge
pulseaudio-daemon 16.1 ha8d29e2_3 conda-forge
python 3.11.3 h2755cc3_0_cpython conda-forge
qt-main 5.15.6 hafeba50_4 conda-forge
readline 8.2 h8228510_1 conda-forge
setuptools 67.7.2 pyhd8ed1ab_0 conda-forge
tk 8.6.12 h27826a3_0 conda-forge
tzdata 2023c h71feb2d_0 conda-forge
wheel 0.40.0 pyhd8ed1ab_0 conda-forge
xcb-util 0.4.0 h516909a_0 conda-forge
xcb-util-image 0.4.0 h166bdaf_0 conda-forge
xcb-util-keysyms 0.4.0 h516909a_0 conda-forge
xcb-util-renderutil 0.3.9 h166bdaf_0 conda-forge
xcb-util-wm 0.4.1 h516909a_0 conda-forge
xkeyboard-config 2.38 h0b41bf4_0 conda-forge
xorg-libxau 1.0.9 h7f98852_0 conda-forge
xorg-libxdmcp 1.1.3 h7f98852_0 conda-forge
xz 5.2.6 h166bdaf_0 conda-forge
zstd 1.5.2 h3eb15da_6 conda-forge
I build locally a version of qt-main with GCC 10, and it seems that there is no segfault, see file https://github.com/traversaro/qt-main-feedstock/releases/tag/build109 if you want to debug yourself.
so to summarize: it looks like compiling qt-main with gcc 11 leads to a crash in qml color dialog? maybe time to go upstream?
so to summarize: it looks like compiling qt-main with gcc 11 leads to a crash in qml color dialog? maybe time to go upstream?
I just tried to reproduce the problem with some modern distro that is probably built with a recent GCC version (Debian Sid), and there qml and ColorDialog work fine, so I guess our behaviour it is due to some strange interaction either with conda-forge patches, dependencies or build scripts. I am afraid upstream will not pay a lot of attention to any issue unless we are able to reproduce it with a vanillla qt build.
Some additional debug that I did.
I locally built a version of qt-main package symbols, it is available at https://github.com/traversaro/qt-main-feedstock/releases/tag/build109 . Unfortunatly, even with the debug symbols the backtrace of the segfault is not particularly useful, at least to me:
==180434== Thread 3 QQmlThread:
==180434== Invalid read of size 8
==180434== at 0x49F8E70: count (qvector.h:241)
==180434== by 0x49F8E70: QQmlPropertyCache::property(int) const (qqmlpropertycache_p.h:278)
==180434== by 0x4A595BC: QQmlPropertyCacheAliasCreator<QQmlTypeCompiler>::propertyDataForAlias(QmlIR::Object const&, QV4::CompiledData::Alias const&, int*, int*, QQmlPropertyData::Flags*, QQmlEnginePrivate*) (qqmlpropertycachecreator_p.h:857)
==180434== by 0x4A59889: QQmlPropertyCacheAliasCreator<QQmlTypeCompiler>::appendAliasesToPropertyCache(QmlIR::Object const&, int, QQmlEnginePrivate*) (qqmlpropertycachecreator_p.h:932)
==180434== by 0x4A57A40: QQmlComponentAndAliasResolver::resolveAliases(int) (qqmltypecompiler.cpp:1038)
==180434== by 0x4A57E60: QQmlComponentAndAliasResolver::resolve() (qqmltypecompiler.cpp:971)
==180434== by 0x4A58146: QQmlTypeCompiler::compile() (qqmltypecompiler.cpp:124)
==180434== by 0x49F432E: QQmlTypeData::compile(QQmlRefPointer<QQmlTypeNameCache> const&, QV4::ResolvedTypeReferenceMap*, std::function<QByteArray ()> const&) (qqmltypedata.cpp:768)
==180434== by 0x49F8115: QQmlTypeData::done() (qqmltypedata.cpp:445)
==180434== by 0x49EDE05: tryDone (qqmldatablob.cpp:524)
==180434== by 0x49EDE05: QQmlDataBlob::tryDone() (qqmldatablob.cpp:515)
==180434== by 0x4A23FFA: QQmlTypeLoader::setData(QQmlDataBlob*, QQmlDataBlob::SourceCodeData const&) (qqmltypeloader.cpp:457)
==180434== by 0x4A241AB: QQmlTypeLoader::setData(QQmlDataBlob*, QString const&) (qqmltypeloader.cpp:437)
==180434== by 0x4A24769: QQmlTypeLoader::loadThread(QQmlDataBlob*) (qqmltypeloader.cpp:299)
==180434== Address 0x40 is not stack'd, malloc'd or (recently) free'd
==180434==
==180434==
==180434== Process terminating with default action of signal 11 (SIGSEGV)
==180434== Access not within mapped region at address 0x40
==180434== at 0x49F8E70: count (qvector.h:241)
==180434== by 0x49F8E70: QQmlPropertyCache::property(int) const (qqmlpropertycache_p.h:278)
==180434== by 0x4A595BC: QQmlPropertyCacheAliasCreator<QQmlTypeCompiler>::propertyDataForAlias(QmlIR::Object const&, QV4::CompiledData::Alias const&, int*, int*, QQmlPropertyData::Flags*, QQmlEnginePrivate*) (qqmlpropertycachecreator_p.h:857)
==180434== by 0x4A59889: QQmlPropertyCacheAliasCreator<QQmlTypeCompiler>::appendAliasesToPropertyCache(QmlIR::Object const&, int, QQmlEnginePrivate*) (qqmlpropertycachecreator_p.h:932)
==180434== by 0x4A57A40: QQmlComponentAndAliasResolver::resolveAliases(int) (qqmltypecompiler.cpp:1038)
==180434== by 0x4A57E60: QQmlComponentAndAliasResolver::resolve() (qqmltypecompiler.cpp:971)
==180434== by 0x4A58146: QQmlTypeCompiler::compile() (qqmltypecompiler.cpp:124)
==180434== by 0x49F432E: QQmlTypeData::compile(QQmlRefPointer<QQmlTypeNameCache> const&, QV4::ResolvedTypeReferenceMap*, std::function<QByteArray ()> const&) (qqmltypedata.cpp:768)
==180434== by 0x49F8115: QQmlTypeData::done() (qqmltypedata.cpp:445)
==180434== by 0x49EDE05: tryDone (qqmldatablob.cpp:524)
==180434== by 0x49EDE05: QQmlDataBlob::tryDone() (qqmldatablob.cpp:515)
==180434== by 0x4A23FFA: QQmlTypeLoader::setData(QQmlDataBlob*, QQmlDataBlob::SourceCodeData const&) (qqmltypeloader.cpp:457)
==180434== by 0x4A241AB: QQmlTypeLoader::setData(QQmlDataBlob*, QString const&) (qqmltypeloader.cpp:437)
==180434== by 0x4A24769: QQmlTypeLoader::loadThread(QQmlDataBlob*) (qqmltypeloader.cpp:299)
==180434== If you believe this happened as a result of a stack
==180434== overflow in your program's main thread (unlikely but
==180434== possible), you can try to increase the size of the
==180434== main thread stack using the --main-stacksize= flag.
==180434== The main thread stack size used in this run was 48390144.
==180434==
==180434== HEAP SUMMARY:
==180434== in use at exit: 1,648,795 bytes in 14,319 blocks
==180434== total heap usage: 29,220 allocs, 14,901 frees, 3,515,728 bytes allocated
==180434==
==180434== LEAK SUMMARY:
==180434== definitely lost: 104 bytes in 8 blocks
==180434== indirectly lost: 16,496 bytes in 2 blocks
==180434== possibly lost: 11,012 bytes in 88 blocks
==180434== still reachable: 1,621,183 bytes in 14,221 blocks
==180434== of which reachable via heuristic:
==180434== newarray : 27,712 bytes in 8 blocks
==180434== suppressed: 0 bytes in 0 blocks
==180434== Rerun with --leak-check=full to see details of leaked memory
==180434==
==180434== For lists of detected and suppressed errors, rerun with: -s
==180434== ERROR SUMMARY: 7 errors from 5 contexts (suppressed: 0 from 0)
Segmentation fault
Under the hypothesis that there could be an uninteded ABI change due to the GCC upgrade, I prepare a small python script to print the GCC version used to compile the packages in the envirionment:
import subprocess
import json
import os
conda_meta_dir = os.environ['CONDA_PREFIX'] + "/conda-meta"
def search_json_files(directory, key):
results = []
for filename in os.listdir(directory):
if filename.endswith('.json'):
filepath = os.path.join(directory, filename)
with open(filepath, 'r') as f:
json_data = json.load(f)
if key in json_data:
ident = json_data["name"]
results.append((ident, json_data[key]))
return results
packages = search_json_files(conda_meta_dir, "extracted_package_dir")
for package in packages:
# Open info file
hash_input_file = package[1] + "/info/hash_input.json"
if os.path.isfile(hash_input_file):
with open(hash_input_file, 'r') as f:
json_pkg = json.load(f)
if ("c_compiler_version" in json_pkg):
print(f"{package[0]} c_compiler_version: {json_pkg['c_compiler_version']}")
if ("cxx_compiler_version" in json_pkg):
print(f"{package[0]} cxx_compiler_version: {json_pkg['cxx_compiler_version']}")
if ("fortran_compiler_version" in json_pkg):
print(f"{package[0]} fortran_compiler_version: {json_pkg['fortran_compiler_version']}")
Executing this, this is the output:
(qtmain) traversaro@IITICUBLAP257:~/test1$ python printcxxver.py
xorg-libx11 c_compiler_version: 11
lz4-c c_compiler_version: 11
lz4-c cxx_compiler_version: 11
libcups c_compiler_version: 11
libcups cxx_compiler_version: 11
libclang13 cxx_compiler_version: 12
freetype c_compiler_version: 10
libxcb c_compiler_version: 9
xorg-libxau c_compiler_version: 9
libgpg-error c_compiler_version: 10
libgpg-error cxx_compiler_version: 10
xcb-util-wm c_compiler_version: 7
xz c_compiler_version: 10
graphite2 c_compiler_version: 7
graphite2 cxx_compiler_version: 7
bzip2 c_compiler_version: 9
expat c_compiler_version: 11
expat cxx_compiler_version: 11
xcb-util c_compiler_version: 7
pcre2 c_compiler_version: 10
libflac c_compiler_version: 10
libflac cxx_compiler_version: 10
libjpeg-turbo c_compiler_version: 11
libuuid c_compiler_version: 11
libvorbis c_compiler_version: 9
libvorbis cxx_compiler_version: 9
libglib c_compiler_version: 12
libglib cxx_compiler_version: 12
libgcrypt c_compiler_version: 10
attr c_compiler_version: 10
pthread-stubs c_compiler_version: 7
tk c_compiler_version: 9
libllvm16 cxx_compiler_version: 12
xorg-libxext c_compiler_version: 11
libclang cxx_compiler_version: 12
xorg-xextproto c_compiler_version: 11
openssl c_compiler_version: 12
python c_compiler_version: 11
python cxx_compiler_version: 11
mpg123 c_compiler_version: 11
mpg123 cxx_compiler_version: 11
libexpat c_compiler_version: 11
libexpat cxx_compiler_version: 11
qt-main c_compiler_version: 12
qt-main cxx_compiler_version: 12
mysql-common cxx_compiler_version: 11
xorg-libxdmcp c_compiler_version: 9
glib c_compiler_version: 12
glib cxx_compiler_version: 12
gstreamer c_compiler_version: 11
gstreamer cxx_compiler_version: 11
xorg-xproto c_compiler_version: 9
gettext c_compiler_version: 10
gettext cxx_compiler_version: 10
tzdata c_compiler_version: 11
libxml2 c_compiler_version: 11
keyutils c_compiler_version: 10
xorg-kbproto c_compiler_version: 9
harfbuzz c_compiler_version: 11
harfbuzz cxx_compiler_version: 11
ncurses c_compiler_version: 10
ncurses cxx_compiler_version: 10
xorg-xf86vidmodeproto c_compiler_version: 9
ld_impl_linux-64 c_compiler_version: 11
ld_impl_linux-64 cxx_compiler_version: 11
libpng c_compiler_version: 10
libiconv c_compiler_version: 10
lame c_compiler_version: 10
gst-plugins-base c_compiler_version: 11
gst-plugins-base cxx_compiler_version: 11
xcb-util-image c_compiler_version: 10
mysql-libs cxx_compiler_version: 11
pulseaudio-client c_compiler_version: 11
pulseaudio-client cxx_compiler_version: 11
fontconfig c_compiler_version: 11
libxkbcommon c_compiler_version: 11
libxkbcommon cxx_compiler_version: 11
zstd c_compiler_version: 11
zstd cxx_compiler_version: 11
dbus c_compiler_version: 9
libnsl c_compiler_version: 9
libsqlite c_compiler_version: 10
libopus c_compiler_version: 9
libsndfile c_compiler_version: 11
libsndfile cxx_compiler_version: 11
alsa-lib c_compiler_version: 10
libffi c_compiler_version: 9
krb5 c_compiler_version: 11
krb5 cxx_compiler_version: 11
libpq c_compiler_version: 11
libzlib c_compiler_version: 10
zlib c_compiler_version: 10
xorg-libice c_compiler_version: 9
xorg-libxrender c_compiler_version: 9
xorg-renderproto c_compiler_version: 9
nss c_compiler_version: 11
nss cxx_compiler_version: 11
libevent c_compiler_version: 9
icu c_compiler_version: 11
icu cxx_compiler_version: 11
libcap c_compiler_version: 11
cairo c_compiler_version: 11
libsystemd0 c_compiler_version: 11
xorg-libsm c_compiler_version: 9
xkeyboard-config c_compiler_version: 11
nspr c_compiler_version: 10
nspr cxx_compiler_version: 10
pixman c_compiler_version: 7
readline c_compiler_version: 11
glib-tools c_compiler_version: 12
glib-tools cxx_compiler_version: 12
libedit c_compiler_version: 7
xcb-util-keysyms c_compiler_version: 7
xcb-util-renderutil c_compiler_version: 10
libogg c_compiler_version: 9
However, it seems to be that most dependencies that were compiled with GCC <= 10 have only C ABIs, and I tought it was more probably the an ABI break occured on the C++ side.
At this point I am a bit out of ideas on how to go forward, so if anyone has a suggestion feel free to make it, thanks!
So this is the likely source of the segfault, as always great debugging @traversaro
Unfortunately, that is not the problem.
jpeg
andlibjpeg-turbo
are installed side-by-side in the environment that works, not in the one that does not work. I am now able to create two environments, that are exactly the same from the point of view of installed packages and have qt-main 5.15.6=*_6, but one in whichqml coldialog.qml
segfaults, and another one in whichqml coldialog.qml
works fine. I have no idea why this is happening.
At least I find an explanation for this strange behaviour: qml caches some files in ~/.cache/QtProject/Qml Runtime/qmlcache
, with a cache key that depends on the location of the Qt libraries (and hence on the name of the conda environment) and probably the qt version. If I cleanup that cache everytime I change the qt version, that I can reliable make 5.15.6=*_4
fail, regardless of which qt version was installed before in the environment.
I think I found a related issue upstream: https://bugreports.qt.io/browse/QTBUG-99545 (and its duplicate https://bugreports.qt.io/browse/QTBUG-111795). If this is the bug that is causing this issue, indeed the problem is due to the use of GCC11 as @gabm suggested. Unfortunatly, the fix for that landed in qt5 5.15.11 that is not currently as open source, that will be released in October 2023. Probably we can try to backport the qt6 fix ourself, or look if other distributions already backported it.
A possible alternative is to use one of the possible workarounds:
-optimize-size
option and then we remove the workaround with the update to 5.15.11 once it is available.
wow.. what a (painful) debug story.. thank you for diging so deep!
idk whats the best course of action though.. gcc 10 or fixing ourselves (without violating their license)?
It seems to me that downgrading to GCC 10 or using no-optimize-size seems to be easiest.
I fear that gcc10 might get stale over the coming months before the 5.15.11 release so i would opt for the additional compilation flag.
Excellent debugging work!
The patches to backport look massive....
just for the record how arch does things:
--optimize-size
nor --no-optimize-size
in the recipe: https://github.com/archlinux/svntogit-packages/blob/packages/qt5-base/trunk/PKGBUILDnostrip
and lctg
, even by patching qmake-config: https://github.com/archlinux/svntogit-packages/blob/packages/qt5-base/trunk/qmake-config.patchon another note:
It seems to me that downgrading to GCC 10 or using no-optimize-size seems to be easiest.
I fear that gcc10 might get stale over the coming months before the 5.15.11 release so i would opt for the additional compilation flag.
Ok, I tried locally -no-optimize-size
(see https://github.com/traversaro/qt-main-feedstock/commit/12104cf6444d62d98941752be01ee8a57cce29c3) and it seems to be working as expected, i.e. there is no segfault. @hmaarrfk How do you prefer to proceed with this? I guess we could add the modification on https://github.com/conda-forge/qt-main-feedstock/pull/145, but we probably need to re-build arm + ppc builds, so let me know what do you prefer.
there is neither
--optimize-size
nor--no-optimize-size
in the recipe: https://github.com/archlinux/svntogit-packages/blob/packages/qt5-base/trunk/PKGBUILD
I guess that the default if nothing is indicated is -no-optimize-size
, so they are not hitting the bug for now.
@hmaarrfk How do you prefer to proceed with this? I guess we could add the modification on conda-forge/qt-main-feedstock#145, but we probably need to re-build arm + ppc builds, so let me know what do you prefer.
I just realized that https://github.com/conda-forge/qt-main-feedstock/pull/145 is blocked by https://github.com/conda-forge/qt-webengine-feedstock/pull/26 that is blocked by https://github.com/conda-forge/qt-webengine-feedstock/issues/25 . If you prefer, I can open a PR with the -no-optimize-size
against the current main.
I think the best way is to create a new PR against main to fix existing problems.. I don't see a reason why we should wait for https://github.com/conda-forge/qt-main-feedstock/pull/145 to deliver fixes..
I don't see a reason why we should wait for conda-forge/qt-main-feedstock#145 to deliver fixes..
qt-main requires the manual building and upload of some variants (aarch64 and ppc64le) for every new PR that is merged as they take too much time in the CI, that is the reason why the amount of PR merged in that repo is subject to the kind availability of mantainers.
got it, thanks for clarification
I guess I find it "easy" to rebuild Linux. I can start some jobs locally if you make the PR.
qt-main builds fine with emulation.
I guess I find it "easy" to rebuild Linux. I can start some jobs locally if you make the PR.
qt-main builds fine with emulation.
Thanks, done in https://github.com/conda-forge/qt-main-feedstock/pull/155 .
I just tested with qt-main 5.15.8 h5c52f38_10
and the issue seems solved, thanks @hmaarrfk !
Solution to issue cannot be found in the documentation.
Issue
Including a ColorDialog object in the following QML code for a simple colour changing-canvas causes a segmentation fault (core dumped) with qt 5.15.8. The same example works on qt 5.15.4:
This is called from:
Needed for build:
... [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Loaded '/home/nkw/qt-minimal-fail-example-test/.devenv/host/lib/libQt5Gui.so.5'. Symbols loaded. ...
Loaded '/home/nkw/qt-minimal-fail-example-test/.devenv/host/lib/./././libXdmcp.so.6'. Symbols loaded. [New Thread 0x7ffff340a700 (LWP 544672)] [New Thread 0x7ffff2bb0700 (LWP 544673)] [New Thread 0x7ffff23af700 (LWP 544675)]
Thread 4 "QQmlThread" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff23af700 (LWP 544675)] 0x00007ffff79fc372 in QQmlPropertyCache::property(int) const () from /home/nkw/qt-minimal-fail-example-test/.devenv/host/lib/libQt5Qml.so.5
Environment info