Hi, I had the same problem, this is what solved it for me, I'm sorry I am unable to submit a proper patch, but I havent figured out how build.sh is built... The gdb backtrace and uname is the same as reported by Steve Adams.
However, there was some change related to 64bit transition in 10.6, uname -m says i386, but the architecture should really be x86_64. This guy ( http://lists.apple.com/archives/darwin-dev/2009/Aug/msg00208.html ) suggests the command "sysctl -n hw.cpu64bit_capable".
In build.sh around line 8, I replaced
ucpu=`uname -m`
with
ucpu="x86_64"
After recompiling, nimrod runs.
For reference:
$ uname -a
Darwin Smac.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386
Compiled without optimisations and with -ggdb, here is a stacktrace:
$ gdb bin/nimrod
GNU gdb 6.3.50-20050815 (Apple version gdb-1469) (Wed May 5 04:36:56 UTC 2010)
[...yadayada...]
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .. done
(gdb) r
Starting program: /Users/eric/Documents/Private/Code/nimrod/Compiler/Nimrod/bin/nimrod
Reading symbols for shared libraries +. done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000302008
0x0000000100011b38 in Splitchunk_9266 (A_9269=0x10010da00, C_9270=0x100300000, Size_9271=8192) at build/3_1/system.c:2093
2093 (*Rest_9272).Sup.Size = (NI32)((*C_9270).Sup.Size - Size_9271);
(gdb) bt
#0 0x0000000100011b38 in Splitchunk_9266 (A_9269=0x10010da00, C_9270=0x100300000, Size_9271=8192) at build/3_1/system.c:2093
#1 0x0000000100011e12 in Getbigchunk_9292 (A_9295=0x10010da00, Size_9296=8192) at build/3_1/system.c:2174
#2 0x0000000100012094 in Rawalloc_9395 (A_9398=0x10010da00, Requestedsize_9399=4112) at build/3_1/system.c:2239
#3 0x00000001000120d4 in Alloc_1774 (Size_1776=4096) at build/3_1/system.c:2247
#4 0x0000000100012114 in Alloc0_1777 (Size_1779=4096) at build/3_1/system.c:2255
#5 0x000000010001218f in Init_10478 (S_10481=0x100110a60, Cap_10482=1024) at build/3_1/system.c:2263
#6 0x0000000100012219 in Initgc_3011 () at build/3_1/system.c:2273
#7 0x00000001000144bd in systemInit () at build/3_1/system.c:3119
#8 0x0000000100014d59 in NimMain () at build/3_1/nimrod.c:410
#9 0x0000000100014eea in main (argc=1, args=0x7fff5fbff1c8, env=0x7fff5fbff1d8) at build/3_1/nimrod.c:483
Hi, I had the same problem, this is what solved it for me, I'm sorry I am unable to submit a proper patch, but I havent figured out how build.sh is built... The gdb backtrace and uname is the same as reported by Steve Adams.
However, there was some change related to 64bit transition in 10.6, uname -m says i386, but the architecture should really be x86_64. This guy ( http:// lists.apple. com/archives/ darwin- dev/2009/ Aug/msg00208. html ) suggests the command "sysctl -n hw.cpu64bit_ capable" .
In build.sh around line 8, I replaced
ucpu=`uname -m`
with
ucpu="x86_64"
After recompiling, nimrod runs.
For reference:
$ uname -a 1504.7. 4~1/RELEASE_ I386 i386
Darwin Smac.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-
$ gcc -v gcc/gcc- 5664~38/ src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable- languages= c,objc, c++,obj- c++ --program- transform- name=/^ [cg][^. -]*$/s/ $/-4.2/ --with- slibdir= /usr/lib --build= i686-apple- darwin10 --program- prefix= i686-apple- darwin10- --host= x86_64- apple-darwin10 --target= i686-apple- darwin10 --with- gxx-include- dir=/include/ c++/4.2. 1
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5664)
Compiled without optimisations and with -ggdb, here is a stacktrace: apple-darwin" ...Reading symbols for shared libraries .. done
$ gdb bin/nimrod
GNU gdb 6.3.50-20050815 (Apple version gdb-1469) (Wed May 5 04:36:56 UTC 2010)
[...yadayada...]
This GDB was configured as "x86_64-
(gdb) r eric/Documents/ Private/ Code/nimrod/ Compiler/ Nimrod/ bin/nimrod
Starting program: /Users/
Reading symbols for shared libraries +. done
Program received signal EXC_BAD_ACCESS, Could not access memory. ADDRESS at address: 0x0000000000302008 0x10010da00, C_9270=0x100300000, Size_9271=8192) at build/3_ 1/system. c:2093 9272).Sup. Size = (NI32)( (*C_9270) .Sup.Size - Size_9271); 0x10010da00, C_9270=0x100300000, Size_9271=8192) at build/3_ 1/system. c:2093 0x10010da00, Size_9296=8192) at build/3_ 1/system. c:2174 0x10010da00, Requestedsize_ 9399=4112) at build/3_ 1/system. c:2239 1/system. c:2247 1/system. c:2255 0x100110a60, Cap_10482=1024) at build/3_ 1/system. c:2263 1/system. c:2273 1/system. c:3119 1/nimrod. c:410 f1c8, env=0x7fff5fbff1d8) at build/3_ 1/nimrod. c:483
Reason: KERN_INVALID_
0x0000000100011b38 in Splitchunk_9266 (A_9269=
2093 (*Rest_
(gdb) bt
#0 0x0000000100011b38 in Splitchunk_9266 (A_9269=
#1 0x0000000100011e12 in Getbigchunk_9292 (A_9295=
#2 0x0000000100012094 in Rawalloc_9395 (A_9398=
#3 0x00000001000120d4 in Alloc_1774 (Size_1776=4096) at build/3_
#4 0x0000000100012114 in Alloc0_1777 (Size_1779=4096) at build/3_
#5 0x000000010001218f in Init_10478 (S_10481=
#6 0x0000000100012219 in Initgc_3011 () at build/3_
#7 0x00000001000144bd in systemInit () at build/3_
#8 0x0000000100014d59 in NimMain () at build/3_
#9 0x0000000100014eea in main (argc=1, args=0x7fff5fbf