5 ms·

Well some aspects are still not clear. If this thing was originally called "segmentation violation", who, when switched to calling it "segmentation fault"? Why

Well some aspects are still not clear. If this thing was originally called "segmentation violation", who, when switched to calling it "segmentation fault"? Why we don't get Segmentation violation (core dumped) when this thing fires? Actually "violation" sounds much clearer to me. It's telling me that the code I'm running does something that was not part of the contract. With "fault"... well, it's someone's fault... probably someone else's fault... who knows what happened... ¯\_(ツ)_/¯ I wouldn't be surprised if it was found out to sound smoother to managerial ears.

monktastic1 6y ago
I've always thought of it like a geological fault, where the two sides are misaligned. But this only fits in the case of misaligned memory access, and not in the more general case of accessing illegal locations. There's also the tennis fault. It's a noun corresponding to the adjective "faulty."
commandlinefan 6y ago
Well, it's less intrusive to change the text than to change the constant.
twic 6y ago
The violation is what the program did. A fault is the handler that runs when the program does something funny. Like with a page fault.
- fsckboy 6y ago
  this is the right answer. I'd tweak it a little, a fault is an interrupt, in this case a hardware interrupt, and the message prints because there is no handler for it (except the default handler that prints the message and halts the program)
tankenmate 6y ago
The reason is that the term "fault" is used is because on the PDP range of computers (the first computers to run Unix) when a instruction (op code) fails it creates a "fault". In the case of accessing a segment that no longer exists, or beyond the length of the segment, etc the instruction that tried to execute but failed is said to have "faulted", or suffered a "fault". So an instruction that faults due to a memory segment issue is called a "segment fault" and one that faults due to a memory page issue is called a "page fault". In the case of segment, the name stuck even though almost all modern CPUs have pages rather than segments.
- tankenmate 6y ago
  This leads on to demand paging, when an instruction tries to access a page that isn't loaded in memory (say for example the page has been "paged out" to swap), then when the instruction faults, it traps into the kernel page handler, and the kernel then determines that yes, the program does own that page and that it is indeed in swap, the kernel will then "page in" that page, i.e. read it from the swap partition and put it in memory. Once the IO has completed and the page is in memory then kernel will reschedule the process and start the execution from the instruction that previously failed. Now that the page is in memory the instruction should execute normally and the process will continue unaware that some of its memory wasn't in RAM but now it is. [EDIT] fixed a typo.
- gumby 6y ago
  "Faulting" was a general term (has it fallen out of favor?) when an instruction didn't execute properly and wasn't specific to DEC machines. Hence page faults, as you note. Neither PDP-7 (original Unix machine) nor PDP-11 had segmented memory. Segmentation was fundamental in the design of Multics, and I suspect the term, if not the signal itself of course, was carried over from there. Memory segmentation was pretty common back then, though far from universal. By the way there were a lot of machines under the "PDP" umbrella with some vary different architectures. PDP-1, -7, and -9 had 18-bit words; PDP-5, -8 and -12 had 12-bit words; the PDP-6, -10 (and renamed from PDP -20) had 18-bit addresses and 36-bit words; and the PDP-11/LSI-11 had 16-bit words (this was later pumped up into the 32-bit VAX line). Unix only really ran on the 11s (and VAXes which BTW gave us the MIPS metric) apart from the one PDP-7 development machines. We used a variety of Ones on all those machines, often homegrown. In those days it was quite common for a company to write their own OS and programming language just for their computers, and for their customers to do the same!
