Weird x86 Linux/GNU crashes

Weird x86 Linux/GNU crashes

[Mark Mitchell]

I've got some changes to the C++ front end that I've tested pretty
well (make check-g++).  Then, I updated the compiler and rebuilt from
scratch in preparation for final testing and check-in.  Now, every
dynamically linked C++ binary crashes, but statically linked ones are
OK.

The behavior is somewhat odd; GDB seems to get confused:

bash-2.05$ LD_LIBRARY_PATH=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3/src/.libs:. ./bitfield1.exe 
Segmentation fault

bash-2.05$ LD_LIBRARY_PATH=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3/src/.libs:. gdb ./bitfield1.exe 
(gdb) run
Starting program: /home/mitchell/dev/gcc-mainline/objdir/gcc/./bitfield1.exe 
/home/mitchell/dev/gcc-mainline/objdir/gcc/./bitfield1.exe: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
(gdb) show env LD_LIBRARY_PATH
LD_LIBRARY_PATH = /home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3/src/.libs:.

So, GDB has the right LD_LIBRARY_PATH, but somehow cannot load the
libraries.  From outside GDB, the libraries are loaded OK, but the
binaries crash.

Has anyone seen this before?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Weird x86 Linux/GNU crashes

[H. J. Lu]

On Tue, Jul 30, 2002 at 03:48:12PM -0700, Mark Mitchell wrote:
> 
> I've got some changes to the C++ front end that I've tested pretty
> well (make check-g++).  Then, I updated the compiler and rebuilt from
> scratch in preparation for final testing and check-in.  Now, every
> dynamically linked C++ binary crashes, but statically linked ones are
> OK.
> 
> The behavior is somewhat odd; GDB seems to get confused:
> 
> bash-2.05$ LD_LIBRARY_PATH=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3/src/.libs:. ./bitfield1.exe 
> Segmentation fault
> 
> bash-2.05$ LD_LIBRARY_PATH=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3/src/.libs:. gdb ./bitfield1.exe 
> (gdb) run
> Starting program: /home/mitchell/dev/gcc-mainline/objdir/gcc/./bitfield1.exe 
> /home/mitchell/dev/gcc-mainline/objdir/gcc/./bitfield1.exe: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
> (gdb) show env LD_LIBRARY_PATH
> LD_LIBRARY_PATH = /home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3/src/.libs:.
> 
> So, GDB has the right LD_LIBRARY_PATH, but somehow cannot load the
> libraries.  From outside GDB, the libraries are loaded OK, but the
> binaries crash.

Try:

(gdb) set env LD_DEBUG=libs
(gdb) run


H.J.

Re: Weird x86 Linux/GNU crashes

[Mark Mitchell]

> (gdb) set env LD_DEBUG=libs
> (gdb) run

I get the attached output.  Why is this mmx stuff showing up?  And
what are the bits about bash?

