Bug 27925

Created attachment 12151 [details]
Backtrace for a kdelibs4-based program

Created attachment 12152 [details]
Backtrace of the simple qtconfig tool (Qt4 version)

Jan reported this issue on IRC at the same time we started having issues building kdelibs4 and kdebase4-runtime with documentation, due to meinproc4 spiking to 100% CPU and running infinitely.  I can't help but think that these issues are somehow related.  We've rebuilt kdelibs4 (without docs for now), but it didn't fix either issue.

Assignee: bugsquad => kde
CC: (none) => luigiwalser

It doesn't seem linked to KDELibs4, all packages which use Qt4 (and not KDELibs4) which I tested also crash:

$ vidalia 
QPixmap: Must construct a QApplication before a QPaintDevice
Aborted (core dumped)

$ v4l2ucp 
QPixmap: Must construct a QApplication before a QPaintDevice
Aborted (core dumped)s

$ svgcleaner-gui 
QPixmap: Must construct a QApplication before a QPaintDevice
Aborted (core dumped)

Summary: Some KDElibs4-based programs crash after Qt4 update for ICU 68 => All Qt4 applications crash after Qt4 update for ICU 68.1
Severity: major => critical

From a quick look, among the distros which still package qt4 we seem to be the only ones who already upgraded to ICU 68, so I couldn't find any other downstream bug report or patch to help us.

On the other hand there has been a 68.2 bugfix release a couple of weeks ago, with a number of fixes: https://github.com/unicode-org/icu/compare/release-68-1...release-68-2

At least a couple of those issues were found in Chromium when they updated to 68.1, and one of them caused a crash on Linux, so with some luck it's the same issue we have in Qt 4. I'll push the update and a Qt 4 rebuild, we'll see.

Here's a backtrace from the Vidalia crash:

```
(gdb) bt
#0  0x00007ffff6ab5510 in raise () at /lib64/libc.so.6
#1  0x00007ffff6aa0526 in abort () at /lib64/libc.so.6
#2  0x00007ffff6e7ba74 in qt_message_output(QtMsgType, char const*) (msgType=<optimized out>, buf=<optimized out>) at global/qglobal.cpp:2423
#3  0x00007ffff6e9b89f in qt_message(QtMsgType, const char *, typedef __va_list_tag __va_list_tag *)
    (msgType=QtFatalMsg, msg=0x7ffff7a697d8 "QPixmap: Must construct a QApplication before a QPaintDevice", ap=0x7fffffffce28) at global/qglobal.cpp:2469
#4  0x00007ffff6e9c017 in qFatal(char const*, ...) (msg=msg@entry=0x7ffff7a697d8 "QPixmap: Must construct a QApplication before a QPaintDevice") at global/qglobal.cpp:2652
#5  0x00007ffff751ce01 in qt_pixmap_thread_test() () at image/qpixmap.cpp:102
#6  0x00007ffff751d43b in QPixmap::QPixmap() (this=0x928b58) at image/qpixmap.cpp:174
#7  0x00007ffff74d4e67 in QCursorData::QCursorData(Qt::CursorShape) (this=0x928b40, s=<optimized out>) at kernel/qcursor_x11.cpp:77
#8  0x00007ffff746aca7 in QCursorData::initialize() () at kernel/qcursor.cpp:403
#9  0x00007ffff74d6a29 in QX11Data::xdndSetup() () at kernel/qdnd_x11.cpp:708
#10 0x00007ffff74c6ca4 in qt_init(QApplicationPrivate*, int, _XDisplay*, unsigned long, unsigned long) () at kernel/qapplication_x11.cpp:2027
#11 0x00007ffff745eb15 in QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) () at kernel/qapplication.cpp:838
#12 0x00007ffff745ed2f in QApplication::QApplication(int&, char**, int) () at kernel/qapplication.cpp:741
#13 0x00000000004bf1b4 in Vidalia::Vidalia(QStringList, int&, char**) ()
#14 0x0000000000462976 in main ()
```

There's not much related to ICU here, nor in Jan's backtraces, so focusing on the ICU rebuild might be a red herring.

It might be any other change that happened between the previous rebuild (Aug 25) and the ICU one (Nov 30): http://svnweb.mageia.org/packages/cauldron/qt4/current/SPECS/qt4.spec?view=log&pathrev=1650920

Especially it could also likely be something that impacts the actual Qt4 lib binaries, e.g. glibc, gcc, etc., since no other shared libraries are involved (at least as far as the backtrace shows it, it can still be the consequence of something done via a shared library).

