[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 25 Jul 2017 16:39:44 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Static Qt console application linked with musl
segmentation faults on console message output with thread_local variable
On Tue, Jul 25, 2017 at 04:27:41PM -0400, Rich Felker wrote:
> On Tue, Jul 25, 2017 at 08:01:16AM +0000, Jamie Mccrae wrote:
> > Hi,
> > I have a simple Qt application which just outputs a single string to
> > the console which I'm compiling on alpine linux (raspberry pi)
> > statically with musl and it causes a segmentation fault when ran. I
> > reported the issue to Qt and provided a stack trace but they say
> > it's a problem with musl and not Qt..
> >
> > Stack trace:
> > (gdb) run
> > Starting program: /tmp/TestApp/testconsole
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x74ac7d1c in grabMessageHandler () at global/qlogging.cpp:1618
> > 1618 if (msgHandlerGrabbed)
> > (gdb) bt
> > #0 0x74ac7d1c in grabMessageHandler () at global/qlogging.cpp:1618
> > #1 0x74ac7e34 in qt_message_print (msgType=QtDebugMsg, context=..., message=...) at global/qlogging.cpp:1649
> > #2 0x74ac8024 in qt_message_output (msgType=QtDebugMsg, context=..., message=...) at global/qlogging.cpp:1696
> > #3 0x74b85d48 in QDebug::~QDebug (this=0xaefffcdc, __in_chrg=<optimized out>) at io/qdebug.cpp:156
> > #4 0x74ac2a04 in main (argc=1, argv=0xaefffd44) at main.cpp:63
> >
> > Comment from Qt developer:
> > Not our bug. That function uses a variable marked with C++11 attribute thread_local. That means it's a MUSL bug.
> >
> > Musl version: 1.1.16-r13
> >
> > Sample code to reproduce the issue:
> >
> > main.cpp:
> > int main(int argc, char *argv[])
> > {
> > QCoreApplication app(argc, argv);
> > qDebug() << "test output to console";
> > }
> >
> > main.h:
> > #ifndef MAIN_H
> > #define MAIN_H
> > #include <QCoreApplication>
> > #include <QDebug>
> > int main(int argc, char *argv[]);
> > #endif
> >
> > testconsole.pro:
> > QT += core
> > QT -= gui
> >
> > TARGET = testconsole
> > CONFIG += console
> > CONFIG -= app_bundle
> >
> > TEMPLATE = app
> >
> > SOURCES += main.cpp
> >
> > HEADERS += \
> > main.h
> >
> > Expected output:
> > test output to console
> >
> > Actual output:
> > Segmentation fault
> >
> > Build line for Qt which was used on this system:
> > ../configure -confirm-license -opensource -debug -static
> > -no-journald -no-gif -no-ico -no-egl -xinput2 -qt-xkbcommon-x11
> > -no-compile-examples -no-cups -no-iconv -no-tslib -fontconfig
> > -no-xcb-xlib -no-eglfs -no-directfb -no-linuxfb -no-kms -no-evdev
> > -no-xkbcommon-evdev -no-libproxy -no-mtdev -libinput -dbus-linked
> > -no-glib -icu -no-separate-debug-info -nomake examples -no-opengl
> > -no-openssl -no-sql-sqlite -silent -system-libjpeg -system-libpng
> > -system-pcre -qt-xcb -system-zlib -no-reduce-relocations
> >
> > Is this a bug in musl, or is any more information required for this?
>
> I think more information is probably needed. I don't see how they can
> conclude from use of thread_local that it's a musl bug. While baseline
> thread local storage support is provided by musl, the C++ specific
> part (non-POD data in TLS) is provided entirely by GCC building on top
> of what libc provides. It might be that their code is doing something
> that doesn't work with GCC's (low quality) non-POD TLS support. glibc
> provides more of the C++ TLS support on the libc side, and in the long
> term I want musl to do similarly, but due to major design flaws in the
> C++ TLS ABI GCC uses, it's impossible to achieve full
> safety/robustness without extremely large memory waste. So we've been
> holding off a bit hoping to come up with a fix for the ABI.
>
> Can you provide a little bit more info about how you're using musl?
> Cross compiler? musl-based distro?
Sorry, missed that you're using Alpine.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
