[PATCH] stack: Add new '-n MAXFRAMES' option. Resolve addresses after unwind.

Mark Wielaard mjw at redhat.com
Mon Jan 6 14:52:08 UTC 2014


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
                             demangle names
  -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
about.

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

Cheers,

Mark




More information about the elfutils-devel mailing list