Stack overflow detection

[LemonParty]

How exactly determine that stack overflow occured?
Is this happening when protected page accessed?
How program distinguish between regular segmentation fault and stack overflow?

[LeP]

When you fill your stack ?
Stack has a size (can be enlarged if necessary), and when a program fills the stack the error is generated.

Normally this happen with recursive call (a function that call itself a never stopped to do this).
I think (sure in the old times, now I don't know) the stack overflow is an hardware error (I mean generated by CPU) and cannot be recovered.

[n7800]

The best way to find out is to test ))

Code: Pascal  [Select][+][-]

1. program Project1;
2.  
3.   procedure Test;
4.   begin
5.     Test;
6.   end;
7.  
8. begin
9.   Test;
10. end.

Play around with this code, running it with different build modes (compiler options). For example, I see that when running in release mode, for some reason it doesn't produce any errors and hangs with the entire CPU core loaded...

[Warfley]

Depends on the platform. On embedded platforms you don't. You just have one memory space that you fill up from two sides (heap and stack). On windows the os inserts a stack guard page right after the stack, so when you try to write to it and the stack overflow is detected. Linux does something similar but I dont know how it's called.
You can change the size of the stack (and thereby the location of the stack guard page) in both systems in case you need more stack space for some reason

[PascalDragon]

How program distinguish between regular segmentation fault and stack overflow?

An exception due to stack overflow will be of type EStackOverflow (assuming the operating system reports it as such (Windows does, I think *nix based systems do, too), otherwise it will likely be an EAccessViolation and you'll have to check the fault address against the stack area).

[LemonParty]

Compiler insert some code to check if current procedure/function will out of stack or how it happening?
If I decrease esp/rsp on the current stack size will it trigger imediatelly a stack overflow?

[n7800]

Meanwhile, I figured out why the program in the comment above stops throwing an exception in the release and simply hangs. This is due to the optimization level being increased from "-O1" to "-O2". Isn't this a bug?

[PascalDragon]

Meanwhile, I figured out why the program in the comment above stops throwing an exception in the release and simply hangs. This is due to the optimization level being increased from "-O1" to "-O2". Isn't this a bug?

Very likely. Please report with a small, self contained example.

[n7800]

Meanwhile, I figured out why the program in the comment above stops throwing an exception in the release and simply hangs. This is due to the optimization level being increased from "-O1" to "-O2". Isn't this a bug?

Very likely. Please report with a small, self contained example.

Um, this one? ))

I checked it with a trunk, the behavior is the same (although my FPC trunk hasn't been updated for a couple of months).

If I remember correctly, the absence of the "Classes" and "SysUtils" units can affect exception behavior, but adding them in this example also doesn't change anything. And I don't think this should be affected by optimization.

[ALLIGATOR]

Meanwhile, I figured out why the program in the comment above stops throwing an exception in the release and simply hangs. This is due to the optimization level being increased from "-O1" to "-O2". Isn't this a bug?

This isn't a bug; most likely, your simplified example simply stops using the stack in the recursive call, replacing the call instruction with a jmp

Code: Pascal  [Select][+][-]

1. program app;
2.  
3. var
4.   Glob: Byte;
5.  
6.   procedure Test;
7.   begin
8.     Test;
9.     Glob := 0;
10.   end;
11.  
12. begin
13.   Test();
14. end.

[Khrys]

This isn't a bug; most likely, your simplified example simply stops using the stack in the recursive call, replacing the call instruction with a jmp

Yeah, that's it.
Note that it's also possible to specify  {$optimization notailrec}  to disable tail call optimization.