bus error building nodejs 0.8.0 / 0.8.1

[Ryan Schmidt]

I can't build nodejs 0.8.0 or 0.8.1 on my OS X 10.5 machine with Apple gcc 4.0.1.

First there are tons of warnings. Here's a summary:

$ sed -E -n 's/^.*(warning:)/\1/p' nodejs.main.log | sort | uniq -c
2 warning: "/*" within comment
7 warning: comparison between signed and unsigned
1 warning: implicit declaration of function ‘rename’
128 warning: integer overflow in expression
1 warning: label ‘done’ defined but not used
26 warning: left-hand operand of comma expression has no effect
1 warning: pointer targets in passing argument 6 of ‘recvfrom’ differ in signedness
2 warning: suggest explicit braces to avoid ambiguous ‘else’
1 warning: suggest parentheses around arithmetic in operand of |
1 warning: unused variable ‘feed_count’
13 warning: unused variable ‘ocur_’
10 warning: ‘inline’ is not at beginning of declaration
10 warning: ‘static’ is not at beginning of declaration

Finally, the build fails with:

ACTION v8_snapshot_run_mksnapshot out/Release/obj.target/v8_snapshot/geni/snapshot.cc
/bin/sh: line 1: 37725 Bus error "out/Release/mksnapshot" --log-snapshot-positions --logfile "out/Release/obj.target/v8_snapshot/geni/snapshot.log" "out/Release/obj.target/v8_snapshot/geni/snapshot.cc"

Note that nodejs 0.6.19 is successfully installed on this system.

[mscdex]

On Jun 29, 4:34 am, Ryan Schmidt <google-2...@ryandesign.com> wrote:
> Finally, the build fails with:
>
>   ACTION v8_snapshot_run_mksnapshot out/Release/obj.target/v8_snapshot/geni/snapshot.cc
> /bin/sh: line 1: 37725 Bus error               "out/Release/mksnapshot" --log-snapshot-positions --logfile "out/Release/obj.target/v8_snapshot/geni/snapshot.log" "out/Release/obj.target/v8_snapshot/geni/snapshot.cc"

Does building without a snapshot work (e.g. ./configure --without-
snapshot)?

[Ryan Schmidt]

On Jun 29, 2012, at 04:10, mscdex wrote:

> On Jun 29, 4:34 am, Ryan Schmidt wrote:
>> Finally, the build fails with:
>>
>> ACTION v8_snapshot_run_mksnapshot out/Release/obj.target/v8_snapshot/geni/snapshot.cc
>> /bin/sh: line 1: 37725 Bus error "out/Release/mksnapshot" --log-snapshot-positions --logfile "out/Release/obj.target/v8_snapshot/geni/snapshot.log" "out/Release/obj.target/v8_snapshot/geni/snapshot.cc"
>
> Does building without a snapshot work (e.g. ./configure --without-
> snapshot)?

Looking in ./configure --help I see:

--without-snapshot Build without snapshotting V8 libraries. You might
want to set this for cross-compiling. [Default: False]

The default for *without* snapshot is *false*? So the default for *with* snapshot is *true*. Got it. The double negative is confusing. This should be made more clear, and the same format should be used to indicate what the default value is for all of the configure options.

Yes it builds with snapshot turned off.

What are snapshotting V8 libraries and what is the implication of enabling or disabling them?

[mscdex]

On Jun 29, 7:15 am, Ryan Schmidt <google-2...@ryandesign.com> wrote:
> What are snapshotting V8 libraries and what is the implication of enabling or disabling them?

When snapshot is enabled, it "bundles" a clean v8 vm context with a
lot of already compiled JavaScript and whatnot. This allows for faster
startup and faster creation of additional vm contexts.

Specifically from the v8 Embedder's Guide [1]: "With the V8 snapshot
feature (activated with build option snapshot=yes, which is the
default) the time spent creating the first context will be highly
optimized as a snapshot includes a serialized heap which contains
already compiled code for the built-in JavaScript code."

