#segmentationfault — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #segmentationfault, aggregated by home.social.
-
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
-
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
-
Aha, #gdb uses #c syntax, not #assembly syntax.
print *(((long long *) $rsp) + 5)
works better.
But I still don't understand what caused that #SegmentationFault -
I generated a SIGSEGV for my #assembly program by typing
print (long long) 40($rsp)
in #gdbOk, I know I expected a #SegmentationFault near that point, and my code contains
mov 40(%rsp), %rax
but the SIGSEGV should be raised a few instructions after this movq, when dereferencing a derivative of this 40(%rsp) and at both points (this gdb print and the normal SIGSEGV point) the stack pointer looks ok.