Thanks,

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Starting program: 
/home/mitchell/dev/gcc-mainline/objdir/gcc/./bitfield1.exe
31457:	find library=libtermcap.so.2; searching
31457:	 search 
path=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3
/src/.libs/mmx:/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//li
bstdc++-v3/src/.libs:./mmx:.		(LD_LIBRARY_PATH)
31457:	  trying 
file=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3
/src/.libs/mmx/libtermcap.so.2
31457:	  trying 
file=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3
/src/.libs/libtermcap.so.2
31457:	  trying file=./mmx/libtermcap.so.2
31457:	  trying file=./libtermcap.so.2
31457:	 search cache=/etc/ld.so.cache
31457:	  trying file=/lib/libtermcap.so.2
31457:	
31457:	find library=libdl.so.2; searching
31457:	 search 
path=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3
/src/.libs:./mmx:.		(LD_LIBRARY_PATH)
31457:	  trying 
file=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3
/src/.libs/libdl.so.2
31457:	  trying file=./mmx/libdl.so.2
31457:	  trying file=./libdl.so.2
31457:	 search cache=/etc/ld.so.cache
31457:	  trying file=/lib/libdl.so.2
31457:	
31457:	find library=libc.so.6; searching
31457:	 search 
path=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3
/src/.libs:./mmx:.		(LD_LIBRARY_PATH)
31457:	  trying 
file=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3
/src/.libs/libc.so.6
31457:	  trying file=./mmx/libc.so.6
31457:	  trying file=./libc.so.6
31457:	 search cache=/etc/ld.so.cache
31457:	  trying file=/lib/i686/libc.so.6
31457:	
31457:	
31457:	calling init: /lib/i686/libc.so.6
31457:	
31457:	
31457:	calling init: /lib/libdl.so.2
31457:	
31457:	
31457:	calling init: /lib/libtermcap.so.2
31457:	
31457:	
31457:	initialize program: /bin/bash
31457:	
31457:	
31457:	transferring control: /bin/bash
31457:	
31457:	find library=libstdc++.so.5; searching
31457:	 search path=/usr/local/lib/mmx:/usr/local/lib		(LD_LIBRARY_PATH)
31457:	  trying file=/usr/local/lib/mmx/libstdc++.so.5
31457:	  trying file=/usr/local/lib/libstdc++.so.5
31457:	 search cache=/etc/ld.so.cache
31457:	 search path=/lib/mmx:/lib:/usr/lib/mmx:/usr/lib		(system search 
path)
31457:	  trying file=/lib/mmx/libstdc++.so.5
31457:	  trying file=/lib/libstdc++.so.5
31457:	  trying file=/usr/lib/mmx/libstdc++.so.5
31457:	  trying file=/usr/lib/libstdc++.so.5
31457:	
/home/mitchell/dev/gcc-mainline/objdir/gcc/./bitfield1.exe: error while 
loading shared libraries: libstdc++.so.5: cannot open shared object file: 
No such file or directory

Re: Weird x86 Linux/GNU crashes

[Michael Matz]

Hi,

On Tue, 30 Jul 2002, Mark Mitchell wrote:

> > (gdb) set env LD_DEBUG=libs
> > (gdb) run
>
> I get the attached output.  Why is this mmx stuff showing up?  And
> what are the bits about bash?

That the LD_LIBRARY_PATH after loading bash is different from when it
began searching somehow indicates, that either it's overwritten by some
bash init, or you haven't exported that env var.  (the mmx bits stem from
the linker in case one has optimized libraries for e.g. mmx, which are
then prefered over the normal ones, if placed in those dirs; but that's
not the issue here)


Caio,
Michael.

Re: Weird x86 Linux/GNU crashes

[H. J. Lu]

On Tue, Jul 30, 2002 at 04:10:56PM -0700, Mark Mitchell wrote:
> 
> > (gdb) set env LD_DEBUG=libs
> > (gdb) run
> 
> I get the attached output.  Why is this mmx stuff showing up?  And

It is for optimization. ld.so knows your CPU can do mmx.

> what are the bits about bash?
> 

That is your problem. It may be in your gdb and/or bash. You can try

(gdb) set env LD_LIBRARY_PATH=.....

instead of

LD_LIBRARY_PATH=.... gdb ...

I use gdb 5.2.0_2002-06-27-cvs. It works for me.


H.J.

Re: Weird x86 Linux/GNU crashes

[Michael Matz]

On Tue, 30 Jul 2002, Mark Mitchell wrote:

> And what are the bits about bash?

I forgot to say: gdb actually does a '/bin/bash -c "exec command args"' to
start the debuggee, so that bash is involved is normal.


Ciao,
Michael.

Re: Weird x86 Linux/GNU crashes

[David S. Miller]

   From: Mark Mitchell <mark@codesourcery.com>
   Date: Tue, 30 Jul 2002 16:10:56 -0700
   
   I get the attached output.  Why is this mmx stuff showing up?  And
   what are the bits about bash?