[1] https://developers.google.com/v8/embed#contexts

[Ben Noordhuis]

Ryan, run `make test` afterwards to ensure that your newly compiled
binary is indeed working properly.

Also, if you have the time and the inclination, it'd be interesting to
track down the cause of the bus error.

[Ryan Schmidt]

On Jun 29, 2012, at 07:23, Ben Noordhuis wrote:
> On Fri, Jun 29, 2012 at 11:10 AM, mscdex <msc...@gmail.com> wrote:
>> On Jun 29, 4:34 am, Ryan Schmidt <google-2...@ryandesign.com> wrote:
>>> Finally, the build fails with:
>>>
>>> ACTION v8_snapshot_run_mksnapshot out/Release/obj.target/v8_snapshot/geni/snapshot.cc
>>> /bin/sh: line 1: 37725 Bus error "out/Release/mksnapshot" --log-snapshot-positions --logfile "out/Release/obj.target/v8_snapshot/geni/snapshot.log" "out/Release/obj.target/v8_snapshot/geni/snapshot.cc"
>>
>> Does building without a snapshot work (e.g. ./configure --without-
>> snapshot)?
>
> Ryan, run `make test` afterwards to ensure that your newly compiled
> binary is indeed working properly.

Good point.

The first 142 tests printed:

--- CRASHED ---

At which point I cancelled it.

> Also, if you have the time and the inclination, it'd be interesting to
> track down the cause of the bus error.

I'm not sure I know how to do this, but as a start, here's what the OS X crash reporter has to say about it:


Thread 0 Crashed:
0 mksnapshot 0x000c1e19 v8::internal::AllocateFixedArrayWithFiller(v8::internal::Heap*, int, v8::internal::PretenureFlag, v8::internal::Object*) + 441
1 mksnapshot 0x000c460d v8::internal::Heap::AllocateHashTable(int, v8::internal::PretenureFlag) + 29
2 mksnapshot 0x0017f973 v8::internal::HashTable<v8::internal::SymbolTableShape, v8::internal::HashTableKey*>::Allocate(int, v8::internal::PretenureFlag) + 115
3 mksnapshot 0x000c8dfb v8::internal::Heap::CreateInitialObjects() + 203
4 mksnapshot 0x000c9898 v8::internal::Heap::SetUp(bool) + 1160
5 mksnapshot 0x0014f8ae v8::internal::Isolate::Init(v8::internal::Deserializer*) + 1294
6 mksnapshot 0x00283579 v8::internal::V8::Initialize(v8::internal::Deserializer*) + 201
7 mksnapshot 0x000278cf v8::Context::New(v8::ExtensionConfiguration*, v8::Handle<v8::ObjectTemplate>, v8::Handle<v8::Value>) + 1087
8 mksnapshot 0x00002006 main + 166 (mksnapshot.cc:306)
9 mksnapshot 0x00001f26 start + 54

[Ben Noordhuis]

Can you try it with the HEAD of the v0.8 branch? I landed a couple of
patches that try to detect (and work around) buggy compilers.

[Ryan Schmidt]

On Jul 4, 2012, at 05:22, Ben Noordhuis wrote:

