libcxx std::cerr on GNU/Linux

Clang Frontend
#1

clang++ and libcxx seems mostly to work (I've been using clang for a
little while on our source tree and it's revealed a number of problems,
and libcxx has shown another couple, I think).

Actually running executables also seems to work, except for output to
std::cerr:

#include <iostream>
int main()
{
    std::cout << "Hello world\n";
}

works fine, and valgrind seems happy with it. Changing the cout to cerr
causes a crash (after producing the output):

#0 0x00007fd207b59475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007fd207b5c6f0 in *__GI_abort () at abort.c:92
#2 0x00007fd208388acb in std::uncaught_exception () at ../src/exception.cpp:103
#3 0x00007fd2083913ca in std::__1::basic_ostream<char, std::__1::char_traits<char> >::sentry::~sentry (this=<optimized out>) at ../include/ostream:243
#4 0x0000000000400d6a in std::__1::operator<< <std::__1::char_traits<char> > (__os=..., __str=0x40135c "Hello world\n") at /usr/local/include/ostream:989
#5 0x0000000000400abd in main () at hello.cpp:4

Any ideas about what might cause this? (It feels odd that cout and cerr
should differ in such a way, but I haven't really looked at the
implementation so perhaps it's obvious.)

#2

(I haven't looked if this is a bug in the runtime, but if it is)

Please report your libcxx bugs to
https://github.com/pathscale/libcxxrt/issues

Thanks

#3

If you build with libcxxrt, you have to add -DLIBCXXRT.

Joerg

#4

Joerg Sonnenberger
<joerg-R+WAh6b6Lhar4AypMXd3aLNAH6kLmebB@public.gmane.org> writes:

#5

Two replies so far, and everyone seems to be assuming you're talking about libcxxrt, not libc++. For future reference, calling libc++ libcxx apparently confuses people...

As to the bug, I've seen crashes like this before when doing the FreeBSD and Solaris ports. As I recall, that exception is thrown when the locale_t is NULL. In this case, I would expect you to be using the C locale. I believe on glibc that this is generated by calling __cloc(), so this may be a good place to look.

David

#6

No, I'm just saying that libc++ works if compiled with -DLIBCXXRT against
libcxxrt. On !Apple, the check for uncaught exceptions is explicitly
broken, i.e. calling abort().

Joerg

#7

David Chisnall <theraven-Ae9UE+oIsuU@public.gmane.org> writes:

Two replies so far, and everyone seems to be assuming you're talking
about libcxxrt, not libc++. For future reference, calling libc++
libcxx apparently confuses people...

I've changed the subject line. Probably my own fault; the directory I
checked out libc++ to is called libcxx.

As to the bug, I've seen crashes like this before when doing the
FreeBSD and Solaris ports. As I recall, that exception is thrown when
the locale_t is NULL. In this case, I would expect you to be using
the C locale.

I'm not. At least, LANG is set to en_GB.UTF-8. Setting it to C, en_GB,
unsetting it, doesn't seem to change the crash.

I believe on glibc that this is generated by calling __cloc(), so this
may be a good place to look.

OK. I'm still not seeing anything obvious: if I include <locale> then I
can create a locale (and the destructor seems to complete fine).

ldd shows I'm linking against libstdc++.so.6 and librt.so.1 as well as
libc++.so.1. Is that expected, or should I not be linking against
libstdc++?

  linux-vdso.so.1 => (0x00007fffe9976000)
  libc++.so.1 => /usr/local/lib/libc++.so.1 (0x00007fced02e2000)
  libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fced0043000)
  libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fcecfe2c000)
  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcecfaa5000)
  libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fcecf7a1000)
  libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcecf584000)
  librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fcecf37c000)
  /lib64/ld-linux-x86-64.so.2 (0x00007fced065b000)

[...]

#8

I wasn't watching closely the libc++ build.

I suspect I was just thrown by the fact that so much just worked!

I got our whole tree built and all but one of the sets of tests passed. (Our
source doesn't contain that much exotic C++ since we need it to compile
on a variety of platforms all using slightly old compilers, but even so.)

#9

Thanks for the report. Glad to hear it! It sounds like you're missing an implementation of the low level Itanium ABI. Here are two I'm aware of:

http://libcxxabi.llvm.org/

https://github.com/pathscale/libcxxrt

Howard

#10

The only part is making sure all pieces are linked.
libc++ + libgcc_s shows the issues with std::cerr (and possible other
things). No idea about libcxxabi.

Joerg