This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: how to redirect glibc's dump output ? (stack 'backtrace', etc)
- From: Ãngel GonzÃlez <keisial at gmail dot com>
- To: "Linda A. Walsh" <gnu at tlinx dot org>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, libc-help at sourceware dot org
- Date: Tue, 22 Jul 2014 23:13:24 +0200
- Subject: Re: how to redirect glibc's dump output ? (stack 'backtrace', etc)
- Authentication-results: sourceware.org; auth=none
- References: <53C9DE9B dot 5090000 at tlinx dot org> <53CA2C96 dot 6020500 at tlinx dot org> <CALoOobPY05h0ZiizXYoqEzrBBJVP4HmX5mjw-MpL4ysTXCyzqw at mail dot gmail dot com> <53CB0FA1 dot 3070506 at tlinx dot org>
Linda A. Walsh wrote:
Paul Pluzhnikov wrote:
*mumble about silly gmail blocking ml posts by his own employees*
Had to go to https://sourceware.org/ml/libc-help/2014-07/msg00008.html
for the snippet:
The code you are interested in is in sysdeps/posix/libc_fatal.c:
65 /* Abort with an error message. */
66 void
67 __libc_message (int do_abort, const char *fmt, ...)
68 {
...
78 /* Open a descriptor for /dev/tty unless the user explicitly
79 requests errors on standard error. */
80 const char *on_2 = __libc_secure_getenv ("LIBC_FATAL_STDERR_");
81 if (on_2 == NULL || *on_2 == '\0')
82 fd = open_not_cancel_2 (_PATH_TTY, O_RDWR | O_NOCTTY | O_NDELAY);
So, if you want to have libc messages go to stderr, set the
LIBC_FATAL_STDERR_ environment variable to non-empty.
So, if you want to have libc messages go to stderr, set the
LIBC_FATAL_STDERR_ environment variable to non-empty.
----
Usually if one wants debug output, one sets takes extra steps.
It seems user-unfriendly (maybe developer friendly, but there
are alot more users than developers) to force on this type
of output by default.
Even the stack backtrace echoed to the screen is useless for
most purposes
-- no one is willing or able to work from such useless output
Useless to you does not mean useless to others.
In fact it *is* often quite useful to me.
(...)
But to those developing any other program, they've always asked me
to send a stack trace from gdb. I've yet to have anyone ask for
a memory map along with a backtrace.
I.e. wouldn't it be more user friendly to take a note from the kernel
and do fault-dumps to a file rather than the user's screen? (I do
remember
older machines (usually mainframes) where it was standard practice to
send
fault-dump information to the screen (in place of 'core' files)...
so why is it dumped to the screen anyway?
----
Would you think all users would want all programs to dump
full fault-related debug info to the screen on any program error?
When I see raw errors coming to a screen -- I think "unhandled errors" --
beta or development code.
But too often I am seeing such output by default even in released
materials.
It seems that having libraries dump errors, by default, to the user's
screen
rather than a log file is becoming an unsightly new trend.
Do you really think it's needed for all programs to start dumping
errors to the screen?
I do find useful that the error is dumped to the screen. I am sure that
if it would
go to eg. core.txt many of those would go unnoticed (even the developer may
not be expecting a segfault, and the program could be segfaulting at a
closing
procedure). And yes, I have seen it from "released" programs, where I a
core
wouldn't have been expected (nor I was going to start debugging it), but
at least
the message provided an explanation on why it "disappeared", and found
it useful.
However, you have a point that maybe jumping just the stacktrace would
be enough.