Stack overflow ошибка delphi

Call the function «DoStackOverflow» once from your code and you’ll get the EStackOverflow error raised by Delphi with the message «stack overflow».

​function DoStackOverflow : integer;

begin

 result := 1 + DoStackOverflow;

end;

What is this «stack» and why there is an overflow there using the code above?

So, the DoStackOverflow function is recursively calling itself — without an «exit strategy» — it just keeps on spinning and never exits.

A quick fix, you would do, is to clear the obvious bug you have, and ensure the function exists at some point (so your code can continue executing from where you have called the function).

You move on, and you never look back, not caring about the bug/exception as it is now solved.

Yet, the question remains: what is this stack and why is there an overflow?

Memory in Your Delphi Applications

When you start programming in Delphi, you might experience bug like the one above, you would solve it and move on. This one is related to memory allocation. Most of the time you would not care about memory allocation as long as you free what you create.

As you gain more experience in Delphi, you start creating your own classes, instantiate them, care about memory management and alike.

You will get to the point where you will read, in the Help, something like «Local variables (declared within procedures and functions) reside in an application’s stack.» and also Classes are reference types, so they are not copied on assignment, they are passed by reference, and they are allocated on the heap.

So, what is «stack» and what is «heap»?

Running your application on Windows, there are three areas in the memory where your application stores data: global memory, heap, and stack.

Global variables (their values/data) are stored in the global memory. The memory for global variables is reserved by your application when the program starts and remains allocated until your program terminates. The memory for global variables is called «data segment».

Since global memory is only once allocated and freed at program termination, we do not care about it in this article.

Stack and heap are where dynamic memory allocation takes place: when you create a variable for a function, when you create an instance of a class when you send parameters to a function and use/pass its result value.

What Is Stack?

When you declare a variable inside a function, the memory required to hold the variable is allocated from the stack. You simply write «var x: integer», use «x» in your function, and when the function exits, you do not care about memory allocation nor freeing. When the variable goes out of scope (code exits the function), the memory which was taken on the stack is freed.

The stack memory is allocated dynamically using the LIFO («last in first out») approach.

In Delphi programs, stack memory is used by

• Local routine (method, procedure, function) variables.
• Routine parameters and return types.
• Windows API function calls.
• Records (this is why you do not have to explicitly create an instance of a record type).

You do not have to explicitly free the memory on the stack, as the memory is auto-magically allocated for you when you, for example, declare a local variable to a function. When the function exits (sometimes even before due to Delphi compiler optimization) the memory for the variable will be auto-magically freed.

Stack memory size is, by default, large enough for your (as complex as they are) Delphi programs. The «Maximum Stack Size» and «Minimum Stack Size» values on the Linker options for your project specify default values — in 99.99% you would not need to alter this.

Think of a stack as a pile of memory blocks. When you declare/use a local variable, Delphi memory manager will pick the block from the top, use it, and when no longer needed it will be returned back to the stack.

Having local variable memory used from the stack, local variables are not initialized when declared. Declare a variable «var x: integer» in some function and just try reading the value when you enter the function — x will have some «weird» non-zero value. So, always initialize (or set value) to your local variables before you read their value.

Due to LIFO, stack (memory allocation) operations are fast as only a few operations (push, pop) are required to manage a stack.

What Is Heap?

A heap is a region of memory in which dynamically allocated memory is stored. When you create an instance of a class, the memory is allocated from the heap.

In Delphi programs, heap memory is used by/when

• Creating an instance of a class.
• Creating and resizing dynamic arrays.
• Explicitly allocating memory using GetMem, FreeMem, New and Dispose().
• Using ANSI/wide/Unicode strings, variants, interfaces (managed automatically by Delphi).

Heap memory has no nice layout where there would be some order is allocating blocks of memory. Heap looks like a can of marbles. Memory allocation from the heap is random, a block from here than a block from there. Thus, heap operations are a bit slower than those on the stack.

When you ask for a new memory block (i.e. create an instance of a class), Delphi memory manager will handle this for you: you’ll get a new memory block or a used and discarded one.

The heap consists of all virtual memory (RAM and disk space).

Manually Allocating Memory

Now that all about memory is clear, you can safely (in most cases) ignore the above and simply continue writing Delphi programs as you did yesterday.

Of course, you should be aware of when and how to manually allocate/free memory.

