First things first, I know that accessing data after it’s been free’ed is undefined behavior in C.
But undefined behavior is still a behavior, which varies at its indefiniteness according to the real situation of an access. At the end of the day hardware stays hardware, not a magical black-box. So I am interested only in answers from this perspective.
Case 1: access(mem)
to the memory is made much later after free(mem)
was called, for example 10 minutes later; huge memory usage occurred between this two calls in the program itself.
Case 2: access(mem)
to the memory is made much later after free(mem)
was called, for example 90 minutes later; memory was not used by a program extensively, but was used such by other OS’s processes, for example 3D-video rendering.
Case 3: access(mem)
to the memory is made much later after free(mem)
was called, for example 120 minutes later; both, nor program nor OS had been taking memory during this period.
Case 4: access(mem)
to the memory is made just right after free(mem)
was called. for example:
/* decimal to string */
char *dtos(int num)
{
char *str = (char*)malloc(16 * sizeof(char));
sprintf(str, "%d", num);
free(str);
return str;
}
int main(int argc, char ** argv)
{
/* call */
for(int i = 0; i <= 999999 ; i++)
{
printf("%sn", dtos(i));
}
return 0;
}
Case 5: same as case 4, but this time CPU have a full payload, both by OS and a program itself.
There can be more special cases. These are just some, in which I am interested mostly, fill free to add up.
Here is my question:
—— How much actual indefiniteness each case have, when comparing each one of them with each other?
I ask this mostly because there is such OS/hardware thing, at least when running C-written programs, that after freeing memory it is actually not being returned back into the OS memory pull for quite some time. And it seems that this time varies largely, at least on my machine.
To make my point more grounded, I want to make a request: can anyone provide me with evidence that this simple code from cases 4-5 can actually show an undefined behavior at any circumstances? On any machine controlled by any OS inside any program.
Because when I try to implement undefined behavior in this case, I get only defined one.
1
Can anyone provide me with evidence that this simple code from cases 4-5 can actually show an undefined behavior at any circumstances? On any machine controlled by any OS inside any program.
Exhibit A. At the time of this writing, instead of printing lines 0-99 it doesn’t even print 99 newlines. Because it is undefined behavior its behavior may change at any time.
The behavior depends on the malloc/free implementation, your compiler, compiler flags, the particulars of the memory layout when the program starts, how the program perturbs its heap memory by allocating and freeing blocks of memory, your operating system, and hardware. If you’re curious to know more, look at how your C code is translated into assembly code.
I don’t believe the CPU load matters at all, nor does the time between your allocation and freeing matters. In a modern operating system with memory protection, what other processes are doing shouldn’t perturb another process’s memory. But, again, this depends on the OS and malloc/free implementation.
Some operating systems will deliberately randomize memory. This makes memory-based undefined behavior even more unpredictable, which is the goal; it makes attacks which rely on undefined behavior more difficult.
1