public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* request for stack advice
@ 2004-04-26 17:00 Justin M. Lee
  2004-04-26 18:25 ` Joe Buck
  0 siblings, 1 reply; 2+ messages in thread
From: Justin M. Lee @ 2004-04-26 17:00 UTC (permalink / raw)
  To: gcc

Folks,

I recently inherited some C that crashes when compiled with 3.2-3.3
compilers on Linux x86.  It works on SGI's compiler on Irix and gcc 2.95
on Linux x86.

This code is a bit strange - it puts huge arrays on the stack.  We're
talking about several megs.  In a debugger, it appears that the crash
happens when it tries to touch something on the stack in a particular
call.  I came to realize that I don't understand how stack allocation
works.  Looking at the assembly code, a function doesn't really request
more stack -- it just subtracts from esp.  How does the OS know to
allocate pages to the stack area?  I saw something about stack space in
the ld man page, but it didn't know what I was talking about when I tried
to pass it in via -Xlinker.  Is there a default stack space?

Some more info: it looks to me like the esp is valid at the point of the
crash: its about 8 megs less at the point of the crash than at main.  The
reason I even got here was because I thought the stack was getting
trashed.

At main:
esp 0xbfffe9d0
ebp 0xbffff458

At point of crash
esp 0xbf7ab948
ebp 0xbffe9268

One more thing: removing all this stuff from the stack and mallocing it
fixes the problem.  I'm just curious at this point.

I'm sure this is all either obvious or clearly documented somewhere, but I
couldn't google for it for the life of me.  Feel free to tell me to RTFM
(but please point me to the right chapter).  I only ask here because I'm
trying to figure out if there is something specific in the compiler
differences that could have caused this (and because someone here might
actually know the answers to my questions :) ).

--Justin

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: request for stack advice
  2004-04-26 17:00 request for stack advice Justin M. Lee
@ 2004-04-26 18:25 ` Joe Buck
  0 siblings, 0 replies; 2+ messages in thread
From: Joe Buck @ 2004-04-26 18:25 UTC (permalink / raw)
  To: Justin M. Lee; +Cc: gcc

On Mon, Apr 26, 2004 at 11:41:10AM -0500, Justin M. Lee wrote:
> I recently inherited some C that crashes when compiled with 3.2-3.3
> compilers on Linux x86.  It works on SGI's compiler on Irix and gcc 2.95
> on Linux x86.
> 
> This code is a bit strange - it puts huge arrays on the stack.  We're
> talking about several megs.  In a debugger, it appears that the crash
> happens when it tries to touch something on the stack in a particular
> call.  I came to realize that I don't understand how stack allocation
> works.  Looking at the assembly code, a function doesn't really request
> more stack -- it just subtracts from esp.  How does the OS know to
> allocate pages to the stack area?  I saw something about stack space in
> the ld man page, but it didn't know what I was talking about when I tried
> to pass it in via -Xlinker.  Is there a default stack space?

This is operating system-dependent.  Within a certain size range, the
stack will be automatically grown by the OS, but if this size limit is
exceeded, you'll get faults.

> Some more info: it looks to me like the esp is valid at the point of the
> crash: its about 8 megs less at the point of the crash than at main.  The
> reason I even got here was because I thought the stack was getting
> trashed.

8 megs sounds like the typical default stack size.  It can be changed with
"ulimit" (or "limit" if you use csh or tcsh).

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2004-04-26 16:49 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-26 17:00 request for stack advice Justin M. Lee
2004-04-26 18:25 ` Joe Buck

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).