kazinator 6y ago
Actually, the "segmentation" comes from segmented memory management, which was integrated into in AT&T Unix. BSD went with paged virtual memory, and there we get "fault" from "page fault", which is an often correctable situation that is invisible to the application, but is sometimes an access violation. So "segmentation fault" is a weird combination of terms. And of course "core" is from "magnetic core memory" that nobody uses any more. The SIGSEGV constant having come from AT&T Unix propagated into other variants, for the sake of source code compatibility, even though those other variants didn't use segmented memory. I suspect that what happened was that hackers not working with segmented memory at all somehow adopted the "segmentation" term from the AT&T code and documentation, but did not warm up to the "violation" part, sticking with the "fault" terminology of their paged world. The "Segmentation fault" string you see displayed by the shell comes from the strsignal function that maps signals to descriptive strings. I think that originated in BSD Unix. "(core dumped)" is locally generated by the shell if that flag is true in the process status. Bash internationalizes that with gettext. Here it is in Hungarian: po/hr.po:msgid " (core dumped)" po/hr.po-msgstr " (jezgra izbačena)" Estonia gets a cool one: po/eo.po:msgid " (core dumped)" po/eo.po-msgstr "(nekropsio elŝutita)" Trivia: very early Linux kernel versions used 80386 segments for processes.
- rob74 6y ago
  "hr" is Croatian, Hungarian would be "hu" (and no doubt it sounds cool too). And yeah, a "necropsy" (synonym for autopsy) definitely sounds cooler than a "dump"... Otherwise: great summary, almost more interesting (and more compact) than the original blog post!
  - zvrba 6y ago
    > "hr" is Croatian, Hungarian would be "hu" (and no doubt it sounds cool too). And the translation is abysmal: "jezgra" = "core" (of nuclear reactor) or "nucleus" (of an atom); the closest translation for "izbačena" is "ejected". I believe that "core" comes originally from memory technology of the time (https://en.wikipedia.org/wiki/Magnetic-core_memory https://en.wikipedia.org/wiki/Magnetic-core_memory) so it should have been possible to find a more meaningful translation. EDIT: As a native Croatian speaker, I have NEVER used any program in Croatian locale. It is simply unintelligible. Funnily, I find Norwegian (where I live now) translations more approachable.
klodolph 6y ago
The fault can be corrected. The term “violation” seems to imply that it can’t be corrected. Your program only crashes if the segmentation fault isn’t corrected.
- fsckboy 6y ago
  trying to fetch from a memory address outside of your boundaries is a violation of a program's contract with the OS. It can't be "corrected" by the OS, and if you see the message, the program has not included a handler for it. If the program wishes to do something different, it can register a handler, and you won't see the message. If you see the message, there was a violation. If you don't see the message... well, there was still a violation, but it got handled.
  - klodolph 6y ago
    The program has no such contract with the OS. The only contract is that if you access unmapped memory, you get a segmentation fault, and the relevant signal handler is invoked. The default signal handler terminates the program. Depending on the program, a segmentation fault may be routine. That’s why it doesn’t make sense to call it a violation.
    - fsckboy 6y ago
      in systems with unprotected memory, you would actually access the address; even though you accessed it, it is a violation, the result is undefined. When there is protected memory, what catches the violation is outside of your process space. It is a violation; possibly I should not have said OS, it's a hardware violation. I'm not the only one who says this, look at the name, -V edit: actually, though hardware support is required for certain OS features, it's the OS that sets up the segmentation and the fault handlers so ... it is ultimately an OS contract.
      - klodolph 6y ago
        As the article notes, the -V suffix is a historical curiosity. Since no contract is being violated here, the term “violation” does not make sense. This is nothing more than a fault condition, like trying to open a file that does not exist or trying to go to a webpage that does not exist. The contract with the OS is that if you access unmapped memory, your program is sent SIGSEGV. Just like the contract with open() is that it returns -1 if the file is not found.
zoomablemind 6y ago
DEC VMS equivalent of this is 'Access Violation', which as such is a Fault, and manifests itself in logs as the dreadful ACCVIO, though one is always hopeful it's debuggabble, unlike 'AST fault' (where AST stands for Async System Trap, which is not a Fault, but the fault happened while trying to deliver the AST...), meant a lot of head scratching and likely call to support. The worst by far is a 'Machine Check', next thing one hopes to see is the carrots >>> prompt on reset. It's a very nuanced and structured terminology, but does make sense after reading all those hefty and well-written manuals. People like to use those volumes as monitor risers these days, but those are often true standards of quality technical writing. I once was amazed by the clarity, so the VMS doc volume migrated to the shelf in exchange for some old conference proceedings volume of the same heft.

monktastic1 6y ago

I've always thought of it like a geological fault, where the two sides are misaligned. But this only fits in the case of misaligned memory access, and not in the more general case of accessing illegal locations. There's also the tennis fault. It's a noun corresponding to the adjective "faulty."

commandlinefan 6y ago

Well, it's less intrusive to change the text than to change the constant.

twic 6y ago

The violation is what the program did. A fault is the handler that runs when the program does something funny. Like with a page fault.

fsckboy 6y ago
this is the right answer. I'd tweak it a little, a fault is an interrupt, in this case a hardware interrupt, and the message prints because there is no handler for it (except the default handler that prints the message and halts the program)

tankenmate 6y ago

The reason is that the term "fault" is used is because on the PDP range of computers (the first computers to run Unix) when a instruction (op code) fails it creates a "fault". In the case of accessing a segment that no longer exists, or beyond the length of the segment, etc the instruction that tried to execute but failed is said to have "faulted", or suffered a "fault". So an instruction that faults due to a memory segment issue is called a "segment fault" and one that faults due to a memory page issue is called a "page fault". In the case of segment, the name stuck even though almost all modern CPUs have pages rather than segments.

tankenmate 6y ago
This leads on to demand paging, when an instruction tries to access a page that isn't loaded in memory (say for example the page has been "paged out" to swap), then when the instruction faults, it traps into the kernel page handler, and the kernel then determines that yes, the program does own that page and that it is indeed in swap, the kernel will then "page in" that page, i.e. read it from the swap partition and put it in memory. Once the IO has completed and the page is in memory then kernel will reschedule the process and start the execution from the instruction that previously failed. Now that the page is in memory the instruction should execute normally and the process will continue unaware that some of its memory wasn't in RAM but now it is. [EDIT] fixed a typo.
gumby 6y ago
"Faulting" was a general term (has it fallen out of favor?) when an instruction didn't execute properly and wasn't specific to DEC machines. Hence page faults, as you note. Neither PDP-7 (original Unix machine) nor PDP-11 had segmented memory. Segmentation was fundamental in the design of Multics, and I suspect the term, if not the signal itself of course, was carried over from there. Memory segmentation was pretty common back then, though far from universal. By the way there were a lot of machines under the "PDP" umbrella with some vary different architectures. PDP-1, -7, and -9 had 18-bit words; PDP-5, -8 and -12 had 12-bit words; the PDP-6, -10 (and renamed from PDP -20) had 18-bit addresses and 36-bit words; and the PDP-11/LSI-11 had 16-bit words (this was later pumped up into the 32-bit VAX line). Unix only really ran on the 11s (and VAXes which BTW gave us the MIPS metric) apart from the one PDP-7 development machines. We used a variety of Ones on all those machines, often homegrown. In those days it was quite common for a company to write their own OS and programming language just for their computers, and for their customers to do the same!

kazinator 6y ago

Actually, the "segmentation" comes from segmented memory management, which was integrated into in AT&T Unix. BSD went with paged virtual memory, and there we get "fault" from "page fault", which is an often correctable situation that is invisible to the application, but is sometimes an access violation. So "segmentation fault" is a weird combination of terms. And of course "core" is from "magnetic core memory" that nobody uses any more. The SIGSEGV constant having come from AT&T Unix propagated into other variants, for the sake of source code compatibility, even though those other variants didn't use segmented memory. I suspect that what happened was that hackers not working with segmented memory at all somehow adopted the "segmentation" term from the AT&T code and documentation, but did not warm up to the "violation" part, sticking with the "fault" terminology of their paged world. The "Segmentation fault" string you see displayed by the shell comes from the strsignal function that maps signals to descriptive strings. I think that originated in BSD Unix. "(core dumped)" is locally generated by the shell if that flag is true in the process status. Bash internationalizes that with gettext. Here it is in Hungarian: po/hr.po:msgid " (core dumped)" po/hr.po-msgstr " (jezgra izbačena)" Estonia gets a cool one: po/eo.po:msgid " (core dumped)" po/eo.po-msgstr "(nekropsio elŝutita)" Trivia: very early Linux kernel versions used 80386 segments for processes.

rob74 6y ago
"hr" is Croatian, Hungarian would be "hu" (and no doubt it sounds cool too). And yeah, a "necropsy" (synonym for autopsy) definitely sounds cooler than a "dump"... Otherwise: great summary, almost more interesting (and more compact) than the original blog post!
- zvrba 6y ago
  > "hr" is Croatian, Hungarian would be "hu" (and no doubt it sounds cool too). And the translation is abysmal: "jezgra" = "core" (of nuclear reactor) or "nucleus" (of an atom); the closest translation for "izbačena" is "ejected". I believe that "core" comes originally from memory technology of the time (https://en.wikipedia.org/wiki/Magnetic-core_memory https://en.wikipedia.org/wiki/Magnetic-core_memory) so it should have been possible to find a more meaningful translation. EDIT: As a native Croatian speaker, I have NEVER used any program in Croatian locale. It is simply unintelligible. Funnily, I find Norwegian (where I live now) translations more approachable.

klodolph 6y ago

The fault can be corrected. The term “violation” seems to imply that it can’t be corrected. Your program only crashes if the segmentation fault isn’t corrected.

fsckboy 6y ago
trying to fetch from a memory address outside of your boundaries is a violation of a program's contract with the OS. It can't be "corrected" by the OS, and if you see the message, the program has not included a handler for it. If the program wishes to do something different, it can register a handler, and you won't see the message. If you see the message, there was a violation. If you don't see the message... well, there was still a violation, but it got handled.
- klodolph 6y ago
  The program has no such contract with the OS. The only contract is that if you access unmapped memory, you get a segmentation fault, and the relevant signal handler is invoked. The default signal handler terminates the program. Depending on the program, a segmentation fault may be routine. That’s why it doesn’t make sense to call it a violation.
  - fsckboy 6y ago
    in systems with unprotected memory, you would actually access the address; even though you accessed it, it is a violation, the result is undefined. When there is protected memory, what catches the violation is outside of your process space. It is a violation; possibly I should not have said OS, it's a hardware violation. I'm not the only one who says this, look at the name, -V edit: actually, though hardware support is required for certain OS features, it's the OS that sets up the segmentation and the fault handlers so ... it is ultimately an OS contract.
    - klodolph 6y ago
      As the article notes, the -V suffix is a historical curiosity. Since no contract is being violated here, the term “violation” does not make sense. This is nothing more than a fault condition, like trying to open a file that does not exist or trying to go to a webpage that does not exist. The contract with the OS is that if you access unmapped memory, your program is sent SIGSEGV. Just like the contract with open() is that it returns -1 if the file is not found.

zoomablemind 6y ago

DEC VMS equivalent of this is 'Access Violation', which as such is a Fault, and manifests itself in logs as the dreadful ACCVIO, though one is always hopeful it's debuggabble, unlike 'AST fault' (where AST stands for Async System Trap, which is not a Fault, but the fault happened while trying to deliver the AST...), meant a lot of head scratching and likely call to support. The worst by far is a 'Machine Check', next thing one hopes to see is the carrots >>> prompt on reset. It's a very nuanced and structured terminology, but does make sense after reading all those hefty and well-written manuals. People like to use those volumes as monitor risers these days, but those are often true standards of quality technical writing. I once was amazed by the clarity, so the VMS doc volume migrated to the shelf in exchange for some old conference proceedings volume of the same heft.