2

I'm trying to use gdb to debug a C program which all works ok until I pass a pointer to a function (to a third party library), after which gdb loses focus and the program runs without hitting my breakpoint in my call back function.

For example I am calling pcap_loop from the libpcap library which expects a pointer to my call back function got_packet.

 pcap_loop(handle, num_packets, got_packet, NULL);

As soon as i step in or over this line with gdb my break point in got_packet is never hit.
Why ?
Any ideas?

Improve this question
4
  • 3
    Are sure it really gets called? Commented Feb 18, 2013 at 16:35
  • 2
    I agree with alk. Set a breakpoint on got_packet itself to see if it really gets called. Commented Feb 18, 2013 at 16:46
  • you could be listening to the wrong interface that's why you're not getting any packets.. Commented Feb 18, 2013 at 16:50
  • 1
    Thanks guys, yes im sure the function gets called it happily spits out my packets in my function just never hits the breakpoint in my call back passed to libpcap. Commented Feb 19, 2013 at 11:44

1 Answer 1

Reset to default
1

There are some circumstances in which GDB breakpoints can get skipped, especially when debugging code compiled with optimization enabled, but the most likely answer is that the library function isn't doing what you expect.

GDB can't step into libraries that don't have debug information, so instead it just appears to "lose focus", as you put it, sets a temporary breakpoint on the return point and waits for the function to finish. That still shouldn't stop the breakpoint inside the call-back from triggering.

If you are using a library that came from your OS repository then you might find that there is a "debug" package you can install. This would allow you to step into the library code and possibly work out what the problem is that way.

However, it's usually far simpler to add printf debugging, or "break" the got_packet function in some way that will cause a signal (*(int *)0 = 1), and satisfy yourself that way whether it is being called or not.

If you can show that the function really is being called, and that GDB really isn't catching the breakpoint, then you have a GDB bug (or maybe a kernel bug).

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

GDB can step into libraries that don't have debug information, but you need to use stepi to do that.
@EmployedRussian: well, that's true, but you'd most likely have to step for a long time before you got anywhere useful.
Thanks ams, I ended up doing as you suggest and adding printf's to my callback function passed to libpcap which confirmed my function pointer being called successfully by libpacp but never hitting the breakpoint set in gdb. Ill try using a version of libpcap compiled with debugging information as you suggest and see if this fixes the problem but as you suggest I would still expect the breakpoint to hit when my function is called from a library without debugging info. Anyway, happy to accept you answer :-), many thanks.
@EmployedRussian: I'll try stepi as you suggests too but I've no idea how many calls there would be before my function is called. I'll give it a go so I have a better understanding, thanks.
Why don't put a breakpoint to got_packet function and go ahead normally ? This is the easiest solution for me

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.