1

I use mmap() to allocate 4096 length of memory space from /dev/zero, and I find that I can still access the memory out of this space (e.g. start_pt is the pointer that points to the space and I can print the value of *start_pt+8192 without any segmentation fault). And the values stored in the out-of-bound region seem to be random.

Does anyone have any idea on what those values are and why I can access them?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Longstreet
  • 11
  • 1
  • 5
    Accessing out of bounds memory is undefined behavior and anything can happen. Don't do it, or try to reason about it. – Shawn Mar 02 '19 at 02:29
  • On Linux `cat /proc/1234/maps` and you'll see. Replace 1234 with your program's PID. Add a sleep or something so it doesn't exit. – Zan Lynx Mar 02 '19 at 03:09
  • Are you referring to `*start_pt + 8192` or `*(start_pt + 8192)`? The former is valid; the latter is not. – Jonathan Leffler Mar 02 '19 at 03:27
  • @Shawn except when you're looking for security vulnerabilities. Then the C programming language and undefined behavior are your best friends. – Roland Illig Mar 02 '19 at 03:33
  • And as always: post your actual code so that we can try the exact same experiments as you. – Roland Illig Mar 02 '19 at 03:35
  • [This Q+A](https://stackoverflow.com/questions/24819212/equivalent-of-dwallocationgranularity-in-linux) is relevant. It doesn't jive that well with what you see, but of course we don't know what OS you use and you can't really know whether it happens to be adjacent to another allocation by accident. – Hans Passant Mar 02 '19 at 23:47
  • @Shawn: It is not true that anything can happen, and it is absurd to tell people not to reason about it. A crucial part of software engineering is analyzing crash dumps and reasoning about what happened. The consequences of the C standard not defining the behavior are solely limited to the C standard. The specifications and behaviors of the operating system, linker, and various subsystems and libraries involved still exist and are relevant. Beyond what C tells us, we can analyze and reason about how memory is organized in a process, what the operating system must be doing, and more. – Eric Postpischil Mar 03 '19 at 04:01

2 Answers2

1

At some time, something else in your process requested memory from the operating system. It is not generally possible to say what without examining your specific process. Candidates include:

  • When your program was started, the loader set up memory for your code, constant data, stack, and more. Also, the process that created the new process for your program (possibly the command-line shell) may have had some things in memory that are retained through the process of executing a new program. (For example, I am not sure whether command-line arguments are directly inherited from the parent or are obtained by the start-up code receiving them through some interprocess communication.)
  • While your program’s start-up code was running (the code that is started by the loader and that sets up the C environment before calling main), it may have requested memory for various purposes (preparing file buffers, initializing a pool of memory for malloc, and other things), including for its own computations.
  • If you called any routines prior to mmap, they may have requested memory. For example, buffers may be created when you open files, printf prepares some workspace for the formatting operations it needs to perform, and malloc needs additional memory for its own record keeping besides it returns to you.

Essentially, there are various things going on in memory other than just those you observe in plain C code.

Eric Postpischil
  • 195,579
  • 13
  • 168
  • 312
0

Unused memory is not mapped to the process address space. If you can access the memory, that means something has mapped the memory using mmap (or equivalent).If the memory is unused you could not access it.

user3344003
  • 20,574
  • 3
  • 26
  • 62