Adriaan van Os wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
fjf582.pas Segmentation fault stack overflow (solved with "limit stacksize 2048")
Still? I thought I'd avoided this by using subroutines, but apparently inlining spoiled this attempt. Try adding:
{ FLAG --no-inline-functions }
TEST fjf582.orig.pas: ./test_run: line 202: 2647 Segmentation fault ./"$A_OUT" "$1" TEST fjf582.pas: ./test_run: line 202: 2774 Segmentation fault ./"$A_OUT" "$1"
The backtraces look like this:
I see, a single array is too big already. Well, perhaps we should just declare types instead of variables, to leave the stack alone. It's a rather silly issue, anyway.
--- p/test/fjf582.pas.orig Thu Mar 27 18:35:06 2003 +++ p/test/fjf582.pas Thu Mar 27 18:35:32 2003 @@ -16,11 +16,11 @@ can't make it a `for' loop counter or so. So we use a macro here. } {$define PREPARETEST(n) procedure TestProc##n; +type i = packed array [1 .. $8000] of Integer (n); +type c = packed array [1 .. $8000] of Cardinal (n); +type w = packed array [1 .. $8000] of Word (n); +type b = packed array [1 .. $8000] of Boolean (n); begin - var i: packed array [1 .. $8000] of Integer (n); - var c: packed array [1 .. $8000] of Cardinal (n); - var w: packed array [1 .. $8000] of Word (n); - var b: packed array [1 .. $8000] of Boolean (n); Check (SizeOf (i), $1000 * n, 'i', n); Check (SizeOf (c), $1000 * n, 'c', n); Check (SizeOf (w), $1000 * n, 'w', n);
fjf664.pas Segmentation fault stack overflow (solved with "limit stacksize 2048")
Try this one.
TEST fjf664.pas: gpc: Internal error: Illegal instruction (program gpc1) TEST fjf664.orig.pas: gpc: Internal error: Illegal instruction (program gpc1)
Both produce a gpc internal error (not a Segmentation fault as I reported earlier, I apologize).
For fjf664.pas the backtrace looks like this: That was the wrong one. Here is the correct backtrace for fjf664.pas:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbff7ffc0
Thread 0 Crashed: #0 0x000d04b0 in ggc_alloc (ggc-page.c:858) #1 0x000e5ffc in rtx_alloc (rtl.c:334) #2 0x000c4248 in copy_rtx_if_shared (emit-rtl.c:2593) #3 0x000c41c8 in copy_rtx_if_shared (emit-rtl.c:2613) #4 0x000c41c8 in copy_rtx_if_shared (emit-rtl.c:2613) #5 0x000c41c8 in copy_rtx_if_shared (emit-rtl.c:2613) #6 0x000c41c8 in copy_rtx_if_shared (emit-rtl.c:2613)
<last line repeats> ......
Just to be sure, this is also fixed with a bigger stack size? So it's the compiler's stack that overruns this time (in contrast to fjf582 where it was the compiled program's stack).
In this case, the test may just be too big (for the default stack size), and all I could do is to split it up.
Does it make any difference if you remove some of the procedures t1, t2, t3, t4 or some of the lines in the CN macro?
Frank