Help interpreting gdb: segfault in function

Question

I am trying to debug a segfault, and I have this output from gdb:

(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x08048af9 in parse_option_list (ptr=0x6f72505f <Address 0x6f72505f out of bounds>, box_name=0x696d6978 <Address 0x696d6978 out of bounds>, option_list=0x313a7974, 
    num_elements=0x33313532) at submit.c:125
125       memcpy(&(option_list[(*num_elements)].value), value, 24);
(gdb) p num_elements
$15 = (int *) 0x33313532
(gdb) p *num_elements
Cannot access memory at address 0x33313532
(gdb)

It looks to me like something in memcpy() is going haywire. But I can't figure out what exactly the problem is, since that line references so many variables.

Can somebody help figure out what the 0x8048af9 in parse_option_list... line is telling me?

My function signature is:

int parse_option_list(char *ptr, char *box_name,
   struct option_list_values *option_list, int *num_elements)

And this might be useful:

struct option_list_values {
    char value[24];
    char name[24];
};

Also, the variables value and name are not segfaulting (but if you think they are, i can post the code which sets those values.) But right now, if I can understand this gdb output, I will be happy as a clam! Thank you!

Answer 1

0x8048af9 is the instruction pointer - the address of the executable code in memory that your code was at when the SEGFAULT occurred.

Are you sure that option_list[(*num_elements)].value is a valid address? You might have a buffer overflow, and be overwriting something you shouldn't be.

If num_elements is the length of option_list, then option_list[(*num_elements)] refers to just after the end of the list.

Answer 2

ptr=0x6f72505f - Address 0x6f72505f out of bounds This is the useful part in this case The first input to parse_option_list is invalid. Possibly an uninitialized pointer.

Answer 3

You have all the signs of a classic buffer overflow. The values of all the stack parameters have been overwritten by ASCII text - here is the translation of those values (assuming you have a little-endian architecture, which looks right):

ptr = 0x6f72505f = "_Pro"
box_name = 0x696d6978 = "ximi"
option_list = 0x313a7974 = "ty:1"
num_elements = 0x33313532 = "2513"

Concatenating them together gives "_Proximity:12513" - if this substring looks familiar to you, you should be able to track down where that data is being copied around - somewhere you are copying it into an array stored on the stack, without proper bounds checking.