>>> Also, if you have the time and the inclination, it'd be interesting to
>>> track down the cause of the bus error.
>>
>> I'm not sure I know how to do this, but as a start, here's what the OS X crash reporter has to say about it:
>>
>>
>> Thread 0 Crashed:
>> 0 mksnapshot 0x000c1e19 v8::internal::AllocateFixedArrayWithFiller(v8::internal::Heap*, int, v8::internal::PretenureFlag, v8::internal::Object*) + 441
>> 1 mksnapshot 0x000c460d v8::internal::Heap::AllocateHashTable(int, v8::internal::PretenureFlag) + 29
>> 2 mksnapshot 0x0017f973 v8::internal::HashTable<v8::internal::SymbolTableShape, v8::internal::HashTableKey*>::Allocate(int, v8::internal::PretenureFlag) + 115
>> 3 mksnapshot 0x000c8dfb v8::internal::Heap::CreateInitialObjects() + 203
>> 4 mksnapshot 0x000c9898 v8::internal::Heap::SetUp(bool) + 1160
>> 5 mksnapshot 0x0014f8ae v8::internal::Isolate::Init(v8::internal::Deserializer*) + 1294
>> 6 mksnapshot 0x00283579 v8::internal::V8::Initialize(v8::internal::Deserializer*) + 201
>> 7 mksnapshot 0x000278cf v8::Context::New(v8::ExtensionConfiguration*, v8::Handle<v8::ObjectTemplate>, v8::Handle<v8::Value>) + 1087
>> 8 mksnapshot 0x00002006 main + 166 (mksnapshot.cc:306)
>> 9 mksnapshot 0x00001f26 start + 54
>
> Can you try it with the HEAD of the v0.8 branch? I landed a couple of
> patches that try to detect (and work around) buggy compilers.

The node 0.8.2 build still crashes in the same way.

[Ben Noordhuis]

Does it work when you build with `make CFLAGS+=-O0 CXXFLAGS+=-O0`? -O1 or -O2?

[Ryan Schmidt]

On Jul 10, 2012, at 09:27, Ben Noordhuis wrote:

> Does it work when you build with `make CFLAGS+=-O0 CXXFLAGS+=-O0`? -O1 or -O2?

This failure was with -O2 (the MacPorts default). I'll try with -O0, -O1 and -Os.

[Ben Noordhuis]

On Wed, Jul 11, 2012 at 7:00 AM, JWagner <njwj...@gmail.com> wrote:
> I am having the same issue.
> mac osx 10.5.8 gcc 4.0.2
> I tried
> ./configure --without-snapshot
> make CFLAGS+=-O0 CXXFLAGS+=-O0
> make install // failed with 'make: *** [install] Bus error'

Do you have the possibility to upgrade your gcc? 4.0.2 is really,
really ancient.

[Ryan Schmidt]

gcc 4.0.1 is the version of gcc Apple supplies by default in the newest version of Xcode available for OS X 10.5.8.

gcc 4.2.1 is also included in that version of Xcode and can be used if desired. (CC=/usr/bin/gcc-4.2) I tried that with nodejs 0.8.1 and it didn't make any difference for this build issue.

I think a really old version of clang might be available too. I haven't tried that yet.

MacPorts can install the latest clang and gcc compilers. We could use one of those for nodejs if absolutely necessary. Though it's preferable not to force the user to compile a compiler.

[Ben Noordhuis]

Can you try it with a new gcc and/or clang? It would be good to
exclude the possibility of compiler bugs.

Does MacPorts modify the nodejs.org source tarball in any way?

[Ben Noordhuis]

On Fri, Jul 13, 2012 at 2:17 PM, Eric Vander Weele <eri...@gmail.com> wrote:
> I have tried with clang-3.2 and have gotten nodejs to build under OS X 10.5
> , however when I run node I get the following:
>> Assertion failed: (!!(events & UV__IO_READ) ^ !!(events & UV__IO_WRITE)),
>> function uv__stream_io, file ../deps/uv/src/unix/stream.c, line 732.
>
> seems related to https://github.com/joyent/node/issues/3072 however.

Yes, that's just a regular bug. :-)

Can you compile a debug build and post the output of `bt full` (from
within gdb)?

[Eric Vander Weele]

(gdb) bt full          

 #0  0x932afd52 in __kill ()   No symbol table info available.

 #1  0x932afd44 in kill$UNIX2003 ()   No symbol table info available.

 #2  0x93322242 in raise ()   No symbol table info available.

 #3  0x9332e681 in abort ()   No symbol table info available.

 #4  0x933233e3 in __assert_rtn ()   No symbol table info available.

 #5  0x0005fc68 in uv__stream_io (loop=0x7d5700, w=<value temporarily unavailable, due to optimizations>, events=-2147483645) at ../deps/uv/src/unix/stream.c:732   No locals.

 #6  0x00053246 in uv__io_rw (ev=0x7d5c34, w=0xc082a8, events=-2147483645) at ../deps/uv/src/unix/core.c:622

                                                    loop = (uv_loop_t *) 0x0

                                                                                handle = (uv__io_t *) 0xbffff53c