GDB exec's a shell to setup your environment properly then execute the
program to be debugged.  In this way GDB's environemnt doesn't need
to be altered among other things.

The mmx bits are just some of the search path postfixes glibc uses to
find optimized versions of libraries appropriate for the kind of cpu
execution takes place on.

Re: Weird x86 Linux/GNU crashes

[H. J. Lu]

On Tue, Jul 30, 2002 at 05:23:09PM -0700, David S. Miller wrote:
>    From: Mark Mitchell <mark@codesourcery.com>
>    Date: Tue, 30 Jul 2002 16:10:56 -0700
>    
>    I get the attached output.  Why is this mmx stuff showing up?  And
>    what are the bits about bash?
> 
> GDB exec's a shell to setup your environment properly then execute the
> program to be debugged.  In this way GDB's environemnt doesn't need
> to be altered among other things.
> 

I think Mark has

LD_LIBRARY_PATH=....

somewhere in his bash startup scripts.


H.J.

Re: Weird x86 Linux/GNU crashes

[Daniel Jacobowitz]

On Tue, Jul 30, 2002 at 04:10:56PM -0700, Mark Mitchell wrote:
> 
> >(gdb) set env LD_DEBUG=libs
> >(gdb) run
> 
> I get the attached output.  Why is this mmx stuff showing up?  And
> what are the bits about bash?

First, if you run bash at a prompt does it clobber your
LD_LIBRARY_PATH?  Second, do the built binaries contain an RPATH?  I'd
assume from this output that one of those was happening.

> 
> Thanks,
> 
> -- 
> Mark Mitchell                mark@codesourcery.com
> CodeSourcery, LLC            http://www.codesourcery.com
> 
> Starting program: 
> /home/mitchell/dev/gcc-mainline/objdir/gcc/./bitfield1.exe
> 31457:	find library=libtermcap.so.2; searching
> 31457:	 search 
> path=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3
> /src/.libs/mmx:/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//li
> bstdc++-v3/src/.libs:./mmx:.		(LD_LIBRARY_PATH)
> 31457:	  trying 
> file=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3
> /src/.libs/mmx/libtermcap.so.2
> 31457:	  trying 
> file=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3
> /src/.libs/libtermcap.so.2
> 31457:	  trying file=./mmx/libtermcap.so.2
> 31457:	  trying file=./libtermcap.so.2
> 31457:	 search cache=/etc/ld.so.cache
> 31457:	  trying file=/lib/libtermcap.so.2
> 31457:	
> 31457:	find library=libdl.so.2; searching
> 31457:	 search 
> path=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3
> /src/.libs:./mmx:.		(LD_LIBRARY_PATH)
> 31457:	  trying 
> file=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3
> /src/.libs/libdl.so.2
> 31457:	  trying file=./mmx/libdl.so.2
> 31457:	  trying file=./libdl.so.2
> 31457:	 search cache=/etc/ld.so.cache
> 31457:	  trying file=/lib/libdl.so.2
> 31457:	
> 31457:	find library=libc.so.6; searching
> 31457:	 search 
> path=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3
> /src/.libs:./mmx:.		(LD_LIBRARY_PATH)
> 31457:	  trying 
> file=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3
> /src/.libs/libc.so.6
> 31457:	  trying file=./mmx/libc.so.6
> 31457:	  trying file=./libc.so.6
> 31457:	 search cache=/etc/ld.so.cache
> 31457:	  trying file=/lib/i686/libc.so.6
> 31457:	
> 31457:	
> 31457:	calling init: /lib/i686/libc.so.6
> 31457:	
> 31457:	
> 31457:	calling init: /lib/libdl.so.2
> 31457:	
> 31457:	
> 31457:	calling init: /lib/libtermcap.so.2
> 31457:	
> 31457:	
> 31457:	initialize program: /bin/bash
> 31457:	
> 31457:	
> 31457:	transferring control: /bin/bash
> 31457:	
> 31457:	find library=libstdc++.so.5; searching
> 31457:	 search path=/usr/local/lib/mmx:/usr/local/lib	 (LD_LIBRARY_PATH)
> 31457:	  trying file=/usr/local/lib/mmx/libstdc++.so.5
> 31457:	  trying file=/usr/local/lib/libstdc++.so.5
> 31457:	 search cache=/etc/ld.so.cache
> 31457:	 search path=/lib/mmx:/lib:/usr/lib/mmx:/usr/lib	 (system 
> search path)
> 31457:	  trying file=/lib/mmx/libstdc++.so.5
> 31457:	  trying file=/lib/libstdc++.so.5
> 31457:	  trying file=/usr/lib/mmx/libstdc++.so.5
> 31457:	  trying file=/usr/lib/libstdc++.so.5
> 31457:	
> /home/mitchell/dev/gcc-mainline/objdir/gcc/./bitfield1.exe: error while 
> loading shared libraries: libstdc++.so.5: cannot open shared object file: 
> No such file or directory
> 
> 
> 

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Weird x86 Linux/GNU crashes

