GDB keeps resetting my SHELL to the current executable

Question

Every time I try to run anything in GDB, I am met with the following error message:

Error: No such file or directory
During startup program exited with code 127.

Searching around on here, I found out that this can occur when the SHELL variable is not properly set, and indeed running export SHELL=/bin/bash --login before running GDB solves the problem for the current session.

However, this is in spite of the fact that echo $SHELL spits out the desired value already. If I look closer at the command GDB is trying to execute, it typically takes the form:

/path/to/mybin -c exec /path/to/mybin --my --opts

instead of

$SHELL -c exec /path/to/mybin --my --opts

That is, GDB somehow resets SHELL to point to whatever executable I am passing it before it starts running. (I use the format gdb --args /path/to/mybin --my --opts to start GDB.) Before and after the run, SHELL has the correct value. If I try to debug three different executables in a row, each of those three executable will be used as it's own shell, obviously producing failures. If I even once run export SHELL=(acceptable shell) , it will work properly for the remainder of the session.

None of my shell dotfiles (.bashrc, .profile, etc) make any reference or modification to the SHELL variable. This behavior seems completely incomprehensible to me. Does anyone have an idea what may be going on?

I am using gdb-7.7.1 in bash-4.3.11 on Ubuntu 14.04.

EDIT: I was wrong about an important detail. Running export SHELL=/bin/bash --login actually does not correct it. The same problem persists if I do that. (This is also the default value in my shell and what I see if I enter show env SHELL when gdb is not working. However, setting export SHELL=/bin/bash does correct the issue, so the login shell is somehow the issue, I guess.

Answer 1

The problem is almost certainly with your ~/.bashrc but it's hard to guess what it is from your description.

Step 1:

mv ~/.bashrc ~/.bashrc.save.20170411

logout and back in verify that GDB works just fine

Step 2:

Copy parts of .bashrc.save.20170411 to ~/.bashrc, and repeat logout/login cycle, until GDB stops working again.

Step 3:

Now you know part is causing trouble, and can ask a better question if you still don't understand why that chunk of .bashrc is problematic.