Re: how to redirect glibc's dump output ? (stack 'backtrace', etc)

[Ãngel GonzÃlez <keisial at gmail dot com>]

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.