2

I'm trying to understand the following paradox:

I'm running a program in a 64-bit Linux. So the program runs in 64-bit mode (submode of AMD64's long mode), right? But this mode has no segmentation, it only has paging. Then why the code below generates a segmentation fault?

int main() {
  int* ptr = (int*)0xABCDABCDABCD;
  *ptr = 10;
  return 0;
}
matheuscscp
  • 827
  • 7
  • 23
  • this address is probably located in a page that is marked readonly. so trying to change anything in that page, via: *ptr = 10; will rise a fault, typically a seg fault. – user3629249 Nov 01 '14 at 02:43

1 Answers1

3

It's called a segmentation fault irrespective of the underlying paging technology. It means (usually) you've tried to access memory outside the bounds of waht you're permitted (your segment), It could have been called block, chunk, section, memlim, xyzzy, plugh, or any term really.

It's much the she same as when you get a null pointer exception in Java despite the fact there are no "pointers" in the language :-)

The signal indicating it in UNIX (SIGSEGV) was around long before Intel gave us the segmented architecture of the original x86 chips.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • So this is a page fault? But a page fault leads the OS to load the page to the physical memory... – matheuscscp Oct 31 '14 at 20:50
  • @matheuscscp, again, paging is the underlying technology and may not even be there (it probably _is_ for latter x86 chips though). And the OS may well page fault and try to bring in the page then, when it discovers you have _no_ such page to load for your process address space, it may segfault then. E.g., OS gives you 4M address space and you try to write to something above that: OS page faults, discovers it's beyond your range and stops you before anything (really) bad happens. Or you write to OS memory above the 3G line in you virtual address space and it's write-protected. And so on ... – paxdiablo Oct 31 '14 at 20:55
  • Okay, but how exactly the system knows that the virtual address 0xABCDABCDABCD is outside the bounds, since every process has its own full 64 bit virtual addressing space? – matheuscscp Oct 31 '14 at 20:59
  • Is it because there is no page entry in the page table for the virtual address 0xABCDABCDABCD? – matheuscscp Oct 31 '14 at 21:04
  • @matheuscscp: more than likely, yes. Every process may have the full range of _virtual_ addresses but that doesn't mean they've mapped _physical_ memory behind every single one of those addresses. See for example http://stackoverflow.com/questions/9006634/mapping-of-virtual-address-to-physical-address. – paxdiablo Oct 31 '14 at 21:06