Félix
(replying to Saagar Jha)
@saagar also enjoy the debugger taking 15 minutes to give you a backtrace when you stop your process by hand
2 replies
Saagar Jha
(replying to Félix)
Andy Wingo
(replying to Saagar Jha)
@saagar @fay59 there are solutions to all of these problems https://wingolog.org/archives/2014/03/17/stack-overflow
Jason Molenda
(replying to Félix)
@fay59 @saagar fake news, lldb has an optimized stack walker specifically to handle inf recursion crashes well; I think the most stack frames you can get with std main thread stack size is ~500k frames; lldb can walk that in 5.5 seconds on my m4 max desktop. I mean unlimited stack means really infinite recursion crash ofc, 500k is just the start of what you could do in that env.
Jason Molenda
(replying to Jason Molenda)
@fay59 @saagar (if you have lldb formatting argument variables for each stack frame, that’s gonna take longer of course - lots of memory reads and type formatters. but just looking at “lldb has enumerated all stack frames, and knows the pc values with symbol name and debug info for each”, 5-6 seconds max.)
Félix
(replying to Jason Molenda)
@jasonmolenda @saagar I don’t stack overflow all that much but I recall at least Xcode not being very good at it. maybe I’m unjustly blaming lldb for it
Jason Molenda
(replying to Félix)
@fay59 @saagar to be fair, in the early days I’d written lldb’s register tracking up & down the stack with a recursive algorithm and you can guess what happened next.