libcxx std::cerr on GNU/Linux

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

libcxx std::cerr on GNU/Linux

bruce.r.stephens
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.)
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: libcxx std::cerr on GNU/Linux

C Bergström
On 02/29/12 09:03 PM, Bruce Stephens wrote:

> 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):
(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

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: libcxx std::cerr on GNU/Linux

Joerg Sonnenberger
In reply to this post by bruce.r.stephens
On Wed, Feb 29, 2012 at 02:03:11PM +0000, Bruce Stephens wrote:
> 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).

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

Joerg
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: libcxx std::cerr on GNU/Linux

bruce.r.stephens



Joerg Sonnenberger
<[hidden email]> writes:

> On Wed, Feb 29, 2012 at 02:03:11PM +0000, Bruce Stephens wrote:
>> 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).
>
> If you build with libcxxrt, you have to add -DLIBCXXRT.

But I'm not building with libcxxrt, am I?

Should I be?


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: libcxx std::cerr on GNU/Linux

David Chisnall
In reply to this post by bruce.r.stephens
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

On 29 Feb 2012, at 14:03, Bruce Stephens wrote:

> 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.)
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


-- Sent from my Difference Engine




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: libcxx std::cerr on GNU/Linux

Joerg Sonnenberger
On Wed, Feb 29, 2012 at 04:32:04PM +0000, David Chisnall wrote:
> 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...

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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: libc++ std::cerr on GNU/Linux

bruce.r.stephens
In reply to this post by David Chisnall
David Chisnall <[hidden email]> 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)

[...]

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: libcxx std::cerr on GNU/Linux

bruce.r.stephens
In reply to this post by bruce.r.stephens
On Wed, Feb 29, 2012 at 6:21 PM, Howard Hinnant <[hidden email]> wrote:

> Watch your build messages closely.  If any of them say something along the lines of:
>
> #warning foo not implemented
>
> then you can expect calls to abort() when foo is called.

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.)

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: libcxx std::cerr on GNU/Linux

Howard Hinnant
On Feb 29, 2012, at 1:44 PM, Bruce Stephens wrote:

> On Wed, Feb 29, 2012 at 6:21 PM, Howard Hinnant <[hidden email]> wrote:
>
>> Watch your build messages closely.  If any of them say something along the lines of:
>>
>> #warning foo not implemented
>>
>> then you can expect calls to abort() when foo is called.
>
> 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.)

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

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: libcxx std::cerr on GNU/Linux

Joerg Sonnenberger
In reply to this post by bruce.r.stephens
On Wed, Feb 29, 2012 at 06:44:22PM +0000, Bruce Stephens wrote:

> On Wed, Feb 29, 2012 at 6:21 PM, Howard Hinnant <[hidden email]> wrote:
>
> > Watch your build messages closely.  If any of them say something along the lines of:
> >
> > #warning foo not implemented
> >
> > then you can expect calls to abort() when foo is called.
>
> 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.)

>From my own testing: for Linux libc++ + libcxxrt + libunwind works fine.
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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev