In gdb: During startup program exited with code 1. Runs fine outside of GDB

Question

I have a program that I compiled with debug flags that runs just fine when I execute it normally, but will not run in gdb.

Here's a summary of what I see:

gdb --args myProgram various arguments
//some standard gdb output stuff here
run
Starting Program: /full/path/to/my/executable/myProgram various arguments
During startup program exited with code 1

I believe that the "during startup" part means that the program is exiting prior to calling main, but so far I haven't been able to figure out anyway to set a breakpoint prior to it failing.

Things I tried

• I verified that the path that GDB outputs for my executable is correct
• b main - same output as before
• b _start - same output as before
• b _init - same output as before
• b exit - same output as before
• catch syscall exit_group - same output as before
• starti - no such command because my gdb is too old
• set disable-aslr on - no such symbol (at this point this was a little desperate, I have no idea if ASLR is playing a role in this at all)
• set stop-on-solib-events 1 - same output
• catch load - undefined catch command
• break *0 - (nifty hack from this answer)same output as before (plus the messages about the invalid address)
• info file - to see the entry point address, it was the same address as _start
• b std::terminate - couldn't find the symbol
• I looked at quite a few other stack exchange questions, but unfortunately I didn't keep track of them all, so I can't list them all here.

Thing I really don't want to try

The only thing that I know of that happens before main is that statically stored variables are initialized. So I suppose on approach I could take would be to attempt to identify all of the places where static variables are initialized and set breakpoints there. However, this is a large code base that depends on a lot of shared libraries and a lot of it is pretty messy because a lot of it was written in the 80s when coding standards were quite different. I really don't want to dig through all of this, especially since I have a pretty low level of confidence that it would actually help me out anyway.

Some general questions I have

Maybe I shouldn't even be focusing on trying to set a breakpoint before the program quits. Maybe there's another way to figure out (or even guess) what is causing it to exit.

What are some differences between how a program is run in GDB vs how it is run normally from the command line?

What are some common causes of seeing this error when a program runs fine outside of GDB?

Is it possible that GDB is reporting this issue before even attempting to start my program? Or is it actually starting it and all my attempts to break just aren't working for some reason?

Answer 1

[SOLVED] Special case involving redirection.

I was getting "During startup program exited with code 130." when I ^C well after my program was running,

Yes I had "handle SIGINT pass nostop noprint" in my .gdbinit so I could break my program as if it wasn't running in the debugger.

It turns out I wasn't interrupting the correct program.

I ran "gdb a.out", set a breakpoint, and then "r [args] 2>&1 > tee output.log" because I wanted to both see the stdout/stderr output immediately but also wanted to capture it in output.log in case it started streaming errors too fast and overran my terminal scrollback buffer.

When I hit ^C I was sending a SIGINT to tee, not to my program running in gdb.

When I reran my program with a simple "-r [args] 2> output.log" and did a "tail -f output.log" in another window my ^C sent SIGINT to my program and I gracefully exited.

Answer 2

You might want to review https://sourceware.org/gdb/onlinedocs/gdb/Starting.html for details of the start process under gdb. It may involve the shell or some wrapper process, and the error message you quote indicates the exit of that shell/wrapper before it executes your actual binary. For example, if you use sudo to start gdb under a system account whose shell is set to /bin/false and you pass arguments to it and you don't set startup-with-shell off, gdb will try to use /bin/false to pass the arguments to you binary, which will naturally fail and you'll get the exact message you quoted instead of your program being executed.

Answer 3

I believe that the "during startup" part means that the program is exiting prior to calling main

You must be on Windows (it's worth mentioning that, because the solutions are going to be very different from e.g. Linux).

No: it means that the program received EXIT_PROCESS_DEBUG_EVENT before it completed initialization. Usually it means that kernel32.dll didn't like something about the way this process was set up, and not even a single instruction of your program has run.

You may get additional debug help from GDB with set debugevents 1.