1
votes

I'm working on a C++ application, that I debug on Android; as it happens, on some devices this app crashes. I've sort of narrowed it down to one function, which I try to debug with a breakpoint in ndk-gdb. The first time, at start, the function runs and it breaks fine, e.g.:

Breakpoint 1, MyApp::MyFunc (this=0xb8541c40, curel=0xb8cb7e68, doShow=false)
    at /path/to/src/MyApp.cpp:1600
1600      myObj.clear();
(gdb) c
Continuing.

Here, I've obviously typed c and ENTER myself; but then, upon a user action, the function runs for a second time, and I get this:

Breakpoint 1, MyApp::MyFunc (this=0xb8541c40, curel=0xb8cb7e68, doShow=true)
    at /path/to/src/MyApp.cpp:1600
1600      myObj.clear();
(gdb) 
Continuing.

Program received signal SIGABRT, Aborted.
0xb6f7b1b0 in tgkill ()
   from /path/to/obj/local/armeabi-v7a/libc.so
(gdb) 
Continuing.

Program received signal SIGABRT, Aborted.
0xb6f7b1b0 in tgkill ()
   from /path/to/obj/local/armeabi-v7a/libc.so
(gdb) 
Continuing.

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.

So, here the breakpoint does hit, but it doesn't break - and even if I didn't press c, it goes on with "Continuing", hitting SIGABRT twice and again "Continuing", and finally the program terminates.

From the limited information here, would anyone have an idea of why does this happen, and how to remedy it? For instance, could this be due to optimization (the app is compiled in what should be debug mode, but possibly some optimization is still there)? Btw this is GNU gdb (GDB) 7.7, android-ndk-r10e.

1
The second time around the code crashes with a SIGABRT, before the breakpoint gets hit again. When you get a SIGABRT, look at the backtrace.Sam Varshavchik
Thanks @SamVarshavchik - occasionally it stops at the sigabrt, and I've tried issuing a backtrace, but it didn't reveal anything obvious... But good to have it clarified that the breakpoint didn't hit the second time, I'll try it again - cheers!sdaau

1 Answers

2
votes

Damn it, I'm stupid :).. See, what happened is that after I issue c the first time, I get a bunch of messages in gdb, and then they temporarily stop while the app waits for input. And, usually I press here ENTER a couple of times, so I have a few empty lines in the terminal output, to delimit a new stage in the log.

But, gdb interprets ENTER as "repeat last command", which here was continue, so, it basically "runs over" the breakpoint and the sigabrts when they occur (I did find it strange why do I get the break at sigabrt only sometimes).

Well, there it is - don't press ENTER to make space in the terminal output while debugging :) (and make sure there are no hanging processes from previously badly terminated session with gdb)