[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170725202741.GV1627@brightrain.aerifal.cx>
Date: Tue, 25 Jul 2017 16:27:41 -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 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?
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.
