Steve Loft wrote:
I'm using gpc 20010115 on a Linux system. I'm having problems with a program I've written which has recursive function calls, which I thought may be down to blowing the stack.
If I run the program in gdb, when it crashes I can't get it to display a backtrace:
Program received signal SIGSEGV, Segmentation fault. 0x240804e7 in ?? () (gdb) bt #0 0x240804e7 in ?? () Cannot access memory at address 0xbabffff5
So I compiled it with --stack-checking, and now it crashes much earlier, with a segmentation fault on a 'var' statement. It's at about 20 levels of recursion, and the function only uses three of four integers of local variables; uname -s tells me I have 8196k of stack, so I'm puzzled as to why I'm blowing the stack, if indeed I am.
Without seeing the code I can only guess. GPC uses stack, e.g., for temporary expressions. Strings (and large sets), in particular, can eat up much stack rather quickly.
You can use the built-in (since 2000-04-11) routine FrameAddress to get the current stack (frame) position. If you check it in some critical routines, you might be able to get an idea how much stack is used in each call.
program WasteStack;
procedure Recursive; begin Writeln (PtrCard (FrameAddress (0))); Recursive end;
begin Recursive end.
If it turns out that, say, most of the stack waste is due to a complicated string operation in the recursive routine, you could solve the problem by encapsulating it in a local subroutine (which will return, and therefore free its temporary storage, before the recursive call).
Is a SIGSEGV what you would expect to see as a result of turning on stack checking?
Depends on the OS, I think. On Linux, it's SIGSEGV, on some other systems it might also be SIGBUS etc...
Frank