6

I've never used a debugger and the time has come to give them a try. MinGW appears to come with GDB which I've been trying to use. Supposdly running gdb from the command line and typing run myprog.exe starts the debugger but when I do this I get

Starting program: C:\MinGW\bin\myprog.exe MyProg.exe [New Thread 1828.0xd8c] Error opening file. [Inferior 1 (process 1828) exited with code 02]

How to proceed or what's an easier way?

In particular I'm trying to flush out undefined behavior.

Celeritas
  • 14,489
  • 36
  • 113
  • 194

5 Answers5

2

Since your program terminates, you'll need to set a breakpoint to see anything. Try break main before the run line. Then you can do commands line next (next line), step (step into/outof function calls), print expression (where expression can be a variable name or a function-call or a calculation), display expression (same as print, but prints just before each prompt). At any given point you can type backtrace to get a call stack. You can even type up and down to move up the callstack, so you can print higher local variables.

luser droog
  • 18,988
  • 3
  • 53
  • 105
1

Well, the easiest way would be to use an IDE, actually. You might want to give code::blocks a try - very easy to use, configures everything for you on installation (just make sure to pick a compiler - don't worry, it'll prompt you) and there, you're all set and ready to go. As it's multi-platform, it doesn't really lock you into windows either, and gives you very powerful (and, I guess more importantly, convenient) possibilities of graphical debugging.

Fenixp
  • 645
  • 5
  • 22
  • I am using codeblock and according to this YouTube video I need to add a file to a project before using a debugger on it. I have a file but no project, how do I add it to a project? http://www.youtube.com/watch?v=6CGH9Z19dS8 – Celeritas Oct 04 '13 at 09:01
1

pass the binary with gdb

gdb <binary>

then set breakpoint to main

gdb) break main

Then run your program in gdb

gdb) run

then break point hits use 'n' or 'next' to step to different lines

gdb) n

Use 's' for stepping into function and 'p' printing var value

Example :

gdb) s <fun_name> 
gdb) p x
Sohil Omer
  • 1,171
  • 7
  • 14
0

I would suggest , as a beginner start off with Visual Studio. It has a very good and easy to use debugger. Just create a break point in the line from which you want to start debugging (click on the left bar beside the line or right click and create a break point). Once your break points are set you can just simply run the program in debug mode and the execution of the program will halt in the point where the break was created.

At this point you should be able to view all valuable information about the execution of the program. You can use F10 to continue the execution step or F11 to step inside the execution tree.

The debugger as many other advanced features like break on condition , hit count etc but you can start off with it's basic functionality.

Genocide_Hoax
  • 843
  • 2
  • 18
  • 42
  • 2
    I would suggest that beginners avoid visual studio like the plague. It's the worst debugger and development environment i've ever seen in my entire life. Files lock constantly (windows thing), the project files are a nightmare to manage, it automatically slips in and out of native and other modes preventing you from hitting breakpoints, you need to have dlls and pdb files for debugging, the core file analysis is just broken, windows has a fault tolerant heap to hide crashes from you to make it seem more reliable than it really is, the documentation is attrocious, functions are proprietry etc. – Owl Apr 10 '17 at 13:24
0

If I compiled a program like this:

gcc -o my-prog -g myprog.c

I could then debug the executable my-prog it like this:

gdb my-prog

The -g option tells gcc to generate full debugging info. Other compilers will have their own versions of this option (e.g. the MSVC cl command has the /Zi option).

Since you're having issues running the gdb on your program, it might be worth checking if it was compiled with debugging info in the first place. The debugging info is usually generated in the same location as where you compiled your program.

angstyloop
  • 117
  • 6