[Bug c++/59675] New: -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)

[Bug c++/59675] New: -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)

[jan.kratochvil at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675

            Bug ID: 59675
           Summary: -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jan.kratochvil at redhat dot com
            Target: x86_64-unknown-linux-gnu

Created attachment 31570
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31570&action=edit
Fix.

__replacement_assert: __builtin_printf() -> __builtin_fprintf(stderr)

Regular assert() prints to stderr.

The fix works on a live system but it was not run on a testsuite.

[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)

[jan.kratochvil at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675

--- Comment #2 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
It needs also some new #include as otherwise one may get:

In file included from /usr/include/c++/4.8.2/bits/stl_algobase.h:59:0,
                 from /usr/include/c++/4.8.2/list:60,
                 from list.C:1:
/usr/include/c++/4.8.2/x86_64-redhat-linux/bits/c++config.h: In function ‘void
std::__replacement_assert(const char*, int, const char*, const char*)’:
/usr/include/c++/4.8.2/x86_64-redhat-linux/bits/c++config.h:2042:23: error:
‘stderr’ was not declared in this scope
     __builtin_fprintf(stderr, "%s:%d: %s: Assertion '%s' failed.\n", __file,
                       ^
>From gcc-bugs-return-440396-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jan 15 08:35:24 2014
Return-Path: <gcc-bugs-return-440396-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3159 invoked by alias); 15 Jan 2014 08:35:24 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3135 invoked by uid 48); 15 Jan 2014 08:35:20 -0000
From: "joerg.richter@pdv-fs.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/59821] New: __builtin_LINE and __builtin_FILE for new'd objects is wrong
Date: Wed, 15 Jan 2014 08:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: joerg.richter@pdv-fs.de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-59821-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg01538.txt.bz2
Content-length: 850

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY821

            Bug ID: 59821
           Summary: __builtin_LINE and __builtin_FILE for new'd objects is
                    wrong
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: joerg.richter@pdv-fs.de

The script below demonstrates that __builtin_LINE used in constructors
is different when the object is allocated with new.  The same is true for
__builtin_FILE and I suspect also for __builtin_FUNCTION.


cat > t.cc <<EOF
#include <cassert>
struct Foo
{
    int line;
    Foo( int line = __builtin_LINE() )
      : line( line )
    {}
};

int main()
{
  assert( Foo().line == (new Foo)->line );
}
EOF

g++ -o t t.cc
./t

[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That is a non-starter though IMHO, because that would pollute the headers. 
Perhaps you need to export some helper routine from libstdc++.so, which will
just do va_list ap; va_start (ap, fmt); vfprintf (stderr, fmt, ap); va_end
(ap); ?

[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, we've tried hard to stop polluting our headers with unnecessary includes,
so that would be a step backwards.

[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)

[jan.kratochvil at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675

--- Comment #5 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
gcc-4.9.2-6.fc21.x86_64:
gcc-5.1.1-1.fc23.x86_64
#include <debug/string>
int main() { __gnu_debug::string s((const char *)0); }
g++ -o gcc59675b gcc59675b.C -Wall -g -D_GLIBCXX_DEBUG
-D_GLIBCXX_DEBUG_PEDANTIC
./gcc59675b 2>/dev/null
/usr/include/c++/5.1.1/debug/functions.h:315: const _CharT*
__gnu_debug::__check_string(const _CharT*) [with _CharT = char]: Assertion '__s
!= 0' failed.
Aborted

I was hitting this issue often on some older GCC versions but now I find it
very difficult to reproduce.  __glibcxx_assert() is probably no longer too much
used.  For some reason I could no longer even reproduce it with std::string.

[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-05-06
     Ever confirmed|0                           |1

[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)

[jan.kratochvil at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|4.8.2                       |9.2.1

--- Comment #6 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
libstdc++-devel-9.2.1-1.fc31.x86_64
cat >gcc59675b.C <<EOH
#include <memory>
int main() { std::shared_ptr<int> sp; return *sp; }
EOH
g++ -o gcc59675b gcc59675b.C -Wall -g -D_GLIBCXX_DEBUG
-D_GLIBCXX_DEBUG_PEDANTIC
$ ./gcc59675b 2>/dev/null
/usr/include/c++/9/bits/shared_ptr_base.h:1007: std::__shared_ptr_access<_Tp,
_Lp, <anonymous>, <anonymous> >::element_type& std::__shared_ptr_access<_Tp,
_Lp, <anonymous>, <anonymous> >::operator*() const [with _Tp = int;
__gnu_cxx::_Lock_policy _Lp = __gnu_cxx::_S_atomic; bool <anonymous> = false;
bool <anonymous> = false; std::__shared_ptr_access<_Tp, _Lp, <anonymous>,
<anonymous> >::element_type = int]: Assertion '_M_get() != nullptr' failed.
Aborted
$ ./gcc59675b >/dev/null
Aborted

[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)

[yfeldblum at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675

Jay Feldblum <yfeldblum at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yfeldblum at gmail dot com

--- Comment #7 from Jay Feldblum <yfeldblum at gmail dot com> ---
Created attachment 51622
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51622&action=edit
[PATCH] print extended assertion failures to stderr

It is ordinarily expected that assertion failures go to stderr and that stdout
be reserved for output intentionally produced by the application. Testing,
deployment, and monitoring infrastructures are often set up to match this
expectation.

A colleague recently noticed that some testing infrastructure at work does not
observe assertion failures from libstdc++ that would be expected to be observed
from building with `-D_GLIBCXX_ASSERTIONS`.

I have attached a patch - may we do something like it, or at least make
progress otherwise?

I read through the comments on this bug so far. It seems like there is some
desire to address this issue, with a caveat listed and with a suggestion
listed.

The caveat, not to pollute `bits/c++config` with `#include </* anything, really
*/>`. Are there more caveats to be aware of?

The suggestion, to export a helper routine that would work like `printf` but
emit to stderr. I can't tell whether that's a strong or weak preference. The
patch I went with - exporting a helper routine that returns the value of
`stderr` - is a bit smaller. But if that's not the preference then I can change
the patch.

Beyond the question of what helper routine to add, there is where to add it. I
cam e up with a guess but perhaps a better place will be suggested.

[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jay Feldblum from comment #7)
> The caveat, not to pollute `bits/c++config` with `#include </* anything,
> really */>`. Are there more caveats to be aware of?

No, that's it. The additional overhead of calling a function defined in the
library is not a problem, because we're aborting anyway.

> 
> The suggestion, to export a helper routine that would work like `printf` but
> emit to stderr. I can't tell whether that's a strong or weak preference. The
> patch I went with - exporting a helper routine that returns the value of
> `stderr` - is a bit smaller. But if that's not the preference then I can
> change the patch.

That seems OK. Another option would be to export the existing __snprintf_lite
function and print into a buffer, then use ::write(2, ...) to output that.
Either way requires adding a new export to the library. Using write has some
other advantages, but means polluting the namespace (and isn't available on all
targets) which isn't a problem with __builtin_printf or __builtin_fprintf.


> Beyond the question of what helper routine to add, there is where to add it.
> I cam e up with a guess but perhaps a better place will be suggested.

src/c++98/compatibility.cc is definitely wrong, that's for symbols that are
only retained for backwards compatibility with previous releases. Not for new
symbols for new features.

Patches should be sent to the libstdc++ and gcc-patches mailing lists for
review though, rather than attached here.

Thanks for working on this!

[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
           Keywords|                            |patch

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Patch available now:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582682.html

[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:a54ce8865a885bca5ab9c4aa6ec725cd13c09901

commit r12-5193-ga54ce8865a885bca5ab9c4aa6ec725cd13c09901
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Nov 3 16:06:29 2021 +0000

    libstdc++: Print assertion messages to stderr [PR59675]

    This replaces the printf used by failed debug assertions with fprintf,
    so we can write to stderr.

    To avoid including <stdio.h> the assert function is moved into the
    library. To avoid programs using a vague linkage definition of the old
    inline function, the function is renamed. Code compiled with old
    versions of GCC might still call the old function, but code compiled
    with the newer GCC will call the new function and write to stderr.

    libstdc++-v3/ChangeLog:

            PR libstdc++/59675
            * acinclude.m4 (libtool_VERSION): Bump version.
            * config/abi/pre/gnu.ver (GLIBCXX_3.4.30): Add version and
            export new symbol.
            * configure: Regenerate.
            * include/bits/c++config (__replacement_assert): Remove, declare
            __glibcxx_assert_fail instead.
            * src/c++11/debug.cc (__glibcxx_assert_fail): New function to
            replace __replacement_assert, writing to stderr instead of
            stdout.
            * testsuite/util/testsuite_abi.cc: Update latest version.

[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for gcc-12.