Dear all,
The reason I tried to switch to a newer compiler is that the older compiler crashed on, I suspect, memory usage. Increasing a const that determines the size of a number of arrays causes the crash. Restoring the const to the old value gives a fine compilation. Compiler gpc 20030830, based on gcc-3.2.1 also crashes on a linux machine.
The crashes are consistent in the following way: At a clean start, i.e. after removing all the object and gpi files, the compiler crashes after line 86 in writestruct.p (see below). Subsequent compile runs, with the already compiled .o and .gpi files available, consistently show line 120 of the same file. Could be a --progress-messages thing, not related to the real cause of the crash, but I am not sure.
I do not know how to single out the problem for this case. Aside of posting the backtrace, I am in the dark. Can anyone point me to information on how to attack this problem?
Thanks for your consideration, Regards,
Marten Jan
% uname -a Linux so3 2.4.18-14smp #1 SMP Wed Sep 4 12:34:47 EDT 2002 i686 i686 i386 GNU/Linux
% make_fem <snip> #progress# IO/writestruct.p (86) gpc: Internal error: Segmentation fault (program gpc1) Please submit a full bug report. See URL:http://www.gnu-pascal.de/todo.html for instructions. gpc1: gpc exited with status 1
% gdb \ /cluster3/deruiter/system/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/gpc1 \ core.22274
GNU gdb Red Hat Linux (5.2.1-4) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `/cluster3/deruiter/system/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/gpc1 /tmp/ccgaf2M'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 emit_library_call_value_1 (retval=0, orgfun=0x40014b60, value=0x0, fn_type=1076180224, outmode=VOIDmode, nargs=3, p=0xbfbddaf8 "�@~�\b�\b0۽ zC@\030\t>@\030B\001@") at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/calls.c:3811 3811 memcpy (stack_usage_map, initial_stack_usage_map, (gdb) backtrace #0 emit_library_call_value_1 (retval=0, orgfun=0x40014b60, value=0x0, fn_type=1076180224, outmode=VOIDmode, nargs=3, p=0xbfbddaf8 "�@~�\b�\b0۽ zC@\030\t>@\030B\001@") at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/calls.c:3811 #1 0x081020ed in emit_library_call (orgfun=0xbf7bd370, fn_type=3212563312, outmode=3212563312, nargs=-1082403984) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/calls.c:4228 #2 0x080ac770 in emit_push_insn (x=0x403ecb40, mode=BLKmode, type=0x40294b60, size=0x403e0918, align=1, partial=0, reg=0x0, extra=0, args_addr=0x4024e070, args_so_far=0x527, reg_parm_stack_space=0, alignment_pad=0x40014210) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/expr.c:3467 #3 0x08102702 in store_one_arg (arg=0xbfffe2f8, argblock=0x4024e070, flags=0, variable_size=0, reg_parm_stack_space=0) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/calls.c:4587 #4 0x080ffb23 in expand_call (exp=0x40437640, target=0x0, ignore=1) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/calls.c:2968 #5 0x080b35f3 in expand_expr (exp=0x40437a20, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/expr.c:7379 #6 0x0825c05a in expand_expr_stmt_value (exp=0xbfffe2f8, want_value=1, maybe_last=1076180224) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/stmt.c:2247 #7 0x0825bf91 in expand_expr_stmt (exp=0xbf7bd370) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/stmt.c:2201 #8 0x08051e1b in yyuserAction (yyn=562, yyrhslen=3, yyvsp=0x840e650, yyvalp=0xbfffe88c, yylocp=0xbfffe890, yystack=0xbfffe8f0) at parse.c:4580 #9 0x08058367 in yydoAction (yystack=0xbfffe8f0, yyk=0, yyrule=562, yyvalp=0xbfffe88c, yylocp=0xbfffe890) at parse.c:8218 #10 0x08057ee9 in yyglrReduce (yystack=0xbfffe8f0, yyk=0, yyrule=562, yyforceEval=1 '\001') at parse.c:8290 #11 0x08057436 in main_yyparse () at parse.c:8991 #12 0x080e3954 in compile_file () at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/toplev.c:2124 #13 0x080e85e9 in do_compile () at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/toplev.c:5218 #14 0x080e8659 in toplev_main (argc=-1082403984, argv=0x0) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/toplev.c:5250 #15 0x080f168b in main (argc=-1082403984, argv=0xbf7bd370) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/main.c:35 #16 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
Marten Jan de Ruiter wrote:
Dear all,
The reason I tried to switch to a newer compiler is that the older compiler crashed on, I suspect, memory usage. Increasing a const that determines the size of a number of arrays causes the crash. Restoring the const to the old value gives a fine compilation. Compiler gpc 20030830, based on gcc-3.2.1 also crashes on a linux machine.
The crashes are consistent in the following way: At a clean start, i.e. after removing all the object and gpi files, the compiler crashes after line 86 in writestruct.p (see below). Subsequent compile runs, with the already compiled .o and .gpi files available, consistently show line 120 of the same file. Could be a --progress-messages thing, not related to the real cause of the crash, but I am not sure.
I do not know how to single out the problem for this case. Aside of posting the backtrace, I am in the dark. Can anyone point me to information on how to attack this problem?
It looks that you are passing large arrays by value. Such arrays may cause problems at runtime due to limit on stack usage (by default 10Mb on Linux) -- arguments are passed by value and consume stack space. Unfortunatly, such array consume even more space in the compiler. Try increase stack limit or pass them as `var' parameters (if you want to protect them from modification make them `protected').
FYI crash on programs passing large arrays happens in all versions (including 3.3 and 3.4 backends).
Marten Jan de Ruiter wrote:
The reason I tried to switch to a newer compiler is that the older compiler crashed on, I suspect, memory usage. Increasing a const that determines the size of a number of arrays causes the crash. Restoring the const to the old value gives a fine compilation. Compiler gpc 20030830, based on gcc-3.2.1 also crashes on a linux machine.
The crashes are consistent in the following way: At a clean start, i.e. after removing all the object and gpi files, the compiler crashes after line 86 in writestruct.p (see below). Subsequent compile runs, with the already compiled .o and .gpi files available, consistently show line 120 of the same file. Could be a --progress-messages thing, not related to the real cause of the crash, but I am not sure.
Progress messages are asynchronous. To see exactly how far it gets, try `--debug-source' or `p lineno' under gdb.
Waldek Hebisch wrote:
It looks that you are passing large arrays by value. Such arrays may cause problems at runtime due to limit on stack usage (by default 10Mb on Linux) -- arguments are passed by value and consume stack space. Unfortunatly, such array consume even more space in the compiler.
But only if they are initialized field by field or something like that, shouldn't they?
Am I missing something? AFAICS, Marten didn't show any actual code. The following program compiles fine for me (but crashes with stack overflow when trying to run it).
program Foo;
type a = array [1 .. 100000000] of Integer;
var v: a;
procedure p (v: a); begin end;
begin p (v) end.
Frank
Frank Heckenbach wrote:
Waldek Hebisch wrote:
It looks that you are passing large arrays by value. Such arrays may cause problems at runtime due to limit on stack usage (by default 10Mb on Linux) -- arguments are passed by value and consume stack space. Unfortunatly, such array consume even more space in the compiler.
But only if they are initialized field by field or something like that, shouldn't they?
Am I missing something? AFAICS, Marten didn't show any actual code. The following program compiles fine for me (but crashes with stack overflow when trying to run it).
program Foo;
type a = array [1 .. 100000000] of Integer;
var v: a;
procedure p (v: a); begin end;
begin p (v) end.
Compiles fine with 3.2.3. Crashes with 3.3.3 and 3.4.0. With 20Gb stack limit compiles fine. The following compiles with 2.95.3 but crashes with 3.x:
program foo(output); type ta = string(20000000); var a, b : ta; procedure bar(v : ta); begin write(v) end; procedure baz(u, w : ta); begin write(u); bar(w) end; begin baz(a,b); writeln end .
If I increase stack limit then 3.x works OK.
I could not find anything applicable for me on stack size in the documentation. After some googling I increased the stack size in the tcsh, after which the program compiled fine. Thanks for the help! Now, to me the beautiful task of digging up the culprit in our code, and making it a `var'.
Maybe it is something to put in the docs. I wrote a tiny bit below, after a bit of ranting. Feel free to copy and adapt ( Yes, you have my permission to use and modify the text I shamelessly stole from e-mails you wrote yourself ;-) )
Hopefully I am not too patronizing, but in my opinion, URL:http://www.gnu-pascal.de/todo.html does not give clear directions. It took me some time to find the link URL:http://www.gnu-pascal.de/gpc/Compiler-Crashes.html, which was hidden in `where to get support'. This is actually the page I expected to find following the URL provided in the error message. It might be an improvement to direct the user to that page. On that page, links to the known bugs, planned features, fixed bugs and `where to get support' could help a user solving a compiler crash.
Now for the snippet of documentation:
<Header>Gpc crashed... now what?</Header>
If the compiler crashes with the following error
gpc: Internal error: Segmentation fault (program gpc1) Please submit a full bug report. See URL:http://www.gnu-pascal.de/todo.html for instructions. gpc1: gpc exited with status 1
<FIXME: insert a list of other possible causes, like a link to the known bugs>
a possible cause may be that the operating system provides a too small stack size. This can be verified in the following way: increase the stack size and try to compile the program again.
On Unix-like systems, the stack size can be increased in the shell settings (bash: ulimit; csh: limit; syscall: setrlimit(2)).
For DJGPP (MS-DOS) platforms, see URL:http://www.gnu-pascal.de/gpc/Stack-size.html
A large stack size can be required if large arrays are passed as value. Try passing them as `var' parameters (if you want to protect them from modification make them `protected').
<FIXME: insert other causes of large stack usage.>
Regards, Marten Jan
On Tuesday 11 May 2004 03:44, you wrote:
Frank Heckenbach wrote:
Waldek Hebisch wrote:
It looks that you are passing large arrays by value. Such arrays may cause problems at runtime due to limit on stack usage (by default 10Mb on Linux) -- arguments are passed by value and consume stack space. Unfortunatly, such array consume even more space in the compiler.
But only if they are initialized field by field or something like that, shouldn't they?
Am I missing something? AFAICS, Marten didn't show any actual code. The following program compiles fine for me (but crashes with stack overflow when trying to run it).
program Foo;
type a = array [1 .. 100000000] of Integer;
var v: a;
procedure p (v: a); begin end;
begin p (v) end.
Compiles fine with 3.2.3. Crashes with 3.3.3 and 3.4.0. With 20Gb stack limit compiles fine. The following compiles with 2.95.3 but crashes with 3.x:
program foo(output); type ta = string(20000000); var a, b : ta; procedure bar(v : ta); begin write(v) end; procedure baz(u, w : ta); begin write(u); bar(w) end; begin baz(a,b); writeln end .
If I increase stack limit then 3.x works OK.
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Waldek Hebisch wrote:
It looks that you are passing large arrays by value. Such arrays may cause problems at runtime due to limit on stack usage (by default 10Mb on Linux) -- arguments are passed by value and consume stack space. Unfortunatly, such array consume even more space in the compiler.
But only if they are initialized field by field or something like that, shouldn't they?
Am I missing something? AFAICS, Marten didn't show any actual code. The following program compiles fine for me (but crashes with stack overflow when trying to run it).
program Foo;
type a = array [1 .. 100000000] of Integer;
var v: a;
procedure p (v: a); begin end;
begin p (v) end.
Compiles fine with 3.2.3. Crashes with 3.3.3 and 3.4.0.
Not here:
frank@goedel:~/work# gpc3 --version gpc3 20040423, based on gcc-3.3.3 Copyright (C) 1987-2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
frank@goedel:~/work# gpc3 -O3 -g x.pas frank@goedel:~/work# ./a.out Segmentation fault frank@goedel:~/work#
With 20Gb stack limit compiles fine. The following compiles with 2.95.3 but crashes with 3.x:
program foo(output); type ta = string(20000000); var a, b : ta; procedure bar(v : ta); begin write(v) end; procedure baz(u, w : ta); begin write(u); bar(w) end; begin baz(a,b); writeln end .
Again, this compiles fine here, and crashes at runtime with a "small" stack limit.
OK, I did some more testing. On another machine the compiler crashes indeed. The difference seems to be `ACCUMULATE_OUTGOING_ARGS' which apparently is set there but not here (maybe because of different processors, if it's an optimization thing).
Anyway, I'd consider it at least an important flaw. On the one hand, one may say if the stack usage at compile time is of the same magnitude as run time, it doesn't matter, but on the other hand, the program may be intended to run on another machine with more memory. Also, I don't know exactly, but I suppose the backend does something with the allocated memory, which would slow down compilation (again)-: ...
BTW, is there an option to warn about large (value) parameter sizes, i.e. something like `-Wlarger-than-...', only for parameters?
Frank
On Tue, May 11, 2004 at 06:39:57PM +0200, Frank Heckenbach wrote:
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Waldek Hebisch wrote:
It looks that you are passing large arrays by value. Such arrays may cause problems at runtime due to limit on stack usage (by default 10Mb on Linux) -- arguments are passed by value and consume stack space. Unfortunatly, such array consume even more space in the compiler.
But only if they are initialized field by field or something like that, shouldn't they?
Am I missing something? AFAICS, Marten didn't show any actual code. The following program compiles fine for me (but crashes with stack overflow when trying to run it).
program Foo;
type a = array [1 .. 100000000] of Integer;
var v: a;
procedure p (v: a); begin end;
begin p (v) end.
Compiles fine with 3.2.3. Crashes with 3.3.3 and 3.4.0.
Not here:
frank@goedel:~/work# gpc3 --version gpc3 20040423, based on gcc-3.3.3 Copyright (C) 1987-2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
frank@goedel:~/work# gpc3 -O3 -g x.pas frank@goedel:~/work# ./a.out Segmentation fault frank@goedel:~/work#
The result apparently depends on the optimization level. I get this:
[~/pas]% gpc --version gpc 20030830, based on gcc-3.3.2 Copyright (C) 1987-2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[~/pas]% ulimit -s 10240 [~/pas]% gpc -g bigar.pas gpc: Internal error: Segmentation fault (program gpc1) Please submit a full bug report. See URL:http://www.gnu-pascal.de/todo.html for instructions. [~/pas]% gpc -g -O2 bigar.pas [~/pas]% ./a.out [~/pas]% gpc -g -O3 bigar.pas [~/pas]% ./a.out zsh: segmentation fault ./a.out [~/pas]%
Emil
-
Emil Jerabek -
Frank Heckenbach -
Marten Jan de Ruiter -
Waldek Hebisch