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

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

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:

 * 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

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

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

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

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



Regards,
Jan