#7  0x0005815d in ev_invoke_pending (loop=0x7d5c34) at ../deps/uv/src/unix/ev/ev.c:2145

                           pri = Cannot access memory at address 0x4

[Ben Noordhuis]

On Fri, Jul 13, 2012 at 3:08 PM, Eric Vander Weele <eri...@gmail.com> wrote:
> (gdb) bt full
>
> #0 0x932afd52 in __kill () No symbol table info available.
>
> #1 0x932afd44 in kill$UNIX2003 () No symbol table info available.
>
> #2 0x93322242 in raise () No symbol table info available.
>
> #3 0x9332e681 in abort () No symbol table info available.
>
> #4 0x933233e3 in __assert_rtn () No symbol table info available.
>
> #5 0x0005fc68 in uv__stream_io (loop=0x7d5700, w=<value temporarily
> unavailable, due to optimizations>, events=-2147483645) at
> ../deps/uv/src/unix/stream.c:732 No locals.
>
> #6 0x00053246 in uv__io_rw (ev=0x7d5c34, w=0xc082a8, events=-2147483645)
> at ../deps/uv/src/unix/core.c:622
>
> loop = (uv_loop_t *) 0x0
>
>
> handle = (uv__io_t *) 0xbffff53c
>
> #7 0x0005815d in ev_invoke_pending (loop=0x7d5c34) at
> ../deps/uv/src/unix/ev/ev.c:2145
>
> pri = Cannot access memory at address 0x4

Eric, can you try that with a debug build? gdb prints mostly bogus
results with release builds. `make BUILDTYPE=Debug` compiles to
out/Debug/node.

[Ryan Schmidt]

The problem remains with 0.8.3 and 0.9.0.

Building 0.8.3 with -O0, -O1 or -Os doesn't change it.

On Jul 11, 2012, at 08:17, Ben Noordhuis wrote:

> Can you try it with a new gcc and/or clang? It would be good to
> exclude the possibility of compiler bugs.

Building 0.8.3 with Apple's gcc-4.2 doesn't help. I misremembered, and this version of Xcode does not provide clang. I installed MacPorts clang 3.0 and built nodejs 0.8.3 with it; the build succeeds but "make test" crashes in mksnapshot. I installed MacPorts clang 3.1 and built nodejs 0.8.4 with it and had the same result.

> Does MacPorts modify the nodejs.org source tarball in any way?

The Portfile (the Tcl recipe telling MacPorts how to install nodejs) is here:

https://trac.macports.org/browser/trunk/dports/devel/nodejs/Portfile

There are currently no patches, and only a few sed replacements of shebang lines to ensure the correct copies of node and python get used (rather than relying on /usr/bin/env).


Now that OS X 10.8 Mountain Lion has been released, 10.5 Leopard is three releases old, and there's really no excuse whatsoever for Intel Mac users not to upgrade to at least 10.6 Snow Leopard (all Intel Macs support it and it is a faster OS), so I'm happy to just mark node as requiring Snow Leopard or newer in MacPorts.

[Ben Noordhuis]

On Sat, Jul 28, 2012 at 7:35 PM, Ryan Schmidt
<googl...@ryandesign.com> wrote:
> Now that OS X 10.8 Mountain Lion has been released, 10.5 Leopard is three releases old, and there's really no excuse whatsoever for Intel Mac users not to upgrade to at least 10.6 Snow Leopard (all Intel Macs support it and it is a faster OS), so I'm happy to just mark node as requiring Snow Leopard or newer in MacPorts.

That gets my vote. The only person I know that still uses 10.5 is my
father-in-law and he's not exactly the target audience.