I have discovered code generation problem on AMD64. The patch below corrects code generation. It causes spurious warnings in some other tests (fjf1014.pas, fjf1021h.pas, fjf1021i.pas, fjf768c.pas, fjf768e.pas, fjf768f.pas) but those will require separate fix.
In principle other platforms may be affected -- in particular the problem on Mac OSX looks related.
diff -u p.orig/expressions.c p/expressions.c --- p.orig/expressions.c 2005-02-16 04:38:36.000000000 +0100 +++ p/expressions.c 2005-02-19 05:17:58.200156608 +0100 @@ -259,20 +259,23 @@ { tree cond, t; int side_effects = TREE_SIDE_EFFECTS (expr); - expr = save_expr (expr); - if (TREE_CODE (expr) == SAVE_EXPR) - TREE_SIDE_EFFECTS (expr) = side_effects; - cond = chklo ? build_implicit_pascal_binary_op (LT_EXPR, expr, min) : NULL_TREE; + tree tmpvar = make_new_variable("range_check", TREE_TYPE (expr)); + tree tv; + cond = chklo ? build_implicit_pascal_binary_op (LT_EXPR, tmpvar, min) : NULL_TREE; if (chkhi) { - tree cond2 = build_implicit_pascal_binary_op (GT_EXPR, expr, max); + tree cond2 = build_implicit_pascal_binary_op (GT_EXPR, tmpvar, max); cond = cond ? build_pascal_binary_op (TRUTH_ORIF_EXPR, cond, cond2) : cond2; } - t = save_expr (build (COND_EXPR, TREE_TYPE (expr), cond, build (COMPOUND_EXPR, - TREE_TYPE (expr), build_predef_call (co->range_checking > 1 ? p_IORangeCheckError : p_RangeCheckError, - NULL_TREE), expr), expr)); - if (TREE_CODE (t) == SAVE_EXPR) - TREE_SIDE_EFFECTS (t) = side_effects; + t = build (COMPOUND_EXPR, TREE_TYPE (expr), + build_predef_call (co->range_checking > 1 ? p_IORangeCheckError : p_RangeCheckError, + NULL_TREE), tmpvar); + t = build (COND_EXPR, TREE_TYPE (expr), cond, t, tmpvar); + tv = build (MODIFY_EXPR, TREE_TYPE (expr), tmpvar, expr); + PASCAL_VALUE_ASSIGNED (tmpvar) = 1; + TREE_SIDE_EFFECTS (tv) = 1; + t = build (COMPOUND_EXPR, TREE_TYPE (expr), tv, t); + TREE_SIDE_EFFECTS (t) = side_effects; return t; } }
On 19 Feb 2005 at 5:36, Waldek Hebisch wrote:
I have discovered code generation problem on AMD64. The patch below corrects code generation. It causes spurious warnings in some other tests (fjf1014.pas, fjf1021h.pas, fjf1021i.pas, fjf768c.pas, fjf768e.pas, fjf768f.pas) but those will require separate fix.
[...]
Didn't help with the Mingw problem. I ran xgpc.exe through gdb, it tells me that there was an access violation in strncmp(). Have no idea what that is all about - but the previous snapshots don't cause this access violation, so it doesn't seem like a library issue ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 19 Feb 2005 at 5:36, Waldek Hebisch wrote:
I have discovered code generation problem on AMD64. The patch below corrects code generation. It causes spurious warnings in some other tests (fjf1014.pas, fjf1021h.pas, fjf1021i.pas, fjf768c.pas, fjf768e.pas, fjf768f.pas) but those will require separate fix.
[...]
Didn't help with the Mingw problem. I ran xgpc.exe through gdb, it tells me that there was an access violation in strncmp(). Have no idea what that is all about - but the previous snapshots don't cause this access violation, so it doesn't seem like a library issue ...
Can you post a complete traceback or at least error position? (There are many strncmp's in gpc.c, and know which one it is might help.)
Frank
On 19 Feb 2005 at 14:50, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
On 19 Feb 2005 at 5:36, Waldek Hebisch wrote:
I have discovered code generation problem on AMD64. The patch below corrects code generation. It causes spurious warnings in some other tests (fjf1014.pas, fjf1021h.pas, fjf1021i.pas, fjf768c.pas, fjf768e.pas, fjf768f.pas) but those will require separate fix.
[...]
Didn't help with the Mingw problem. I ran xgpc.exe through gdb, it tells me that there was an access violation in strncmp(). Have no idea what that is all about - but the previous snapshots don't cause this access violation, so it doesn't seem like a library issue ...
Can you post a complete traceback or at least error position? (There are many strncmp's in gpc.c, and know which one it is might help.)
Attached ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
(Mingw)/src/mingw/gcc-3.2.3/build/gcc $gdb xgpc.exe GNU gdb 6.3 Copyright 2004 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 "i686-pc-mingw32"... Breakpoint 1 at 0x404446: file ../../gcc/p/gpc.c, line 7569. Breakpoint 2 at 0x4141a0 Breakpoint 3 at 0x414250 (gdb) run Starting program: c:\src\mingw\gcc-3.2.3\build\gcc/xgpc.exe gdb: do_initial_child_stuff: process 2488 gdb: kernel event for pid=2488 tid=2736 code=CREATE_PROCESS_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 2488.0xab0 ContinueDebugEvent (cpid=2488, ctid=2736, DBG_CONTINUE); gdb: kernel event for pid=2488 tid=2736 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 2488.0xab0 ContinueDebugEvent (cpid=2488, ctid=2736, DBG_CONTINUE); gdb: kernel event for pid=2488 tid=2736 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 2488.0xab0 ContinueDebugEvent (cpid=2488, ctid=2736, DBG_CONTINUE); gdb: kernel event for pid=2488 tid=2736 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 2488.0xab0 ContinueDebugEvent (cpid=2488, ctid=2736, DBG_CONTINUE); gdb: kernel event for pid=2488 tid=2736 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 2488.0xab0 ContinueDebugEvent (cpid=2488, ctid=2736, DBG_CONTINUE); gdb: kernel event for pid=2488 tid=2736 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 2488.0xab0 ContinueDebugEvent (cpid=2488, ctid=2736, DBG_CONTINUE); gdb: kernel event for pid=2488 tid=2736 code=EXCEPTION_DEBUG_EVENT) gdb: Target exception EXCEPTION_BREAKPOINT at 0x7c901230 gdb: child_resume.SetThreadContext: thread 2488.0xab0 ContinueDebugEvent (cpid=2488, ctid=2736, DBG_CONTINUE); gdb: kernel event for pid=2488 tid=2736 code=EXCEPTION_DEBUG_EVENT) gdb: Target exception EXCEPTION_ACCESS_VIOLATION at 0x77c47a64
Program received signal SIGSEGV, Segmentation fault. 0x77c47a64 in strncmp () (gdb) info line *0x77c47a64 No line number information available for address 0x77c47a64 <strncmp+20>
Can you post a complete traceback or at least error position? (There are many strncmp's in gpc.c, and know which one it is might help.)
Attached ...
<snip>
Program received signal SIGSEGV, Segmentation fault. 0x77c47a64 in strncmp () (gdb) info line *0x77c47a64 No line number information available for address 0x77c47a64 <strncmp+20>
can you type `bt' here (to get the calling place)?
On 19 Feb 2005 at 17:33, Waldek Hebisch wrote:
Can you post a complete traceback or at least error position? (There are many strncmp's in gpc.c, and know which one it is might help.)
Attached ...
<snip> > Program received signal SIGSEGV, Segmentation fault. > 0x77c47a64 in strncmp () > (gdb) info line *0x77c47a64 > No line number information available for address 0x77c47a64 > <strncmp+20>
can you type `bt' here (to get the calling place)?
Program received signal SIGSEGV, Segmentation fault. 0x77c47a64 in strncmp () (gdb) bt #0 0x77c47a64 in strncmp () #1 0x0040f24d in update_path (path=0x0, key=0x4191f7 "GCC") at ../../gcc/prefix.c:256 During symbol reading, Incomplete CFI data; unspecified registers at 0x0040f229. During symbol reading, Incomplete CFI data; unspecified registers at 0x0040f229. During symbol reading, Incomplete CFI data; unspecified registers at 0x0040f229. During symbol reading, Incomplete CFI data; unspecified registers at 0x0040f229. #2 0x0040284f in add_prefix (pprefix=0x415024, prefix=0x0, component=0x0, priority=1, require_machine_suffix=0, warn=0x0, os_multilib=0) at ../../gcc/p/gpc.c:3207 During symbol reading, Incomplete CFI data; unspecified registers at 0x0040280d. During symbol reading, Incomplete CFI data; unspecified registers at 0x0040280d. During symbol reading, Incomplete CFI data; unspecified registers at 0x0040280d. During symbol reading, Incomplete CFI data; unspecified registers at 0x0040280d. #3 0x0040898e in process_command (argc=2, argv=0x3d2588) at ../../gcc/p/gpc.c:3888 During symbol reading, Incomplete CFI data; unspecified registers at 0x0040861c. During symbol reading, Incomplete CFI data; unspecified registers at 0x0040861c. During symbol reading, Incomplete CFI data; unspecified registers at 0x0040861c. During symbol reading, Incomplete CFI data; unspecified registers at 0x0040861c. #4 0x0040cf44 in main (argc=2, argv=0x3d2588) at ../../gcc/p/gpc.c:7000
The offending call to strncmp() in prefix.c is on line 256. Starting from line 249, it is as follows:
249 char * 250 update_path (path, key) 251 const char *path; 252 const char *key; 253{ 254 char *result; 255 256 if (! strncmp (path, std_prefix, strlen (std_prefix)) && key != 0)
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 19 Feb 2005 at 17:33, Waldek Hebisch wrote:
Can you post a complete traceback or at least error position? (There are many strncmp's in gpc.c, and know which one it is might help.)
Attached ...
<snip> > Program received signal SIGSEGV, Segmentation fault. > 0x77c47a64 in strncmp () > (gdb) info line *0x77c47a64 > No line number information available for address 0x77c47a64 > <strncmp+20>
can you type `bt' here (to get the calling place)?
Program received signal SIGSEGV, Segmentation fault. 0x77c47a64 in strncmp () (gdb) bt #0 0x77c47a64 in strncmp () #1 0x0040f24d in update_path (path=0x0, key=0x4191f7 "GCC") at ../../gcc/prefix.c:256 #2 0x0040284f in add_prefix (pprefix=0x415024, prefix=0x0, component=0x0, priority=1, require_machine_suffix=0, warn=0x0, os_multilib=0) at ../../gcc/p/gpc.c:3207 #3 0x0040898e in process_command (argc=2, argv=0x3d2588) at ../../gcc/p/gpc.c:3888
Quick glance: gcc_libexec_prefix (2nd argument in that add_prefix call) seems to be NULL. It's previously set by make_relative_prefix(*) (line 3847 or 3854) which can indeed return NULL (line 2947 or 2967).
But add_prefix passes this argument to update_path, and this to strncmp, so it must not be NULL.
(*) This is different in gcc.c (gcc-3.4.3), so it might be the cause of the problem. I haven't looked into what this code exactly does, so I don't know if that part can simply be copied from gcc.c, or if it's only a "red herring".
Frank
Prof A Olowofoyeku wrote:
Program received signal SIGSEGV, Segmentation fault. 0x77c47a64 in strncmp () (gdb) bt #0 0x77c47a64 in strncmp () #1 0x0040f24d in update_path (path=0x0, key=0x4191f7 "GCC") at ../../gcc/prefix.c:256 #2 0x0040284f in add_prefix (pprefix=0x415024, prefix=0x0, component=0x0, priority=1, require_machine_suffix=0, warn=0x0, os_multilib=0) at ../../gcc/p/gpc.c:3207 #3 0x0040898e in process_command (argc=2, argv=0x3d2588) at ../../gcc/p/gpc.c:3888
It seems that someting is wrong already in `process_command' (`prefix' in call to `add_prefix' definitely should be not 0). Could you try the following patch and post the results. The patch should print some relevant info and exit cleanly (if it still crashes you could wrap every `fprintf' in an `if' like the first one).
--- gpc.c.bb Sun Feb 20 21:27:53 2005 +++ gpc.c Sun Feb 20 21:41:48 2005 @@ -3840,6 +3840,12 @@ gcc_libexec_prefix = standard_libexec_prefix; #ifndef VMS /* FIXME: make_relative_prefix doesn't yet work for VMS. */ + if (gcc_exec_prefix) + fprintf(stderr, "gcc_exec_prefix=%s", gcc_exec_prefix); + else + fprintf(stderr, "gcc_exec_prefix is null\n"); + fflush(0); + if (!gcc_exec_prefix) { gcc_exec_prefix = make_relative_prefix (argv[0], standard_bindir_prefix, @@ -3885,6 +3891,17 @@ }
set_std_prefix (gcc_exec_prefix, len); + fprintf(stderr, "standard_bindir_prefix=%s\n", standard_bindir_prefix); + fprintf(stderr, "standard_libexec_prefix=%s\n", standard_libexec_prefix); + fprintf(stderr, "argv[0]=%s\n", argv[0]); + fprintf(stderr, "gcc_exec_prefix=%s\n", gcc_exec_prefix); + if (gcc_libexec_prefix) + fprintf(stderr, "gcc_libexec_prefix=%s\n", gcc_libexec_prefix); + else + fprintf(stderr, "gcc_libexec_prefix is null\n"); + fflush(0); + if (!gcc_libexec_prefix) + exit(1); add_prefix (&exec_prefixes, gcc_libexec_prefix, "GCC", PREFIX_PRIORITY_LAST, 0, NULL, 0); add_prefix (&startfile_prefixes, gcc_exec_prefix, "GCC",
On 20 Feb 2005 at 21:40, Waldek Hebisch wrote:
Prof A Olowofoyeku wrote:
Program received signal SIGSEGV, Segmentation fault. 0x77c47a64 in strncmp () (gdb) bt #0 0x77c47a64 in strncmp () #1 0x0040f24d in update_path (path=0x0, key=0x4191f7 "GCC") at ../../gcc/prefix.c:256 #2 0x0040284f in add_prefix (pprefix=0x415024, prefix=0x0, component=0x0, priority=1, require_machine_suffix=0, warn=0x0, os_multilib=0) at ../../gcc/p/gpc.c:3207 #3 0x0040898e in process_command (argc=2, argv=0x3d2588) at ../../gcc/p/gpc.c:3888
It seems that someting is wrong already in `process_command' (`prefix' in call to `add_prefix' definitely should be not 0). Could you try the following patch and post the results.
[....] gcc_exec_prefix is null standard_bindir_prefix=d:/mingw/bin/ standard_libexec_prefix=/usr/local/libexec/gcc/ argv[0]=d:\src\mingw\gcc-3.2.3\build\gcc\xgpc.exe gcc_exec_prefix=d:\src\mingw\gcc-3.2.3\build\gcc..\lib/gcc-lib/ gcc_libexec_prefix is null
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
On 20 Feb 2005 at 21:40, Waldek Hebisch wrote:
Prof A Olowofoyeku wrote:
Program received signal SIGSEGV, Segmentation fault. 0x77c47a64 in strncmp () (gdb) bt #0 0x77c47a64 in strncmp () #1 0x0040f24d in update_path (path=0x0, key=0x4191f7 "GCC") at ../../gcc/prefix.c:256 #2 0x0040284f in add_prefix (pprefix=0x415024, prefix=0x0, component=0x0, priority=1, require_machine_suffix=0, warn=0x0, os_multilib=0) at ../../gcc/p/gpc.c:3207 #3 0x0040898e in process_command (argc=2, argv=0x3d2588) at ../../gcc/p/gpc.c:3888
It seems that someting is wrong already in `process_command' (`prefix' in call to `add_prefix' definitely should be not 0). Could you try the following patch and post the results.
[....] gcc_exec_prefix is null standard_bindir_prefix=d:/mingw/bin/ standard_libexec_prefix=/usr/local/libexec/gcc/ argv[0]=d:\src\mingw\gcc-3.2.3\build\gcc\xgpc.exe gcc_exec_prefix=d:\src\mingw\gcc-3.2.3\build\gcc..\lib/gcc-lib/ gcc_libexec_prefix is null
Now I understand the problem. Normally with gcc-3.2.3 or gcc-3.3.x `gcc_libexec_prefix' is unused, and `standard_libexec_prefix' has default value. If you pass `--prefix=d:/mingw/' option to configure `standard_libexec_prefix' is bogus. `standard_libexec_prefix' is passed to `make_relative_prefix'. On Linux `make_relative_prefix' just gives bogus value of `gcc_libexec_prefix', but with Windows paths one gets null pointer (and crash). The following should fix the problem.
diff -u p.bb/gpc.c p/gpc.c --- p.bb/gpc.c Sat Feb 12 02:14:47 2005 +++ p/gpc.c Mon Feb 21 01:03:06 2005 @@ -3885,8 +3885,14 @@ }
set_std_prefix (gcc_exec_prefix, len); - add_prefix (&exec_prefixes, gcc_libexec_prefix, "GCC", - PREFIX_PRIORITY_LAST, 0, NULL, 0); +#ifdef GCC_3_4 + if (gcc_libexec_prefix) + add_prefix (&exec_prefixes, gcc_libexec_prefix, "GCC", + PREFIX_PRIORITY_LAST, 0, NULL, 0); + else +#endif + add_prefix (&exec_prefixes, gcc_exec_prefix, "GCC", + PREFIX_PRIORITY_LAST, 0, NULL, 0); add_prefix (&startfile_prefixes, gcc_exec_prefix, "GCC", PREFIX_PRIORITY_LAST, 0, NULL, 0); }
On 21 Feb 2005 at 2:53, Waldek Hebisch wrote:
[...]
Now I understand the problem. Normally with gcc-3.2.3 or gcc-3.3.x `gcc_libexec_prefix' is unused, and `standard_libexec_prefix' has default value. If you pass `--prefix=d:/mingw/' option to configure `standard_libexec_prefix' is bogus. `standard_libexec_prefix' is passed to `make_relative_prefix'. On Linux `make_relative_prefix' just gives bogus value of `gcc_libexec_prefix', but with Windows paths one gets null pointer (and crash). The following should fix the problem.
diff -u p.bb/gpc.c p/gpc.c --- p.bb/gpc.c Sat Feb 12 02:14:47 2005
[...]
Yes, it does. Thanks.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 21 Feb 2005 at 2:53, Waldek Hebisch wrote:
[...]
Now I understand the problem. Normally with gcc-3.2.3 or gcc-3.3.x `gcc_libexec_prefix' is unused, and `standard_libexec_prefix' has default value. If you pass `--prefix=d:/mingw/' option to configure `standard_libexec_prefix' is bogus. `standard_libexec_prefix' is passed to `make_relative_prefix'. On Linux `make_relative_prefix' just gives bogus value of `gcc_libexec_prefix', but with Windows paths one gets null pointer (and crash). The following should fix the problem.
diff -u p.bb/gpc.c p/gpc.c --- p.bb/gpc.c Sat Feb 12 02:14:47 2005
[...]
Yes, it does. Thanks.
Thanks, I'm putting the patch into the next release.
Frank
Waldek Hebisch wrote:
I have discovered code generation problem on AMD64. The patch below corrects code generation. It causes spurious warnings in some other tests (fjf1014.pas, fjf1021h.pas, fjf1021i.pas, fjf768c.pas, fjf768e.pas, fjf768f.pas) but those will require separate fix.
In principle other platforms may be affected -- in particular the problem on Mac OSX looks related.
New test results on Mac OS X
[G5:gcc/p/test] adriaan% make EXTRA_PFLAGS=--longjmp-all-nonlocal-labels ... Native configuration is powerpc-apple-darwin7 (G5.local)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: asmtest.pas FAIL: avo4.pas FAIL: az20.pas FAIL: filehand.pas FAIL: fjf1021h.pas FAIL: fjf1021i.pas UNSUPPORTED: fjf165a.pas FAIL: fjf659o.pas FAIL: fjf684.pas FAIL: fjf746.pas FAIL: fjf751k.pas FAIL: fjf751l.pas FAIL: fjf800.pas FAIL: fjf980b.pas FAIL: fjf998r.pas UNSUPPORTED: gmptest.pas FAIL: longr2.pas FAIL: pack10.pas FAIL: pack12.pas FAIL: pack2.pas FAIL: pack4.pas FAIL: random.pas FAIL: systemtest.pas
=== gpc Summary ===
# of tests 4537 # of expected passes 4511 # of unexpected failures 20 # of unsupported tests 6
gpc version 20050217, based on gcc-3.4.3
TEST avo4.pas: ./test_run: line 345: 1590 Segmentation fault ./"$A_OUT" "$1"
TEST az20.pas: ./test_run: line 345: 1969 Segmentation fault ./"$A_OUT" "$1"
TEST filehand.pas: ./filehand.pas: In main program: ./filehand.pas:11: error: statement used as an expression failed
TEST fjf1021h.pas: ./fjf1021h.pas:6: error: expressions with side-effects are not allowed in schema types failed
TEST fjf1021i.pas: ./fjf1021i.pas:8: error: expressions with side-effects are not allowed in schema types failed
TEST fjf659o.pas: ./test_run: line 345: 16058 Segmentation fault ./"$A_OUT" "$1"
TEST fjf684.pas: ./fjf684.pas: In main program: ./fjf684.pas:12: error: invalid operands to `=' failed
TEST fjf746.pas: ./test_run: line 345: 20132 Segmentation fault ./"$A_OUT" "$1"
TEST fjf751k.pas: ./fjf751k.pas: In main program: ./fjf751k.pas:8: error: argument to `WriteLn' is of wrong type failed
TEST fjf751l.pas: ./fjf751l.pas: In main program: ./fjf751l.pas:8: error: argument to `WriteLn' is of wrong type failed
TEST fjf800.pas: ./fjf800.pas:65: error: redeclaration of `Fjf800' ./fjf800.pas:1: error: previous declaration ./fjf800.pas:65: error: redeclaration of `Fjf800' ./fjf800.pas:1: error: previous declaration failed
TEST fjf980b.pas: ./test_run: line 345: 2583 Segmentation fault ./"$A_OUT" "$1"
TEST longr2.pas: dummy.pas: In main program: dummy.pas:2: error: real constant out of range
TEST pack10.pas: ./test_run: line 345: 16476 Segmentation fault ./"$A_OUT" "$1"
TEST pack12.pas: ./test_run: line 345: 16516 Segmentation fault ./"$A_OUT" "$1"
TEST pack2.pas: ./test_run: line 345: 16537 Segmentation fault ./"$A_OUT" "$1"
TEST pack4.pas: ./test_run: line 345: 16577 Segmentation fault ./"$A_OUT" "$1"
TEST random.pas: ./random.pas: In main program: ./random.pas:22: error: invalid operands to `*' ./random.pas:22: error: invalid operands to `*' failed
TEST systemtest.pas: ./test_run: line 345: 22603 Segmentation fault ./"$A_OUT" "$1"
typical backtrace for the segmentation faults:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x000d703c
Thread 0 Crashed: 0 a.out 0x00008260 _p_FileHandle + 0x4 (files.pas:1015) 1 a.out 0x00003760 _p_WriteErrorMessage + 0x10c (error.pas:750) 2 a.out 0x00003a40 _p__rts_Error_S24_Writestackdump + 0x2cc (error.pas:772) 3 a.out 0x00004438 _p_EndRuntimeError + 0x38 (error.pas:862) 4 a.out 0x00004544 _p__rts_Error_S32_Strerror + 0 (error.pas:875) 5 a.out 0x00002998 _p_IORangeCheckError + 0 (error.pas:585) 6 a.out 0x000026ac _p__M0_main_program + 0x23c (pack2.pas:18) 7 a.out 0x00002808 main + 0x34 (<implicit code>:22) 8 a.out 0x000020a8 _start + 0x188 (crt.c:267) 9 dyld 0x8fe1a558 _dyld_start + 0x64
-
Adriaan van Os -
Frank Heckenbach -
Prof A Olowofoyeku (The African Chief) -
Waldek Hebisch