(In reply to Rémi Verschelde from comment #6)
> There's not much related to ICU here, nor in Jan's backtraces, so focusing
> on the ICU rebuild might be a red herring.
> 
> It might be any other change that happened between the previous rebuild (Aug
> 25) and the ICU one (Nov 30):
> http://svnweb.mageia.org/packages/cauldron/qt4/current/SPECS/qt4.
> spec?view=log&pathrev=1650920
> 
> Especially it could also likely be something that impacts the actual Qt4 lib
> binaries, e.g. glibc, gcc, etc., since no other shared libraries are
> involved (at least as far as the backtrace shows it, it can still be the
> consequence of something done via a shared library).

Confirmed, I rebuilt ICU 67.1 locally, then rebuilt Qt 4, and vidalia or qtconfig still crash the same way. So ICU is not the problem.

Summary: All Qt4 applications crash after Qt4 update for ICU 68.1 => All Qt4 applications crash after Qt4 rebuild in late Nov 2020, worked in Aug 2020

Yeah, I was never sure why Jan thought it was related to the ICU update, other than the timing of when the issue started.  I hope we can figure this out soon, so I can upgrade to Cauldron and hopefully get my video card working.

He first reported it on IRC at 10:42 am Eastern time on December 1st.  ICU had just been updated over the previous night.  I don't know how often he updates his system.  I see that glibc 2.32 had also been pushed 5 days earlier.

I update quite often. My mentioning of the ICU update as possible culprit came basically from having had, very very recently, Qt4 updated to "rebuild against ICU68". But I have no idea it there's any relation, other than the last step before crashing in my backtrace, is a string comparison.

It doesn't look like glibc 2.32 did it either, because the autobuild on 11-27 didn't show the Qt4 crashing (kpdftool, qscriptgenerator) even though it was running with glibc 2.32.  The autobuild on 12-06 did show it, so the cause happened some time between the kickoff of the 11-27 autobuild and the morning of 12-01 when Jan updated and first saw the problem.

Qt4 dependencies that were updated during that time frame:
fontconfig (2.13.93)
gcc (20201128)
icu (68.1)
mesa (20.3.0-rc3)

Rémi ruled out icu as being the cause in Comment 7, so it was likely one of the other three.

Build log for kpdftool that shows Qt4's uic3 crashing:
http://pkgsubmit.mageia.org/autobuild/cauldron/aarch64/core/2020-12-26/kpdftool-0.23.1-10.mga8.src.rpm/build.0.20201226025645.log

Could it be a fallout of binutils 2.35 that atleast qt5 had some issues with?

https://sourceware.org/bugzilla/show_bug.cgi?id=26928

I don't think so, unless it didn't have its effect until other things were built with it.  binutils 2.35 was also in the 11-27 autobuild which did not show the issue.

(In reply to David Walser from comment #15)
> I don't think so, unless it didn't have its effect until other things were
> built with it.  binutils 2.35 was also in the 11-27 autobuild which did not
> show the issue.


Well, since autobuild does not install the srpms it rebuilt in the chroot, it would miss breaking a base qt package...

the qtbug is: https://bugreports.qt.io/browse/QTBUG-86173

just a thought as the timing could match somewhat...

(In reply to David Walser from comment #12)
> Qt4 dependencies that were updated during that time frame:
> fontconfig (2.13.93)

I can rule that one out, as I can run a Qt4 app on Mageia 7 using Mageia 8's fontconfig package with an LD_LIBRARY_PATH trick.

(In reply to David Walser from comment #12)
> Qt4 dependencies that were updated during that time frame:
> gcc (20201128)

That one's OK too (libgcc1 and libstdc++6).

(In reply to David Walser from comment #12)
> Qt4 dependencies that were updated during that time frame:
> mesa (20.3.0-rc3)

Also fine, so I'm quite perplexed now.

It also runs fine with Mageia 8's Qt4 libraries themselves, so the issue is definitely in a dependency (the only one I couldn't get it to use was lib64qtscript4 because of a glibc mismatch).

looking at a qt4 buildlog is uses reduced_relocations, so going by that it's most likely affected by the binutils qtbug wich means it's use of

-Bsymbolic-functions should also add "--dynamic-list-data" ...

I tried running it against Mageia 8's other direct dependencies of Qt4 (dbus, fontconfig, freetype2, ice, jpeg, mng, openssl, png16, sm, tiff, x11, xcursor, xext, xfixes, xi, xinerama, xrandr, xrender, and zlib libraries) and it still doesn't crash, so it must be some recursive dependency.  I couldn't get it to work with glib2.0 because of the same glibc mismatch as in the previous comment.

(In reply to Thomas Backlund from comment #21)
> looking at a qt4 buildlog is uses reduced_relocations, so going by that it's
> most likely affected by the binutils qtbug wich means it's use of
> 
> -Bsymbolic-functions should also add "--dynamic-list-data" ...

Perhaps, but that doesn't seem to be what's causing these crashes, given Comment 20.

One easy way to find out... hopefully...

I've pushed qt4-4.8.7-35.mga8 with disabled reduced_relocations to the buildsystemm...

Lets see if it helps

OK, finally I can reproduce the segfault.  It is caused by glibc 2.32.  I don't know why it didn't show up in the 11-27 autobuild.  It specifically is libdl-2.32.so that causes the segfault.  I can have almost all of the other mga8 libraries shown by ldd in play without it segfaulting.

I've just rebuit kpdftool-0.23.1-11.mga8 with the newly built qt4-4.8.7-35.mga8 and the build completed...

Maybe we need to rebuild all qt4 apps now to be sure ?

i don't think rebuilds are needed because today i tested Vidalia as reported by Akien => It was crashing.

I just updated my cauldron with your new Qt4 => No more crashes.


You are the best :)

CC: (none) => mageia

Awesome.  Jan, how do things look on your end?

(In reply to Thomas Backlund from comment #24)
> I've pushed qt4-4.8.7-35.mga8 with disabled reduced_relocations to the
> buildsystemm...
> 
> Lets see if it helps

IT HELPED!! I tip my hat to you, sir! =)



(In reply to David Walser from comment #28)
> Awesome.  Jan, how do things look on your end?

They look great! Most basic test: Qt4's qtconfig works again, and kdelibs4 programs I've tested work just fine, apparently (at the very least, they launch an appear normal xD)


THANK YOU ALL!! Mageicians rock, as always!

Fantastic job Thomas.

Resolution: (none) => FIXED
Status: NEW => RESOLVED