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 Comments
BlazeDaley@lemmy.world · 18 pts · 349d
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.
fmixolydian@programming.dev · 4 pts · 349d
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 · 7 pts · 349d
🤔 that reminds me of the brainfuck debugger I wrote. Good fun
fmixolydian@programming.dev · 6 pts · 349d
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 pts · 349d
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 pts · 349d
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 pts · 346d
Time to reimplement it in Rust