[Raja R Harinath]

Hi,

Mark Mitchell <mark@codesourcery.com> writes:

> I've got some changes to the C++ front end that I've tested pretty
> well (make check-g++).  Then, I updated the compiler and rebuilt from
> scratch in preparation for final testing and check-in.  Now, every
> dynamically linked C++ binary crashes, but statically linked ones are
> OK.
>
> The behavior is somewhat odd; GDB seems to get confused:
>
> bash-2.05$ LD_LIBRARY_PATH=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3/src/.libs:. ./bitfield1.exe 
> Segmentation fault

Maybe you should try

  /home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3/libtool --mode=execute ./bitfield1.exe

> bash-2.05$
> LD_LIBRARY_PATH=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3/src/.libs:. gdb
> ./bitfield1.exe 

And

  /home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3/libtool --mode=debug gdb ./bitfield1.exe

That is the supported way to run libtool-built programs in the build
tree.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu

Re: Weird x86 Linux/GNU crashes

[Raja R Harinath]

Raja R Harinath <harinath@cs.umn.edu> writes:

> And
>
>   /home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu//libstdc++-v3/libtool --mode=debug gdb ./bitfield1.exe

That should also be '--mode=execute', actually.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu

Re: Weird x86 Linux/GNU crashes

[Mark Mitchell]

--On Wednesday, July 31, 2002 02:16:03 AM +0200 Michael Matz <matz@suse.de> 
wrote:

> On Tue, 30 Jul 2002, Mark Mitchell wrote:
>
>> And what are the bits about bash?
>
> I forgot to say: gdb actually does a '/bin/bash -c "exec command args"' to
> start the debuggee, so that bash is involved is normal.

Aha, that is what I did not know.  How curious.

Thanks!

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Weird x86 Linux/GNU crashes

[Mark Mitchell]

--On Tuesday, July 30, 2002 11:41:25 PM -0500 Raja R Harinath 
<harinath@cs.umn.edu> wrote:

> Hi,
>
> Mark Mitchell <mark@codesourcery.com> writes:
>
>> I've got some changes to the C++ front end that I've tested pretty
>> well (make check-g++).  Then, I updated the compiler and rebuilt from
>> scratch in preparation for final testing and check-in.  Now, every
>> dynamically linked C++ binary crashes, but statically linked ones are
>> OK.
>>
>> The behavior is somewhat odd; GDB seems to get confused:
>>
>> bash-2.05$
>> LD_LIBRARY_PATH=/home/mitchell/dev/gcc-mainline/objdir/i686-pc-linux-gnu
>> //libstdc++-v3/src/.libs:. ./bitfield1.exe  Segmentation fault

Interesting.

I found the bug -- it was in my changes to the C++ front end -- but I
very much appreciate all the debugging tips.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Weird x86 Linux/GNU crashes

[Joe Buck]

