sources of segmentation error

**stanlvw** · 04-21-2009

I know that the most common source of segmentation error comes from the programmer writing/reading from memory that has not been allocated by the operating system yet. I'm experiencing a segmentation fault problem whenever a special case of the program runs, yet I can't find any references in the code where the variable the debugger is complaining about is being read/written illegally. What other highly likely sources are there? What are some of the tools used to find it?

I found the following description when going through the debugger. I'm not sure how much help this would be, but I don't totally understand the explanation in this comment.

Code:

/*
         * If this ASSERT fails, a bad pointer has been passed in. It may be
         * totally bogus, or it may have been allocated from another heap.
         * The pointer MUST come from the 'local' heap.
         */
        _ASSERTE(_CrtIsValidHeapPointer(pUserData));

**matsp** · 04-21-2009

That only checks if the pointer is from the local heap [the block of memory from which for example malloc() allocates memory]. It does not really check if it's a valid pointer - it is much more restrictive.

For example:

Code:

char *p = "abcdef";

p in the above code is a valid pointer (to read from), but it's not from the local heap.

I know that the most common source of segmentation error comes from the programmer writing/reading from memory that has not been allocated by the operating system yet.

That, and read-only memory failing on attempts to be written are the only cases that will give a seg-fault [ok, so modern processors can also seg-fault if you try to execute something that has the NX bit set - this bit indicates that the section of memory is "Not eXecutable"]. But basically, it means you trying to access memory in a way that the processor doesn't agree with - either the memory isn't available to the process, or it can't be accessed in the way you are requesting (writing read only, or executing stuff that isn't intended to be executed).

Of course, invalid pointers can be caused by all sorts of things - it's not necessarily that the pointer hasn't been assigned a valid value - it may be that it's got overwritten by something else and thus points into the weeds.

--
Mats

**matsp** · 04-21-2009

I should add that if you are working on Linux, you may be able to use valgrind to find the problem - in Windows there are commercial products of similar ilk, but no free version, unfortunately.

--
Mats

**pheres** · 04-22-2009

Originally Posted by stanlvw

I know that the most common source of segmentation error comes from the programmer writing/reading from memory that has not been allocated by the operating system yet.

It has not really to do with allocation, you can use un-allocated memory as you want as long as you have access right to it. So it is an access violation, you are accessing memory location the OS is protecting from you. Unfortunately this doesn't help you much, you still have to find out where the bad pointer comes from.

**Masterx** · 04-22-2009

i once had the same problem , try checking your indexes ( i mean counters and stuff like that , which you use to loop mainly) maybe they are incrementing or decrementing more than enough!
in my own problem , one of loops ( that actually used to interact with a map , has exceeded its bounds , and it gave me that segmentation error )

**cyberfish** · 04-26-2009

So is it a segmentation fault or a failed assertion? I'm assuming a function meant to check for a valid pointer won't give you segfault...

Can you get a backtrace (call stack) from the debugger? It could give you more information in terms of what variables are passed to what functions (and you can examine them).

**stanlvw** · 04-26-2009

When I backtraced the call stack from a debugger, it's coming from a free() call. I have examined all the calls that have used the parameter of free() that I tried to call, and can't find anything about indexing the array out of bounds.

**cyberfish** · 04-26-2009

You can examine the frames leading up to the free() call.

It's probably not out of bounds access. More likely double free or freeing an uninitialized pointer in this case. Did you initialize all your pointers to null?

**stanlvw** · 04-26-2009

Do you mean the call stack frames leading up to the free() call? I'm pretty sure that I have called free() only once, and nothing was done on the pointers before having memory allocated to the pointers, so I don't know if initializing them to NULL even mattered.

**cyberfish** · 04-26-2009

Do you mean the call stack frames leading up to the free() call?

Yes.

I'm pretty sure that I have called free() only once

Are you sure the memory was allocated on the heap, not the stack? Are you sure memory allocation actually took place and succeeded?

Initialize to NULL would tell you if you are freeing an uninitialized pointer, because freeing a NULL pointer is harmless.

**matsp** · 04-27-2009

Also, you may want to check ANY OTHER free that the program makes - since it's quite possible that the problem is caused by another free prior to the one where it actually fails. The reason for this is that malloc/free and hold some internal data structures (linked lists or similar, most likely) that can get messed up if you free garbage. It won't crash then, but it will crash when you do the next free, because it now tries to dereference a rubbish pointer.

--
Mats

**CornedBee** · 04-27-2009

Are you perhaps implementing your own string class or something similar? Does the class have a proper copy constructor?

Thread: sources of segmentation error

Thread Tools

Search Thread

Display

sources of segmentation error

Similar Threads

Compiling sample DarkGDK Program

Testing some code, lots of errors...

Another syntax error

Post...

Dikumud