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

[Paul Pluzhnikov <ppluzhnikov at gmail dot com>]

On Tue, Jul 22, 2014 at 2:13 PM, Ãngel GonzÃlez <keisial@gmail.com> wrote:
> Linda A. Walsh wrote:
>>
>> Paul Pluzhnikov wrote:
>
> *mumble about silly gmail blocking ml posts by his own employees*

Sorry about that. There are reasons why this is happening, and there
is nothing we (small subset of Googlers who post to OSS mailing lists)
can do.

I've switched to personal e-mail for this message.

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

I've been told that there are also security reasons for why messages
don't go to STDERR by default: if an external user could run some
program on your machine (e.g. via cgi-bin) and observe an error
report, he then have way more info than you want him to have.

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


The (numeric) stacktrace is useless without the memory map if you have
relocatable objects (shared libraries or a PIE executable) that took
part in the crash.



-- 
Paul Pluzhnikov