1

I think I understand the idea of a segmentation fault. I get confused when trying to figure out how a dangling pointer and segmentation fault are related. Does it change at all in C versus C++?

2

@Rip, you absolutely did say so. But a lot of our readership will not realize that a lot of other libraries like stdio and hsearch will break it for you even if your own code avoids malloc totally.

I have successfully used sbrk (+) and then sbrk (-), but I saved the initial space (size_t Orig = sbrk (0); tells you that) and checked nobody else had extended above me before I freed it again.

3

@Paul

Malloc or mmap never go hand in hand with sbrk (). That is why I initially mentioned not to mix them in same program, which is what you are confirming.
The reason is sbrk () is just a raw and primitive way of memory allocation, and responsibility of management of allocated space rests on programmer.

4

I’ll say I was lucky.

I was expecting garbage or a crash. I was running in debug, I know buffers are allocated with guard bands to detect overwrites, maybe the debug code nulls the stack space for a function when it increments the stack pointer or something like that.

If I had written that routine, I would
A, allocated a buffer and returned it to the caller
B, if I had to use a fixed buffer, I always would use snprintf and pass the buffer size -1 and push a 0 in the last character of the buffer.

I was always a belt and suspenders kind of guy ( and maybe a few staples, duct tape, whatever seemed needed… )

Oh, to be using a real programming language again…
Thanks for the education and the memories.

5

OK, you were lucky. Whatever ended up on top of Buf had a null byte on the first 8 bits, so you got an empty string and did not crash.

Now try static char Buf [80]; which puts Buf in base segment, not on stack, so it will not be messed by stack accesses.

You will get two numbers printed, either -787 twice or 999999 twice. But it is indeterminate which happens.

6

"Also try this, and then explain the result.

printf (“Got %s and then %sn”, Format (99999), Format (-787)); "

I got ( windows 7, VS 2008 ( would love to move to linux ) )

"Got and then "

Format executed, laid down it’s stack ( for argument -787 ), then the stack got popped as format returned ( caller/callee division unclear )
Buff, somewhere in that memory section is returned
Format executed again ( argument 99999 ), laid down it’s stack
Buff, somewhere in that memory section is returned, different bits there. Items popped again as stack is wound down.
printf executed, lays it’s own stack down, buf is somewhere in there, whatever automatic or argument items are there ( and printf executes the varargs stuff to unpack the variable argument items, including two references to buf, which are now within the stack for printf./varargs ( and whatever other functions might execute ), and again, different bits get written there, depending on what items end up there ( and if there is any stack randomizing going on to thwart hacking, even more mayhem ).

7

The classical hanging pointer looks like this. No malloc in sight.

#define PAD 4

static char *Format (int number)

{
char Pad[PAD];
char Buf[80];

??? sprintf (Buf, “%12d”, number);
??? return (Buf);
}

int main (int argc, char** argv)

{
char *p = Format (12345678);

… more code
}

OK. main has a pointer to Buf, and Buf contains “??? 12345678”. Fine.

But the very next call (or evaluation of a complex expression) will use the stack and will write different stuff where Buf used to be. If PAD was 4000 instead of 4, you might get away with a deeper call stack before it got hit, but it is always vulnerable.

Also try this, and then explain the result.

printf (“Got %s and then %sn”, Format (99999), Format (-787));

Incidentally, declaring Buf as static char fixes the hanging pointer issue, but does NOT fix the printf problem.

And I did develop an application that barely fitted on the system (8MB Perq). We used to start by mallocing more memory than could ever exist, and counting down in 32KB blocks until we got a non-null answer. Then we freed it so we have a pre-grown free list that no other process could steal.

8

To be “Pedant-ic” ( bet you have heard that a million times before ), having no memory available without a leak could happen if you simply allocate all of the memory available.

On dangling pointer, how about

char* blah = strdup( “help help0” );
char* bleh = strdup( “no no0” );
bleh = blah;

9

@Ripunjay,

Normally the stack grows downwards from -4 or -8 (the first word address less than zero), and the data/code/heap space grows up from zero. I normally picture that as growing away from each other. In any case, the heap cannot wrap over MAXINT to become negative, and the stack cannot wrap past -MAXINT and become positive (because address registers are treated as unsigned ints). So I do not believe there is any interaction between stack and sbrk space.

OK, Linux says sbrk() is a compiler library, but still puts it in man -s2 with all the system calls. In “proper” Unix, it is a system call being directly implemented in kernel.

It is almost impossible to use sbrk(-ve) to shrink memory.

suppose you:

#define SZ_SRK 32768
sbrk (SZ_BRK);
fprintf (stderr, “Extended memory by %d bytesn”, SZ_BRK);
sbrk (-SZ_BRK);
fprintf (stderr, “Shrank memory by %d bytesn”, SZ_BRK);

First sbrk works.
Then fprintf is called. It sees stderr does not yet have a buffer, so it mallocs one.
Malloc does not have a free list, so it calls sbrk() to get space for one, and creates a free list and gives a void* to stderr->buffer.
The second sbrk then gives back to the system: part of the free list, and part of the stderr buffer, and part of your original sbrk space.
The next call you make to stdio or malloc or free or any other library function that uses malloc or free, will seg viol.

In fact, any memory shrink almost guarantees to create whole bunches of dangling pointers. The sbrk limit is a shared resource, and you don’t ever know who else has used it since you did.

Michael seems to have covered about everything in pointer corruption, except for one thing.

In my experience, 90% of seg viols are caused by stuffing string data into a buffer that is too small, without checking length properly. Ascii chars get smeared across the adjacent memory. If any of that memory contains a pointer, it will now contain a bad pointer. The reason being, the top byte of the pointer will contain at lease 0x20 in ASCII, and in a 32-bit address that is at least 2^^29, and that is almost certainly bigger than your process space. Next use of pointer guarantees segviol.

10

@Ripunjay,

Actually, segmentation has been around since long before the x86 - at least since the development of the MULTICS computer at MIT in the 1960s.

Michael S. Meyers-Jouan

11

The above explanation is absolutely correct for a dangling pointer (was lazy to write this big myself:))

