[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jonathan Wakely --- Fixed for gcc-12.
[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675 --- Comment #10 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a54ce8865a885bca5ab9c4aa6ec725cd13c09901 commit r12-5193-ga54ce8865a885bca5ab9c4aa6ec725cd13c09901 Author: Jonathan Wakely Date: Wed Nov 3 16:06:29 2021 + 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 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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||patch --- Comment #9 from Jonathan Wakely --- 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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675 --- Comment #8 from Jonathan Wakely --- (In reply to Jay Feldblum from comment #7) > The caveat, not to pollute `bits/c++config` with `#include 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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675 Jay Feldblum changed: What|Removed |Added CC||yfeldblum at gmail dot com --- Comment #7 from Jay Feldblum --- Created attachment 51622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51622=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 `. 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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675
Jan Kratochvil changed:
What|Removed |Added
Version|4.8.2 |9.2.1
--- Comment #6 from Jan Kratochvil ---
libstdc++-devel-9.2.1-1.fc31.x86_64
cat >gcc59675b.C <
int main() { std::shared_ptr 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, , >::element_type& std::__shared_ptr_access<_Tp,
_Lp, , >::operator*() const [with _Tp = int;
__gnu_cxx::_Lock_policy _Lp = __gnu_cxx::_S_atomic; bool = false;
bool = false; std::__shared_ptr_access<_Tp, _Lp, ,
>::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)
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)
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)
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, ^
[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)
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)
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.
