[HN Gopher] Having Fun with Signal Handlers ___________________________________________________________________ Having Fun with Signal Handlers Author : edward Score : 15 points Date : 2020-11-22 08:26 UTC (14 hours ago) (HTM) web link (www.giovannimascellani.eu) (TXT) w3m dump (www.giovannimascellani.eu) | [deleted] | zX41ZdbW wrote: | It can be done easier with sigsetjmp, siglongjmp. | zX41ZdbW wrote: | Also you can check it with the `write` syscall (just write a | byte pointed by address to /dev/null). If a pointer is invalid, | it will return setting errno to EFAULT. | jmgao wrote: | And if you're on Linux, you can read the memory directly with | process_vm_readv. | jez wrote: | Another place where SIGSEGV handlers are common: showing | backtraces and "how to report a bug" messages. For example here's | where it's done in the Ruby VM: | | https://github.com/ruby/ruby/blob/5445e0435260b449decf2ac16f... | | They have a bug report handler that shows a bunch of helpful | information: | | - the Ruby-level backtrace | | - the stack of VM control frames (an internal data structure) | | - the C-level backtrace (which Ruby implementation functions were | running) | | - which files had been required and loaded into memory | | - what segments of memory are mapped and what aren't | | Another thing: it's designed to work even when the program ran | out of memory! | | The sigaltstack(2) system call lets you preallocate a buffer that | the kernel knows how to set up before it runs your SIGSEGV | handler, so you can have just enough stack memory to compute and | print all this debug info before the program ultimately crashes. | Here's that code, again in the Ruby VM: | | https://github.com/ruby/ruby/blob/5445e0435260b449decf2ac16f... ___________________________________________________________________ (page generated 2020-11-22 23:00 UTC)