Adriaan van Os wrote:
Gale Paeper wrote:
I wouldn't rely up the lack of a OS stack overflow report as indicative of a small stack size. In one -O3 execution test I ran with 10000 levels of recursion, I got no problems reported; however, the trash stack frame size was still 80 bytes as the assembly code showed.
I am puzzled. I think this *should* be reliable, the way the kernel works. Are you sure ? The difference between our tests is (maybe) you run OS X 10.3, where I run 10.2.
It turns out that it just a difference between Mac OS X 10.2 and 10.3.1 (the version I'm testing under). The default stack size with 10.3.1 according to ulimit is 8192 kbytes. Your recursion.pas and the GPC test programs nonloc2goto.pas and nonloc4goto.pas are well within that stack limit so there wouldn't be any stack overflow to detect. When I increased the number of recursions to 200000 (which should exceed the default stack size limit), I did get a "Segmentation fault".
However, I do have noticed that (on 10.2) "limit stacksize" gets confused when called three or four times in the same terminal window (so I always open a new terminal window before calling "limit stacksize").
Limit isn't a built-in command for bash (the default shell with Mac OS X 10.3). Eventually figured out ulimit was the command to use.
Did you try adding a __UNIXSTACK segment with the linker, e.g.
% gpc -o nonloc2goto nonloc2goto.pas -Wl,-stack_size,0x100000,-stack_addr,0xc0000000
Doesn't have any effect as far as I can tell. I tried that (with the number of recursions set to the original 10000) for both your recursion.pas and nonloc2goto.pas and no stack overflow was detected with the default ulimit stack size of 8192 kbytes.
I also tried varying optimization levels from no optimatization, -O, -O2, and -O3 and all stack frame sizes for thr trash procedure and function was 80 bytes.
Sorry, this is a misunderstanding, --no-inline reduces the stack frame size for "recursion.pas" (the simple testprogram in my previous post) and for "nonloc2goto.pas" but not for "nonloc4goto.pas".
That's interesting. With --no-inline and -O3, the trash procedure in both recursion.pas and nonloc2goto.pas gets tail call optimized with no stack frame at all - just like the C analogue compiled with -O3 (without --no-inline).
I also saw a range of errors (illegal instruction, bus error, malloc deallocation problems) during program termination indicating something was stomping on memory being referenced by the terminating code. (This was seen in some follow up testing with a reduced recursion level to keep the stack in the 512K bounds. With or without Frank's writeln suggestion, I got the expected Pascal output - the errors showed up during termination code execution after the main program code had finished ececuting.) But that may be just bugs in the older gpc version 20030830 I'm testing with and may have been fixed in the new gpc version 20040516.
I tried and didn't witness any difference in behaviour between the various compilers. The problem is that when stack is low, you are no longer running in an environment where anything can be trusted. For example, the Darwin kernel raises SIGSEGV for a stack overflow, then it attempts to create a signal frame on the already-full stack. This sometimes results in SIGBUS being reported, rather than SIGSEGV (see http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00747.html).
As I mentioned above, there was no stack overflow running under Mac OS X 10.3.1 so the stack overflow problems you mention don't apply.
Of the various compilers you tried, was one of them the gpc version 20030830 compiler (with no further patches applied) that you're distributing in the GPC Mac OS X binary package? And did your trials include reducing the number of recursions so there wasn't any stack overflow?
As I noted, with no stack overflow and with the gpc version 20030830 compiler I see range of errors (illegal instruction, bus error, malloc deallocation problems) during program termination for nonloc2goto.pas and nonloc4goto.pas. (I don't see any of those with your recursion.pas so it is most likely a problem related to goto code generation in at least the gpc version 20030830 compiler.)
(I took more detailed notes [e.g., program code changes, outputs, command line used for compiling, etc.] on the errors I was seeing. I can send it to you in private e-mail if you're interested.)
Perhaps the difference in what we're seeing is due to differences in the compiler versions we're using.
Gale Paeper gpaeper@empirenet.com