Trival shell script crashes under 2.4.25

Trival shell script crashes under 2.4.25

[Don Hiatt]

Hello,

  Sorry if this is the wrong list to post to; if it is, could you
please suggest an alternative? :)

  Below you will find a very simple shell script that crashes under
2.4.25 running on a RM9000 (PMC rm7935) with busybox 1.0. This script
just demonstrates the actual problem but I do not believe it is 
isolated to busybox. In fact I wrote a simple program that just does
this:
	* for(;;)
		* fork()
			* mmap file "foo"
			* compare "foo" to an array image
		* waitpid()

and it will run for a while and then SEGFAULT at various times. According
to GDB the stack is corrupted and looking at the PC it does seem bogus
(0x2acf2e50). 

  The program crashes after a random amount of time but generally no more
that a minute or so. I can speed up the process if I ping-flood the target.

  Now what is really wierd is that if I run the program under gdbserver
it doesn't crash (or at least has not in the last 1/2 hour). Does gdbserver
change the execution context differently that gdb??

  Any suggestions would be greatly appreciated. :)

Cheers,

don


# cat die.sh 
#!/bin/sh
while :
do
  echo 1
done


*** RUN #1 ***
1
1
....
./die.sh: 5: echo: Bad address

*** RUN # 2 ***
1
1
1
..
Segmentation fault

*** GDB (6.3) DUMP ***
...
----------
fork()
P(16814) : C(17343) : Count (468)

Program received signal SIGSEGV, Segmentation fault.
0x2acf2e50 in ?? ()
(gdb) .
(gdb) bt
#0  0x2acf2e50 in ?? ()
warning: GDB can't find the start of the function at 0x2acf2e50.

    GDB is unable to find the start of the function at 0x2acf2e50
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x2acf2e50 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
#1  0x2acf2e50 in ?? ()
warning: GDB can't find the start of the function at 0x2acf2e50.
Previous frame identical to this frame (corrupt stack?)
(gdb)


*** CPU INFO ***
~ # cat /proc/cpuinfo 
system type             : ITE QED-4N-S01B
processor               : 0
cpu model               : RM9000 V2.2  FPU V2.0
BogoMIPS                : 897.84
wait instruction        : no
microsecond timers      : yes
tlb_entries             : 64
extra interrupt vector  : no
hardware watchpoint     : no
VCED exceptions         : not available
VCEI exceptions         : not available

Re: Trival shell script crashes under 2.4.25

[Ralf Baechle]

On Wed, Sep 14, 2005 at 04:00:40PM -0700, Don Hiatt wrote:

>   Sorry if this is the wrong list to post to; if it is, could you
> please suggest an alternative? :)

How about linux-mips ;-)

>   Below you will find a very simple shell script that crashes under
> 2.4.25 running on a RM9000 (PMC rm7935) with busybox 1.0. This script
> just demonstrates the actual problem but I do not believe it is 
> isolated to busybox. In fact I wrote a simple program that just does
> this:
> 	* for(;;)
> 		* fork()
> 			* mmap file "foo"
> 			* compare "foo" to an array image
> 		* waitpid()

linux-mips.org has no RM9000 support in it's 2.4 code.  That leaves
it up to guessing what could be happening in your codebase.

> and it will run for a while and then SEGFAULT at various times. According
> to GDB the stack is corrupted and looking at the PC it does seem bogus
> (0x2acf2e50). 

That would be a typical address for a shared library.

>   The program crashes after a random amount of time but generally no more
> that a minute or so. I can speed up the process if I ping-flood the target.
> 
>   Now what is really wierd is that if I run the program under gdbserver
> it doesn't crash (or at least has not in the last 1/2 hour). Does gdbserver
> change the execution context differently that gdb??

Strange indeed.  Both shouldn't affect the state of a running program
as long as it isn't being stopped.

  Ralf