0.8.8 gives seg fault on Mac 10.6.3

[Steve Adams]

I downloaded 0.8.8 and built it on Mac OS X 10.6.3. This seemed to go fine. When I try to run the nimrod executable, even in the case with no arguments, it throws a segmentation fault.

[Steve Adams (adamss)]

I tried this on Mac OS X 10.5.8, and the compiler builds and runs. However, in order to use it I had to run the install script.

  sudo sh install.sh /usr/bin

If I do that, all works fine. If I just try to create the symbolic link, I get

  Error: cannot open '/usr/lib/nimrod/system.nim'

when I try

   nimrod c keyval.nim

[Andreas Rumpf (rumpf-a)]

Which GCC version?
Mac OS X 10.6.3: 32 or 64bit?
Mac OS X 10.5.8: 32 or 64bit?

[Steve Adams (adamss)]

32-bit for both

On Sat, 2010-05-15 at 07:12 +0000, Andreas Rumpf wrote:
> Which GCC version?
> Mac OS X 10.6.3: 32 or 64bit?
> Mac OS X 10.5.8: 32 or 64bit?
>

[Andreas Rumpf (rumpf-a)]

I don't have access to a machine with Mac OS X 10.5 or 10.6. Please do:
* add "-g" to COMP_FLAGS in build.sh
* build and install
* run gdb nimrod
* post the stack trace here.

[Steve Adams (adamss)]

I did this on the 10.6.3 machine.

Starting program: /usr/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
0x00000001000105c4 in Splitchunk_8066 (A_8069=0x10011b640, C_8070=<value temporarily unavailable, due to optimizations>, Size_8071=8192) at build/2_1/system.c:2039
2039 (*Rest_8072).Sup.Size = (NI32)((*C_8070).Sup.Size - Size_8071);

[Andreas Rumpf (rumpf-a)]

The built nimrod is for 32 bit, but
KERN_INVALID_ADDRESS at address: 0x0000000000302008
indicates your system is 64bit.
What does "uname -m" say?

Note that Mac OS X for 64bit has never been tested, but it might work if the "build.sh" script would recognize it properly ...

[Andreas Rumpf (rumpf-a)]

And what does "gcc -v" say?

[Steve Adams (adamss)]

uname -m says :
i386

gcc -v says: Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5659~1/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
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5659)

[Andreas Rumpf (rumpf-a)]

Ok... This is strange. Sounds like a GCC issue.
Please try to recompile with -O2 or without optimization.
Does Mac OS X 10.5.8 ship with GCC 4.2.1 too?

[Steve Adams (adamss)]

-O2 gave the same results.

I think the version of GCC is the same on both machines, I can check the other later.

I was wondering if the the problem is with the linker issue that has been reported with 10.6. For me, nimrod runs okay on the 10.5 system if I use the install.sh script instead of trying to use soft link. The other thing I'll try is to use the imaged compiled on 10.5 on the 10.6 system. If I recall correctly, the linker issue I mentioned is only when you build on 10.6.

[Steve Adams (adamss)]

here is the GCC info for the 10.5 machine:

Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5490~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5490)

[Steve Adams (adamss)]

The version built on the 10.5 machine works on both 10.5 and 10.6.

I ran the deinstall.sh script on 10.5 and re-added the soft link on 10.5 and it works fine. The 10.5 images also works with a soft link on 10.6.

[Eric Doughty-Papassideris (eric-doughty)]

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

$ gcc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/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
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5664)

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

[Andreas Rumpf (rumpf-a)]

Thanks. Next version will contain a work-around.