CODEWITHSUNDEEP
gdb
Idan Arye
Idan Arye

Reputation: 12633

GDB ignores my breakpoints

My test case is so simple that I must be doing something very stupid. I wrote a simple source file test.c:

#include<stdio.h>

int main(int argc,char* argv[]){
    printf("1\n");
    printf("2\n");
    printf("3\n");
    return 0;
}

I compiled it with gcc -g test.c and started GDB with gdb a.out. Then I created a breakpoint in main with break main and ran it with run(also tried with start) - but GDB simply ignored my breakpoint!

This is the shell session of me trying to compile test.c and run GDB:

[idanarye@idanarye_lg gdbtest]$ gcc -g test.c
[idanarye@idanarye_lg gdbtest]$ gdb a.out
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/idanarye/gdbtest/a.out...done.
(gdb) break main
Breakpoint 1 at 0x40050f: file test.c, line 4.
(gdb) run
Starting program: /home/idanarye/gdbtest/a.out 
1
2
3
During startup program exited normally.
(gdb)

What in the world am I doing wrong here?

I'm running a 64bit Arch Linux. My GCC version is 4.8.2.

UPDATE

Here is the result of disas main:

Dump of assembler code for function main:
   0x0000000000400500 <+0>:     push   %rbp
   0x0000000000400501 <+1>:     mov    %rsp,%rbp
   0x0000000000400504 <+4>:     sub    $0x10,%rsp
   0x0000000000400508 <+8>:     mov    %edi,-0x4(%rbp)
   0x000000000040050b <+11>:    mov    %rsi,-0x10(%rbp)
   0x000000000040050f <+15>:    mov    $0x4005c4,%edi
   0x0000000000400514 <+20>:    callq  0x4003e0 <puts@plt>
   0x0000000000400519 <+25>:    mov    $0x4005c6,%edi
   0x000000000040051e <+30>:    callq  0x4003e0 <puts@plt>
   0x0000000000400523 <+35>:    mov    $0x4005c8,%edi
   0x0000000000400528 <+40>:    callq  0x4003e0 <puts@plt>
   0x000000000040052d <+45>:    mov    $0x0,%eax
   0x0000000000400532 <+50>:    leaveq 
   0x0000000000400533 <+51>:    retq   
End of assembler dump.

UPDATE

No idea how or why, but it works now. Probably a system update fixed it...

Upvotes: 11

Views: 18405

Answers (3)

Doug Royer
Doug Royer

Reputation: 65

I had this same problem. It was intermittent and drove me nuts. Then I found I did a dumb thing. I had been running the program from the command line, and it had a bunch of arguments.

So, I copied the command line with the mouse-copy-paste buffer.

Then started: gdb Program

Then did: break man

Then did: -PASTE-FROM-MOUSE-

It never stopped, until I realized that I had pasted too much of the command line: "--option=c ... |& tee LOG"

It looked like an intermittent problem, until I realized it was a brain bug. Hope this helps someone. The command line redirect - did something in GDB, no clue what (other than ignore breakpoints).

Upvotes: -3

Vishal Sharma
Vishal Sharma

Reputation: 1750

I encountered a similar problem and in my case the thing was that my program was forking itself. So basically, my code looked like this:

#include <string>
#include <iostream>
#include "func.hpp"

using namespace std;

int main(int argc, char **argv)
{
        if(argc <3)
        {
          printf("\n %s IP PORT\n",argv[0]);
          printf("e.g. %s 10.32.129.77 6379\n",argv[0]);
          printf("\n Going to run on the default server and port\n");
          string command{argv[0]};
          command+=" 10.32.129.77 6379";
          printf("\nCommand: %s\n",command.c_str());
          system(command.c_str());
          exit(0);
        }

func();
}

I was creating a breakpoint where "func" function was being called. However, I unknowingly wasn't passing the correct arguments and as a result my program forked itself with correct arguments. So basically "func" was now being called from the child process and as it turns out gdb doesn't set the breakpoints at the child process and that's why the breakpoint was not being hit.

Upvotes: 0

Iwillnotexist Idonotexist
Iwillnotexist Idonotexist

Reputation: 13467

(curated from comments)

You do not appear do be doing anything wrong; It appears to be GDB's fault.

The message During startup program exited normally. is anomalous, the correct one being Program exited normally.. It suggests GDB failed to insert a breakpoint in main() or the traced program's call to ptrace(PT_TRACE_ME, 0, 0, 0) failed. The program thus ran without being stopped, and it exited while GDB was only expecting it to start up and stop at exec(). Can you run gdb under strace while doing your example and grep strace's log for any failed ptrace calls?

You would do so with strace -f -o syscall.txt gdb ./a.out.

As of right now a stop-gap measure appears to be to run GDB as root.

Upvotes: 4

Related Questions