CODEWITHSUNDEEP
c++csegmentation-faultbuffer-overflow
skiphoppy
skiphoppy

Reputation: 102863

Why would buffer overruns cause segmentation faults when accessing an integer?

During a call to function B() from function A(), B() allocates a 100-char array and fills it several times, including once with a 101-character string and once with a 110 character string. This is an obvious mistake.

Later, function A() tries to access completely unrelated int variable i, and a segmentation fault occurs.

I understand why the buffer overrun occurs, but why do I get a segmentation fault when I access this integer? Why is it that I don't simply get garbage data?

Upvotes: 4

Views: 1229

Answers (5)

t0mm13b
t0mm13b

Reputation: 34592

It is important to remember that you allocate enough memory plus one for the nul terminating character (Astute readers will point out this nul, that is primarily there for a reason - a nul with one 'l' is '\0' [Thanks Software Monkey for pointing out an error!], a null with two 'l' is a pointer pointing to nothing).

Here's an example of how a seg fault can occur

int main(int argc, char **argv){
    int *x = NULL;
    *x = 5;
    // boom
}

Since x is a pointer and set to null, we attempt to dereference the pointer and assigning a value to it. A guaranteed way of generating a segmentation fault.

There is an old trick available in that you can actually trap the seg fault and get a stack trace, more common on unix environment, by setting up a signal handler to trap a SIGSEGV, and within your signal handler invoke a process like this:

char buf[250];
buf[0] = '\0';
sprintf(buf, "gdb -a %d | where > mysegfault.txt", getpid());
system(buf);

This attaches the currently executing C program and shells out to the debugger and attaches itself to it, the where part of it shows the stack trace of the offending line that caused the seg fault and redirects the output to a file in the current directory.

Note: this is implementation defined, depending on the installation, under AIX, the gnu debugger is present and hence this will work, your mileage may vary.

Hope this helps, Best regards, Tom.

Upvotes: 0

wallyk
wallyk

Reputation: 57784

When A() calls B(), B's preamble instructions save A's frame pointer—the location on the stack where A keeps local variables, before replacing it with B's own frame pointer. It looks like this:

Stack Frame

When B overruns its local variables, it messes up the value which will be reloaded into the frame pointer. This is garbage as a frame pointer value, so all of A's local variables are trashed. Worse, future writes to local variables are messing with memory belonging to someone else.

Upvotes: 5

Pascal Cuoq
Pascal Cuoq

Reputation: 80325

A buffer overrun may clobber a previously saved version of the frame pointer on the stack. When the function returns, this corrupt version is loaded into the frame pointer register, causing the behavior you describe.

Wikipedia's page contains a figure and definitions.

Upvotes: 14

Chris Dodd
Chris Dodd

Reputation: 2960

The most likely explanation from you description is that the overrun in B corrupts the saved frame pointer on the stack for A. So after B returns, A has garbage in its frame pointer and crashes when it tries to access a local variable.

Upvotes: 3

Anon.
Anon.

Reputation: 60013

If you're accessing i through a pointer, then the problem is the pointer is garbage.

Upvotes: 0

Related Questions