finding which function caused "Address out of bounds" in gdb

Question

I have a critical bug in my project. When I use gdb to open the .core it shows me something like(I didn't put all the gdb output for ease of reading):

This is very very suspicious, new written part of code ::

0x00000000004579fe in http_chunk_count_loop 
 (f=0x82e68dbf0, pl=0x817606e8a Address 0x817606e8a out of bounds)

This is very mature part of code which worked for a long time without problem::

0x000000000045c8a5 in packet_handler_http 
 (f=0x82e68dbf0, pl=0x817606e8a Address 0x817606e8a out of bounds)

Ok now what messes my mind is the pl=0x817606e8a Address 0x817606e8a out of bounds, gdb shows it was already out of bounds before it reached new written code. This make me think the problem caused by function which calls packet_handler_http.

But packet_handler_http is very mature and working for a long time without problem. And this makes me I am misundertanding gdb output.

The problem is with packet_handler_http I guess but because of this was already working code I am confused, am I right with my guess or am I missing something?

Answer 1

Thanks guys for your contrubition , even gdb says opposite it turn out pointer was good.

There was a part in new code which causes out of bounds problem.

There was line like :: (goodpointer + offset) and this offset was http chunk size and I were taking it from network(data sniffing). And there was kind of attack that this offset were extremely big, which cause integer overflow. And this resulted out of bounds problem.

My conclusions : don't thrust the parameters from network never AND gdb may not always points the parameter correctly at coredump because at the moment of crush things can get messy in stack .

Answer 2

The problem is with packet_handler_http I guess

That guess is unlikely to be correct: if the packet_handler_http is really receiving invalid pointer, then the corruption has happened "upstream" from it.

This is very mature part of code which worked for a long time without problem

I routinely find bugs in code that worked "without problem" for 10+ years. Also, the corruption may be happening in newly-added code, but causing problems elsewhere. Heap and stack buffer overflows are often just like that.

As alk already suggested, run your executable under Valgrind, or Address Sanitizer (also included in GCC-4.8), and fix any problems they find.

Answer 3

To detect "memory errors" you might like to run the program under Valgrind: http://valgrind.org

If having compiled the program with symbols (-g for gcc) you could quite reliably detect "out of bounds" conditions down to the line of code where the error occurrs, as well with the line of code having allocated the memory (if ever).