This is the mail archive of the
mailing list for the elfutils project.
Re: [PATCH] stack: Add new '-n MAXFRAMES' option. Resolve addresses after unwind.
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Mon, 06 Jan 2014 15:52:08 +0100
- Subject: Re: [PATCH] stack: Add new '-n MAXFRAMES' option. Resolve addresses after unwind.
On Mon, 2014-01-06 at 12:57 +0000, Pedro Alves wrote:
> On 01/03/2014 10:23 PM, Mark Wielaard wrote:
> > But I don't agree that there shouldn't be any limit in eu-stack by default.
> > Generating hunderd thousands lines of output is not a good default.
> My 0.02€:
> Are you thinking of users typing in the terminal?
Yes, or scripts that invoke the command and process the output. In
general I feel that we shouldn't flood the user with hundred thousands
lines of output unless they explicitly ask for it. The default output
should be useful as is. Of course they can tweak if however they want.
eu-stack has many options to tailor the output to your need.
Output selection options:
-1 Show the backtrace of only one thread
-a, --activation Additionally show frame activation
-b, --build-id Show module build-id, load address and pc offset
-l, --list-modules Show module memory map with build-id, elf and
debug files detected
-m, --module Additionally show module file information
-n MAXFRAMES Show at most MAXFRAMES per thread (default 2048,
use 0 for unlimited)
-q, --quiet Do not resolve address to function symbol name
-r, --raw Show raw function symbol names, do not try to
-s, --source Additionally show source file information
-v, --verbose Show all additional information (activation,
module and source)
> IMO if the user asks for the backtrace, she should get it.
Sure you can also use eu-stack to get one specific backtrace (-1 -n 0).
But by default it provides [n=2048] frames for all threads of a process.
A bit too much for my liking, but a reasonable compromise for the
default value IMHO. It should give you useful output by default without
completely drowning you in exceptional cases with irrelevant frames.
> gdb's backtrace limit is
> also unlimited by default. Paging, a-la git, gdb, (or external), is
> better to handle long output IMO, as the user can then decide to cancel
> at any time (q, ctrl-c, etc.), but failing that, applying a default
> limit only when stdin is a tty would still be better, IMO.
I think that is a little too fancy, but yeah, that could have been
another choice. But I do think even without a tty one should be explicit
about what one wants. If only so that the consequences of processing a
couple of million lines of output, if using -n 0, have been thought
> That would keep
> compatibility with existing programmatic uses (scripts, etc.), which
> now will possibly start getting truncated backtraces, unless they're
> adjusted to use "-n" (and I assume they'll need to take care to not
> use it with older elfutils that doesn't know about "-n".)
All released versions support -n 0, so if someone really wants to be
flooded with output they can do that unconditionally :)
BTW. What does seem useful is a new (default) option --tail, that would
only show the last n frames of each thread's backtrace. Because that
seems to be what people who want "unlimited" frames by default seem to
really want. "Where did this infinite backtrace start from?" If
detection of infinite backtraces can be done reliably.