Just wanted to add that - Segmentation is a mechanism to implement virtual memory, which provides security and partitioning different elements of a program. Paging is another mechanism used for efficient usage of memory. Most of the operating systems use a hybrid approach.

It is important to note that hardware must provide some mechanism for OS to employ virtual memory mechanisms. Segmentation is primitive mechanism (probably firstly provided in Intel based x86 systems) and most intuitive one.

12

I’m going to try to make a contribution from a hardware point of view.

All modern operating systems use “virtual memory” (which is very different from “virtual machines”) to allocate storage to processes. When you run an application (whether written in C, or Basic, or assembly language), it is loaded into the virtual memory space of a process. For the purposes of this discussion, I’m going to ignore the issues caused by paging, working sets, and other features that implement the virtual memory, and concentrate on the features of virtual memory from the application’s side.

Each application has its own “memory space”, or “address space.” That range of addresses can be huge: with a 32-bit operating system, it is theoretically 4 GB (4,374,659,072 bytes) - and again, I’m going to ignore issues such as the 3.7 GB limit in Windows. With a 64-bit operating system, the address range is (theoretically) 19,137,641,996,231,901,184 bytes. However, a program doesn’t actually use that entire address space; instead, it has sections of the address space allocated form code, data, stack, etc. The technical name for each of the sections is “segment.”

The hardware mechanisms that implement the virtual memory use the segment definitions to determine which parts of the virtual address space are in use. When an application attempts to access an address that is not in one of the defined segments, the hardware generates a segment fault.

I’m not going to get tangled up in the discussion of what constitutes a “dangling pointer,” except to say that it very rare that a dangling pointer by itself is going to generate a segment fault. You see, regardless of whether the object is still there or not, the point is still pointing at a memory location that is within one of the existing segments - the object was allocated at a legitimate address, and the pointer is still pointing to that address.

However, let’s look at what happens when a pointer is a reference to an object or structure which in turn contains pointers (the object or structure references other variables). Now we have a dangerous situation. The object is deleted, and the memory allocated to it is reused, filling that space with some random data. Then, the dangling pointer is used to refer to that space, and some part of the space is used as a pointer. Because that space has been overwritten, the value may (note I wrote may, not will) be an address that is outside of any segment assigned to the process. That is what causes a segment fault.

There is another way that you can get a segment fault, but this typically affects only one segment: the one used to hold the stack. A stack, which is a first-in, last-out storage area, grows from a starting location, towards some other location. The segment that is used for the stack is allocated so that one end of the allocation is the starting point of the stack, and the other end of the segment allocation is the maximum size of the stack.

Now, if the stack grows bigger than that maximum size, the stack pointer is pointing outside the allocated space. That is a segment fault. But, for this one segment, that segment fault is reported as a stack overflow, because that is a much more informative error message - but a stack overflow is (in most operating systems) always detected as a segment fault.

Different operating systems (Windows, OS-X, *nix, etc.) have different ways to set up the segmentation controls. Different processors (Intel x86, IBM PowerPC, Sun SPARC) have different hardware implementations of segmentation. With all these variations, the names of the procedures, and the names of the data elements that go into each segment’s description, vary all over the lot. I don’t see any reason to get caught up in attempts to identify the specifics of these features (also, I don’t know the specifics for most systems or most processor types); if you’re really concerned about these issues, remember that The Help File Is Your Friend: find the manuals for your environment and study them.

Michael S. Meyers-Jouan

13

AFAIK, ulimit is an administrative limit (or hard limit) setup to indicate the maximum of a specific property of a process. Once set this can’t be changed for a given process.