David Miller writes:
> GDB exec's a shell to setup your environment properly then execute the
> program to be debugged.  In this way GDB's environemnt doesn't need
> to be altered among other things.

This "feature" of gdb has caused me nothing but pain over the years; no
other program thinks it needs to "setup your environment properly" rather
than just use the environment as is.  In almost every case where I have
trouble, the environment *was* set up properly before GDB destroyed it by
exec-ing a shell.  Life tends to be worse for csh/tcsh users, but bash
users can also be messed up.

Unfortunately, gdb's developers like it this way, so the rest of us just
have to work around the damage.

Re: Weird x86 Linux/GNU crashes

[Stan Shebs]

Joe Buck wrote:

>David Miller writes:
>
>>GDB exec's a shell to setup your environment properly then execute the
>>program to be debugged.  In this way GDB's environemnt doesn't need
>>to be altered among other things.
>>
>
>This "feature" of gdb has caused me nothing but pain over the years; no
>other program thinks it needs to "setup your environment properly" rather
>than just use the environment as is.  In almost every case where I have
>trouble, the environment *was* set up properly before GDB destroyed it by
>exec-ing a shell.  Life tends to be worse for csh/tcsh users, but bash
>users can also be messed up.
>
>Unfortunately, gdb's developers like it this way, so the rest of us just
>have to work around the damage.
>
Drifting OT I suppose, but I vaguely remember a discussion about adding
an option to choose not to run a subshell at all.  Cygwin has that option
for instance, and I can't imagine it would be that hard to add for Unix
too.  Is there a PR on this?

Stan

>

Re: Weird x86 Linux/GNU crashes

[Daniel Jacobowitz]

On Wed, Jul 31, 2002 at 09:54:05AM -0700, Stan Shebs wrote:
> Joe Buck wrote:
> 
> >David Miller writes:
> >
> >>GDB exec's a shell to setup your environment properly then execute the
> >>program to be debugged.  In this way GDB's environemnt doesn't need
> >>to be altered among other things.
> >>
> >
> >This "feature" of gdb has caused me nothing but pain over the years; no
> >other program thinks it needs to "setup your environment properly" rather
> >than just use the environment as is.  In almost every case where I have
> >trouble, the environment *was* set up properly before GDB destroyed it by
> >exec-ing a shell.  Life tends to be worse for csh/tcsh users, but bash
> >users can also be messed up.
> >
> >Unfortunately, gdb's developers like it this way, so the rest of us just
> >have to work around the damage.
> >
> Drifting OT I suppose, but I vaguely remember a discussion about adding
> an option to choose not to run a subshell at all.  Cygwin has that option
> for instance, and I can't imagine it would be that hard to add for Unix
> too.  Is there a PR on this?

I don't think so.  Please file one and I'll look into it in a couple of
weeks.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Weird x86 Linux/GNU crashes

[Andreas Schwab]

Joe Buck <Joe.Buck@synopsys.com> writes:

|> David Miller writes:
|> > GDB exec's a shell to setup your environment properly then execute the
|> > program to be debugged.  In this way GDB's environemnt doesn't need
|> > to be altered among other things.
|> 
|> This "feature" of gdb has caused me nothing but pain over the years; no
|> other program thinks it needs to "setup your environment properly" rather
|> than just use the environment as is.

It has nothing to do with setting up the environment, but without the
shell you would not be able to specify redirections on the command line.
Every other program that supports shelling out does it the same way.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Weird x86 Linux/GNU crashes

[Phil Edwards]

On Wed, Jul 31, 2002 at 09:33:41AM -0700, Joe Buck wrote:
> David Miller writes:
> > GDB exec's a shell to setup your environment properly then execute the
> > program to be debugged.  In this way GDB's environemnt doesn't need
> > to be altered among other things.
> 
> This "feature" of gdb has caused me nothing but pain over the years; no
> other program thinks it needs to "setup your environment properly" rather
> than just use the environment as is.  In almost every case where I have
> trouble, the environment *was* set up properly before GDB destroyed it by
> exec-ing a shell.  Life tends to be worse for csh/tcsh users, but bash
> users can also be messed up.

