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
