Avoid allocating memory in sig segv handlers. I worked at a company once that had written their own handlers that tried to print a stack trace. I was fortunate enough to find a machine in a test environment that segfaulted while allocating memory. The handler then caused a deadlock in a call to malloc (through new). I ended up rewriting the handler to fix two sources of memory allocation. First I preallocate enough space to do string manipulations in the handler. Second I made eager calls to a few libc functions used in the handler to avoid memory allocation from lazy binding from ld.so.

[–] fmixolydian@programming.dev 4 points 2 weeks ago

actually, in the production version i check if the sigsegv handler already got triggered at the start of the handler (to avoid a nested sigsegv) and just exit without any fancy error printing if that happened

i left it out of this meme bc it would've cluttered up the code snippet.

[–] Scoopta@programming.dev 6 points 2 weeks ago (1 children)

🤔 that reminds me of the brainfuck debugger I wrote. Good fun

[–] fmixolydian@programming.dev 6 points 2 weeks ago (1 children)

cool! i once tried to write a brainfuck jit compiler (that just appends raw bytes to a buffer and runs it as x86 machine code if it hits a branching instruction like [ / ])

[–] Scoopta@programming.dev 3 points 2 weeks ago (1 children)

That's cool. Mine is just an interpreter for execution but it has breakpoints, watchpoints, and save states. I've thought about trying to do some form of JIT or at least AOT but I haven't yet made an attempt. Besides for a debugger that's counter productive.

[–] fmixolydian@programming.dev 3 points 2 weeks ago

save states are something i've seen very few debugger-enabled interpreters have. on paper, it would probably be as easy as storing the state of the interpreter in a format like a core dump (only requires the ability of reflection)

[–] jenesaisquoi@feddit.org 1 points 1 week ago

Time to reimplement it in Rust