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