This explains so much...  GDB has suddenly become useable for me, now that
I know of this "feature" (and can turn it the #!$& off).


> Unfortunately, gdb's developers like it this way, so the rest of us just
> have to work around the damage.

Freaky.  You'd think if they wanted GDB to run with a different environment,
they'd use env(1) or something when starting the debugger.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Weird x86 Linux/GNU crashes

[Joe Buck]

David Miller writes:
> |> > GDB exec's a shell to setup your environment properly then execute the
> |> > program to be debugged.  In this way GDB's environemnt doesn't need
> |> > to be altered among other things.
> |> 

I wrote:
> |> This "feature" of gdb has caused me nothing but pain over the years; no
> |> other program thinks it needs to "setup your environment properly" rather
> |> than just use the environment as is.

Andreas Schwab writes:
> It has nothing to do with setting up the environment, but without the
> shell you would not be able to specify redirections on the command line.
> Every other program that supports shelling out does it the same way.

Sorry, I don't buy this.  The mistake you are making is that you are
focusing on mechanisms, rather than the behavior that is expected by and
that is useful to the user.  Worse, you are advocating an inefficient
mechanism: invoking a shell even in contexts where a shell is not needed,
when it is this invocation that has harmful effects.

When a user types

% gdb my_program
(gdb) [ set some breakpoints ]
(gdb) run

he or she has no idea that he has done any "shelling out".

Even if he types

(gdb) run arg1 arg2 > out_file

s/he has only asked "put my output in out_file", not "destroy my
environment, keep me from finding my shared libraries, and make me
pull all my hair out".

A shell should only be invoked where one is needed, and it should be
invoked if needed in a minimally disruptive way (no reading of shell
startup files).

At minimum, if there are no meta-characters in the "run" command, execv
should be used directly to start the program.  It is more efficient and
won't trash the environment.

Re: Weird x86 Linux/GNU crashes

[Mark Mitchell]

> % gdb my_program
> (gdb) [ set some breakpoints ]
> (gdb) run
>
> he or she has no idea that he has done any "shelling out".

I will not shell out for a debugger that shells out.

Oh, this one's gratis.

Well, I guess I am a sell-out then; I will use this shell-out debugger....

I'm beginning to feel vaguely like I'm in a Dr. Seuss book, so I'll stop...

> Even if he types
>
> (gdb) run arg1 arg2 > out_file
>
> s/he has only asked "put my output in out_file", not "destroy my
> environment, keep me from finding my shared libraries, and make me
> pull all my hair out".
>
> A shell should only be invoked where one is needed, and it should be
> invoked if needed in a minimally disruptive way (no reading of shell
> startup files).
>
> At minimum, if there are no meta-characters in the "run" command, execv
> should be used directly to start the program.  It is more efficient and
> won't trash the environment.

I couldn't agree more.  This was very confusing to me.  If my program
runs differently under the debugger than it does from the shell,
the debugger is broken -- with very few exceptions, such as programs
that explicitly check to see whether they're running in a debugger.

If we really need shell functionality in GDB, it would be far better
to link in the relevant bash code and use it directly.  I would much
rather make C-shell users use Bourne-shell syntax to do redirections
than create situations where stuff in startup files can change the
behavior of programs run in the debuggger.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Weird x86 Linux/GNU crashes

[Joe Buck]

Mark writes:
> If we really need shell functionality in GDB, it would be far better
> to link in the relevant bash code and use it directly.

In the meantime, the best way to cope is to always write

SHELL=/bin/sh gdb ...

or, for csh/tcsh users

env SHELL=/bin/sh gdb ...

When bash is invoked as /bin/sh and it's not a login shell, it won't try
to read any startup files (DO NOT say SHELL=/bin/bash or similar).