Stack variables

Stack variables

[Rauli Ruohonen]

I recently debugged a program (a version of paradise netrek server)
that had a small bug like this:

void foobaz(void)
{
	char str[80];

	str[0]=0;
	while(something) { strcat(str,something_else); }
}

Since there were no checks, it eventually overwrote its stack. When I
debugged it with GDB, I just got a notification "SIGSEGV received", and
stack trace gave only one address: 0. Nothing else. Eventually I figured
it out, but I think that it shouldn't be this easy to screw your stack..

I usually use Electric Fence to debug programs, but in this case it was of
no use since it can't put an unmapped page before/after a stack variable.
After a while I thought of a simple solution: What about having a
debugging option in gcc that would allocate all stack variables with
malloc()? This would slow down the program, yes, but since it would be a
debugging option, it wouldn't matter.

I haven't even looked at gcc sources, so I probably wouldn't be able to
implement it, but it would be nice to see this in a future version of
egcs..

Re: Stack variables

[Jeffrey A Law]

  In message < 199801172114.XAA24914@fishy.pp.sci.fi >you write:
  > Since there were no checks, it eventually overwrote its stack. When I
  > debugged it with GDB, I just got a notification "SIGSEGV received", and
  > stack trace gave only one address: 0. Nothing else. Eventually I figured
  > it out, but I think that it shouldn't be this easy to screw your stack..
Welcome to the wonderful world of unix.

  > I usually use Electric Fence to debug programs, but in this case it was of
  > no use since it can't put an unmapped page before/after a stack variable.
  > After a while I thought of a simple solution: What about having a
  > debugging option in gcc that would allocate all stack variables with
  > malloc()? This would slow down the program, yes, but since it would be a
  > debugging option, it wouldn't matter.
It's an interesting thought, but separating the stack variables from
other uses of the stack might be rather difficult.  There's also significant
code in the compiler which knows special things about the stack or frame
poiner (look for stack_pointer_rtx in reload*.c and many other files).

jeff

Re: Stack variables

[amylaar]

> It's an interesting thought, but separating the stack variables from
> other uses of the stack might be rather difficult.  There's also significant
> code in the compiler which knows special things about the stack or frame
> poiner (look for stack_pointer_rtx in reload*.c and many other files).

Well, what we could do without rewriting significant parts of the compiler
would be to add two extra stack pages in the prologue, and unmap a properly
aligned page in that area.  The epilogue would then have to clean this up.
This should be possible even in a machine description, so no backend
patches would be needed.

Re: Stack variables

[Marc Lehmann]

On Tue, Jan 20, 1998 at 08:13:54AM -0700, Jeffrey A Law wrote:
>   > I usually use Electric Fence to debug programs, but in this case it was of
>   > no use since it can't put an unmapped page before/after a stack variable.
>   > After a while I thought of a simple solution: What about having a
>   > debugging option in gcc that would allocate all stack variables with
>   > malloc()? This would slow down the program, yes, but since it would be a
>   > debugging option, it wouldn't matter.
> It's an interesting thought, but separating the stack variables from
> other uses of the stack might be rather difficult.  There's also significant
> code in the compiler which knows special things about the stack or frame
> poiner (look for stack_pointer_rtx in reload*.c and many other files).

Even more, pages are often 4k or larger in size, and each malloc (under
many memory checkers like efence) allocate at least one page.

i.e. in a normla program, instead of using, say 10k of memory, it'll use
10Mb, so I don't think this is feasible...

the bounds-checking code (like the one from gcc with bounds checking)
seems a more promising approach which catches many of these bugs
while not introducing much runtime overhead.

      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |