As programmer I love that warm fuzzy feeling when I come to the end of long series of fixes and enhancements and you go to bed content that you can cut a release in the morning.
Next day, after a good restful nights sleep, just before you cut that release you test something not in the test suite and BOOM! A pit of despair opens wide as you stare in shock and horror at the screen -- #SIGSEGV
#Java crash bug on #macOS 14.4 is in my wheelhouse (resilience.)
Root cause seems to be they changed what signal the OS sends to a process when certain kind of mem access is attempted
In the case in question the kernel previously delivered a SIGBUS or #SIGSEGV
If you've ever heard of a program crashing via a so-called #segfault it means the process received a #SEGV sig, it did NOT handle it explicitly (& robustly) & the default behavior was to crash
now they SIGKILL it! *cannot* be handled!
[1] 63902 segmentation fault ./blog
Have you ever wondered why segmentation faults are abbreviated "SIGSEGV" in Linux?
Where does the "V" come from? Shouldn't it be "SIGSEGF" instead? ("F" for Fault - not "Vault" π)
David Wragg and Marek Majkowski have a bit of UNIX history for you!
"Why is there a "V" in SIGSEGV Segmentation Fault?" -
https://blog.cloudflare.com/why-is-there-a-v-in-sigsegv-segmentation-fault
#linux #segmentationFault #sigsegv #unix #history #c #programming #developer #software #softwareDevelopment #embedded
My program received a SIGSEGV signal and crashed with "Segmentation Fault" message. Where does the "V" come from? Did I read it wrong? Was there a "Segmentation *V*ault?"? Or did Linux authors make a mistake? Shouldn't the signal be named SIGSEGF?
SirWumpus πΎπ
Michael Daum
synlogic
Sigma
ZERO GmbH
γ³γγ³γγΌγθ²―ιγ―γγγΎγγ