This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

>  * Applications with deeper stack just take longer to unwind, that's normal.
>    If there is a special use case where target application should not be
>    stopped for a noticeable time then the '-n' option is perfect.
>    But this is not the default case.

It shouldn't be unlimited, but a large limit is fine.

>  * Such limit makes IMO sense only for runaway apps with "infinite" backtrace.
>    Such applications have probably already crashed (I am backtracing a core)
>    or the application is no longer responsive.  In such case:
>     * It does not matter if eu-stack takes slightly longer or not.
>     * I really need the full unwind as only the top of stack can disclose
>       why the infinite deadlock occured.
>    Primarily I still miss a use case for this default of non-infinite limit.

The backtrace could just be bad causing us to endlessly unwind.
It isn't reasonable to show infinite backtraces, but it should indeed
be possible to show a finite backtrace however large it is.

>  * It does not warn that it stopped the unwind due to such a limit:
>    #62 0x000000000040054e bt
>    #63 0x000000000040054e bt
>    $ _ (rc = 0)

Right, it returns 1 now like any other non-fatal error that caused the
code to possibly not show the whole stack.

>  * One cannot easily make the unwind unlimited:
>    $ stack -p $p -n 0
>    stack: -n MAXFRAMES should be 1 or higher.
>    Try `stack --help' or `stack --usage' for more information.
>    $ ./src/stack -p $p -n -1
>    Segmentation fault
>    Program received signal SIGSEGV, Segmentation fault.
>    0x0000000000402974 in main (argc=5, argv=0x7fffffffd978) at stack.c:530
>    528    struct frames *frames = malloc (sizeof (struct frames)
>    529                                    + sizeof (struct frame) * maxframes);
>    530 -> frames->frames = 0;

Clearly there was a NULL check missing. Also added support for -n 0 to do
make it unlimited (it will still hit a memory error if there really are
infinite frames).

Thanks,

Mark

Attachment: 0001-stack-Allow-n-0-for-unlimited-frames.-Make-default-2.patch
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]