This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: [PATCH] stack: Add new '-n MAXFRAMES' option. Resolve addresses after unwind.
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Fri, 03 Jan 2014 22:30:11 +0100
- Subject: Re: [PATCH] stack: Add new '-n MAXFRAMES' option. Resolve addresses after unwind.
On Thu, 02 Jan 2014 23:52:05 +0100, Mark Wielaard wrote:
> On Thu, Jan 02, 2014 at 08:45:47PM +0100, Jan Kratochvil wrote:
> > On Mon, 23 Dec 2013 11:21:19 +0100, Mark Wielaard wrote:
> > > Limit the number of frames printed per thread (defaults to 64)
> >
> > The new option is sure OK but any non-infinite default is not right:
>
> I don't agree with the infinite default, there should be a limit by
> default, but I agree with everything else.
I have realized you are right there is needed:
[patch] Detect infinite backtraces
https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-January/003706.html
But otherwise I do not see any justification for any limit.
> > * Normal applications have deeper stack than 64. When I broke into my
> > GTK running app it has 103 frames: http://people.redhat.com/jkratoch/app.bt
>
> Yeah, 64 is silly small. Used 2048 now.
This case is pretty normal debugging issue:
$ echo 'f(){f();}main(){f();}'|gcc -x c -;(ulimit -c unlimited;./a.out);./src/stack -e ./a.out --core ./core.*|tail
[...]
#62 0x00000000004004fe float
#63 0x00000000004004fe float
$ _
Even 2048 is not enough. Why should I have to use:
$ ./src/stack -n 999999 -e ./a.out --core ./core.*|tail
[...]
#523820 0x00000000004004fe float
#523821 0x00000000004004fe float
#523822 0x000000000040050e main
#523823 0x000000305f821d65 __libc_start_main
#523824 0x0000000000400429 _start
$ _
This is a perfectly valid backtrace, I do not see why I should specify an
extra option to get valid backtrace.
I see more why to specify an extra option if I have some need for real-time
processes unwinding.
I hope you at least agree the limit should be suppressed for core files.
This does not mean I agree with the default limit for live processes, though.
> The backtrace could just be bad causing us to endlessly unwind.
It no longer can.
> @@ -512,7 +525,7 @@ main (int argc, char **argv)
> { NULL, '1', NULL, 0,
> N_("Show the backtrace of only one thread"), 0 },
> { NULL, 'n', "MAXFRAMES", 0,
> - N_("Show at most MAXFRAMES per thread (default 64)"), 0 },
> + N_("Show at most MAXFRAMES per thread (default 2048, use 0 for unlimited)"), 0 },
> { "list-modules", 'l', NULL, 0,
> N_("Show module memory map with build-id, elf and debug files detected"), 0 },
> { NULL, 0, NULL, 0, NULL, 0 }
Fine with the patch except still for the default limit.
Thanks,
Jan