The «EStackOverflow» (from the beginning of the article) was raised because with each call to DoStackOverflow a new segment of memory has been used from the stack and stack has limitations. As simple as that.

← →
scout
 
(2003-05-03 20:31)
[0]

Ну беда!!! При запуске проекта вылетает сообщение:

Project lala.exe raised exception class EStackOverflow with message «Stack Overflow». Process stopped.

Что это такое и как с этим бороться?

---

← →
Anatoly Podgoretsky
 
(2003-05-03 20:49)
[1]

Бережнее относиться к стеку, не бездонный.

---

← →
default
 
(2003-05-03 21:36)
[2]

---

← →
Aldor
 
(2003-05-03 22:04)
[3]

Означает переполнение стека. Надо смотреть код. Стек заполняется, например, при объявлении локальных переменных и вызовах процедур. Наиболее частая причина переполнения стека — слишком глубокая рекурсия, возможно без условия выхода.

Иногда ошибку можно найти, используя отладочное окно Call Stack

(View -> Debug Windows -> Call Stack). Удачи!

---

← →
scout
 
(2003-05-04 21:45)
[4]

> Наиболее частая причина переполнения стека — слишком глубокая рекурсия, возможно без условия выхода.

Ну ты и загнул попроще нельзя.

---

← →
Arch-vile
 
(2003-05-04 23:19)
[5]

>
> Наиболее частая причина переполнения стека — слишком глубокая >рекурсия, возможно без условия выхода.

>Ну ты и загнул попроще нельзя.

рекурсия — обратный вызов процедуры, т.е. когда она сама себя вызывает. Например

procedure xxx(i:integer);

begin

xxx(i);

end;

вот тебе и обратный вызов, рекурсия. может быть через 2-3 функции-процедуры:

procedure xxx(i:integer);

begin

yyy(i);

end;

procedure yyy(i:integer);

begin

xxx(i);

end;

---

← →
Arch-vile
 
(2003-05-04 23:21)
[6]

ну типа того, может быть сложнее, и не обязательно
i в качестве переменной

---

← →
k-man
 
(2003-05-05 18:35)
[7]

К вопросу понимания стека…

Попытаюсь предположить почему при глубокой рекурсии переполнятся стек.

Насколько я знаю 1)стек не бездонный.

2)в него при вызове процедур ложатся все (
не только они но все же по-моему они здесь стек и забивают)
К вопросу понимания стека…

Попытаюсь предположить почему при глубокой рекурсии переполнятся стек.

Насколько я знаю 1)стек не бездонный.

2)в него при вызове процедур ложатся все передаваемые аргументы(не только они но все же по-моему они здесь стек и забивают).

Может быть поэтому при глубокой рекурсии стек переполняется.

Так как эти параметров, точек возврата и т.д. становится слишком много..

Хотя это лишь предположение…. Вполне возможно ошибочное..

---

← →
Aldor
 
(2003-05-05 20:16)
[8]

---

← →
k-man
 
(2003-05-05 22:00)
[9]

А вот что интересно: От чего зависит размер стека?

И можно ли его как-то контролировать? Лично я сомневаюсь…

---

← →
Palladin
 
(2003-05-06 14:17)
[10]

> k-man © (05.05.03 22:00)



от установки

{$M}

---

← →
Alek Aaz
 
(2003-05-07 03:54)
[11]

ИМХО. Если в алгоритме есть логическая ошибка {$M} не поможет. Программа засрет все что можно.

---

← →
Palladin
 
(2003-05-07 08:47)
[12]

естественно

---

← →
Aldor
 
(2003-05-07 09:36)
[13]

Как? У ваc еще нет нового процессора Intel Pentium V, выполняющего бесконечный цикл за 6 секунд? :)))

---

← →
k-man
 
(2003-05-07 12:38)
[14]

> Как? У ваc еще нет нового процессора Intel Pentium V, выполняющего

> бесконечный цикл за 6 секунд? :)))



Слышал что это из рекламы суперкомпа Cray.

---

← →
Aldor
 
(2003-05-07 21:51)
[15]

2k-man

Не важно, это просто шутка

---

← →
Aldor
 
(2003-05-07 21:51)
[16]

2k-man

Неважно, это просто шутка

---

← →
k-man
 
(2003-05-07 22:34)
[17]

Неплохая шутка-)

---