Board index » cppbuilder » Re: stack overflow

2005-05-17 01:35:36 AM
cppbuilder100
Jonathan Benedicto wrote:
had skipped Linker (learning something every day). The max stack was
0x00100000 (1.05E6). Making it 16 times larger did the trick. Thanks!
 

"Gerrit" < XXXX@XXXXX.COM >wrote in message
Jonathan
 

There can not be a difference between the compilers when the program
is run.
You said the declarations are in the constructor of a TForm and also
said it works with GCC. GCC does not do VCL so cannot do a TForm.
. Ed

{smallsort}

"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >wrote in message
much data off the stack caused a exception to be thrown. So, I forgot
about the fact that the app ran when compiled under gcc.
I'm sorry if I've caused confusion.
Jonathan
 

Here are two descriptions. They both say the same thing. Pick
whichever works best for you.
A new one:
---------------
If you place a normal declaration of something within a function, and
a constructor IS a function, then it is an automatic variable.
Automatic variables are allocated from the stack.
If the declarations are placed where you say, in the constructor of
TForm then their over 7 Megabyte allocation size exceeds that of the 2
Megabyte stack.
The size of the allocation is the source of the a stack overflow.
This problem is not in the compiler. This problem is in the way the
program is written.
---------------
The one from my previous message to which you replied:
---------------
The error suggests that the class instance is allocated as an
automatic variable within a function. Automatic variables are
allocated from the stack.
Windows defaults to providing a huge, 2 Meg stack for each program.
Your single class instance is about 7 Meg. Either do not allocate it
as an automatic variable or set the linker options to have a larger
stack and pray that Windows lets you have the size you requested.
---------------
. Ed

"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >wrote in message
that is asking for a too large stack size. I found this out by
experience a year ago when working on a project.
allocated the memory off the heap.
Thank you for your patience and for giving all this info and help.
Jonathan
 

"Gerrit" < XXXX@XXXXX.COM >wrote in message
that you should probably use the heap. Like this:
typedef std::string StdString;
typedef std::vector<StdString>StrVector;
typedef std::vector<StrVector>StrVector2D;
typedef std::vector<long double>LDVector;
typedef std::vector<LDVector>LDVector2D;
typedef std::vector<LDVector2D>LDVector3D;
int x;
int y;
StrVector2D t1;
LDVector3D t2;
AnsiString Str;
t1.resize(6);
for(x=0;x<t1.size();x++)
t1[x].resize(46656);
t2.resize(7);
for(x=0;x<t2.size();x++)
{
t2[x].resize(1040);
for(y=0;y<t2[x].size();y++)
t2[x][y].resize(7);
}
Now use t1[x][y] and t2[x][y][z];
Please correct me anyone in any mistakes I have made. This is the
first time I'm doing multi-dimensional arrays with std::vector.
HTH
Jonathan
 

A discussion from .delphi.nativeapi.win32 (Delphi apps terminates...).
Using a code to produce a stack overflow, why the error is raised once?
The second time, the program just terminates whitout error. Inside the IDE,
we get an access violation with faulted message.
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls,
Forms,
Dialogs, StdCtrls;
type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
procedure TheStackanator;
end;
var
Form1: TForm;
implementation
{$R *.dfm}
{ TForm1 }
procedure TForm1.TheStackanator;
var
buff : array[0..100] of char;
begin
FillChar( buff, SizeOf( Buff ), #0 );
TheStackanator;
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
TheStackanator;
end;
end.
 

The stack is allocated when used; that is: the page just below the
currently allocated stack is marked as a "guard" page. When it's used
Windows gets notified, and will add a page to the stack.
I guess stack overflow is detected by having an additional page below
the allowable stack which, when triggered, causes the stack overflow.
After this page has been triggered it would then no longer be possible
to distinguish between stack overflow and an ordinary access violation.
Note that this is mainly guessing; if the guard page is really removes
requires looking up or testing (for example using VirtualProtect).
 

Implementatation of stack growth:
support.microsoft.com/default.aspx
Description of the problem (Section: Trapping the Exception with __try
and __except (Full Solution))
support.microsoft.com/default.aspx
<quote>
If a thread in your application causes an EXCEPTION_STACK_OVERFLOW
exception, then your thread has left its stack in a damaged state.
</quote>
<quote>
Notice an important point here: Your stack no longer has a guard page.
The next time that your program grows the stack all the way to the end
(where there should be a guard page), your program writes beyond the
end of the stack and causes an access violation.
</quote>
If you really need to recover from a stack overflow the text describes
how to do it.
 

The problem is when the stack overflow is inside third party tools.
I'm trying AQTime and it seens to catch the point where the app is being
terminated.
Thanks a lot!
Bruno
"Avatar Zondertau" < XXXX@XXXXX.COM (please reply to newsgroup)>escreveu
na mensagem news:429dae77$ XXXX@XXXXX.COM ...

"Steven" < XXXX@XXXXX.COM >wrote:
that familure with it so I would just add a series of calls
to ShowMessage.
~ JD
 

While debugging my program I get a stack overflow
error. I don't have a clue where its coming from, I
have breakpoints in my program, but I end up looking
at the machine part of the de{*word*81} when it breaks.
I am not sure where to go from there since it's not crashing
within the program where I can see and understand what I
am looking at. Can someone tell me what I need to do to
track down the problem.
Steven
 

"JD" < XXXX@XXXXX.COM >wrote in message
Steven
 

"Steven" < XXXX@XXXXX.COM >wrote in message
placing more and more parameter values on the stack until there is no space
left. Do you have any recursive functions in your code? If all you can see
is machine code in the de{*word*81}, then the error likely happened inside a
library. If you move the CPU view around a little, do you see any function
names displayed? What happens if you step through the instruction calls one
at a time until you find more function calls?
Gambit