Félix

(replying to Saagar Jha)

@saagar enjoy accidental infinite recursion eating all of your RAM

2 replies →
2 replies

methoxyf

(replying to Félix)

@fay59 @saagar is this a post about firefox


Saagar Jha

(replying to Félix)
@fay59 If you’ve got a bug in your loop the memory’s got to come from somewhere be it recursive or not

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 →
2 replies

Saagar Jha

(replying to Félix)
@fay59 This sounds like something a debugger should know how to solve

Andy Wingo

(replying to Saagar Jha)

@saagar @fay59 there are solutions to all of these problems wingolog.org/archives/2014/03/


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.