In a logical address space of process one can assume heap to be siting right above data-area such that stack and heap grow towards each other. In absence of any other kind of memory allocations like in mmap(),
one can theoretically assume that each byte allocated in stack (or heap) actually limits the heap’s (or stack’s) storage capacity. Ideally, malloc/mmap should not be mixed with sbrk() in same program for memory allocation.

Now, what I wanted to say that sbrk() can be used dynamically to allocate or deallocate memory. -ve offset when provided to sbrk() actually deallocates space from heap. Thus stack regains some space.
Check POSIX standard for sbrk() and -ve offset. Moreover, sbrk() is not a system call. It is a glibc library wrapper.
I agree to your point that, a hard limit can be set for stack size to be much lesser value so that it would never reach out to heap.
In practice stack size would be order of 8 MB or so.

You certainly cannot change the base pointer of stack once the program has started, however the far end can always be adjusted; and actually gets adjusted in the absence of restrictions.

In case of threads, you are right to say that pthread_attr_setstacksize() can’t be used dynamically on other threads, other than main() thread. (Atleast in linux)

http://man7.org/linux/man-pages/man3/pthread_attr_setstacksize.3.html

14

Hmmm if you have a pointer to an ‘object’ then delete said ‘object’ (but don’t alter the pointer), then the pointer is pointing to memory that used to belong to the ‘object’ but obviously doesn’t belong to the ‘object’ now so in that sense the pointer is dangling.
Allan

15

No, Gaura. Having no memory available is a consequence of memory leaks, not a cause.

The memory that ptr pointed to does not cease to exist. It is in no sense destroyed.? It happens to be on the free list now, that’s all. That means any other function can fill it with some other data, and ptr will now point to their data and not yours.

Nobody has yet posted an actual instance of the dangling pointer issue here. It is not what yiu think it is.

16

No. sbrk() is a system level call that grows your process space in the positive direction only.

Malloc calls sbrk when it needs to, to extend the heap. Malloc and free then administer that extension for you.

I have never seen a function that will extend the stack once the program is running. You can fix ulimit stack size before starting only.

Pthread might allocate stack size for each thread before it gets started. That space will come from one of two places:

(a) it will be a slice of the original stack for the whole program.

(b) it will be obtained by sbrk()

Again, you can’t extend the satck space of something thst is already running on that stack.

If you disagree, post the link to the man page that supports your beliefs so the rest of us can learn.

17

Reposting as my previous reply did not appear for long.

Gaurav,

There is certainly a memory leak. Why ?
Look at the program.

char *ptr=(char)malloc(10);
ptr=“hello”;
free(ptr);

There is a statement which carries a string constant “hello”.
What do you think, where was the memory allocated for “hello” in the statement ptr = “hello” after process is started but before main() starts executing.
The memory was already allocated in “data area” (.ro data)and the base pointer of “hello” actually points to that address.
Now when you performed ptr = “hello”, you actually overwrote thr previous contents of ptr which is actually an address of allocated memory from heap.
Since you have overwrote that memory, and your program doesn’t know the address of that allocated memory, there is no way you can reclaim that space by calling free.
Depending upon implementation of free(), your program may crash as you are trying manipulate read only data.

Now, what you should have done ?

You should have used -

strcpy(ptr,“hello”);

instead of

ptr = “hello”;

Impact of memory leak as we just saw is insufficient/unavailable memory. But to reach that point, you should have leaked it many more times.
You run your program in an infinite loop and see that by your self.

I hope this explanation gives rise to many more queries in you and a joy of answers to all those :slight_smile:

18

I believe sbrk () call has the job of playing with stack size alone.
Pthread library also provides a portable way to adjust stack size for each
thread.

19

Hi Sir
your first suggestion is correct Ptr returned from malloc should be casted
to char*
sorry for the typing negligenc e. since the memory is allocated “hello”
will not cause memory leak.
Memory leak happens when there isnt memory available
After freeing it points to a memory which does not exist hence becomes
dangling ptr and ptr[0] causes a segmentation fault because we access
unacessible memory

20

@Gaura

That example has a lot of issues.

malloc returns a char * (or void ) so casting it to char and then assigning it to a char is going to give you some compiler warnings.

Then you leak the malloced memory by overwriting ptr with the address of a string.

Then you free the “hello” string, which was not allocated by malloc, so has no hidden header. That’s probably going to crash the next malloc anyway, unless it crashes in the free before then.

Then you assert that using ptr causes a segmentation violation. That’s usually not true. It is forbidden to access ptr, but it won’t necessarily fail then. What happens is that some other part of the program eventually does another malloc, and gets some part of what you had, and fills it with its own contents, and THEN you use ptr and it seg viols. Just doing the free and using ptr does not trigger the problem.

@Manan,

The stack in the process space is of a fixed size (set by a ulimit in Unix) and there is no mechanism to extend it. So if you recurse too deeply, or assign a huge huge array on stack, you can run off the end of it.

That is exactly the same as a segviol (addressing outside process space), except it is reported as a stack overflow. That just really means a seg viol happened when using the Stack Pointer register.