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.
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.
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 [ / ])
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.
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)
7 replies
I’m going to whoosh the joke for a moment.
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.
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.
🤔 that reminds me of the brainfuck debugger I wrote. Good fun
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
[/])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.
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)
Time to reimplement it in Rust