Debug build fails to compile on SmartOS

[jbergstroem]

make[1]: Entering directory '/tmp/iojs-smartos14-32/out'
  LD_LIBRARY_PATH=/tmp/iojs-smartos14-32/out/Debug/lib.host:/tmp/iojs-smartos14-32/out/Debug/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../.; mkdir -p /tmp/iojs-smartos14-32/out/Debug/obj.target/iojs/src; dtrace -32 "-I/root/iojs-smartos14-32/out/Debug/obj/gen" -Isrc -C -G -s src/v8ustack.d -o "/tmp/iojs-smartos14-32/out/Debug/obj.target/iojs/src/node_dtrace_ustack.o"
dtrace: failed to compile script src/v8ustack.d: line 258: failed to resolve V8DBG_OFF_FP_CONTEXT: Unknown variable name
node_dtrace_ustack.target.mk:26: recipe for target '/tmp/iojs-smartos14-32/out/Debug/obj.target/iojs/src/node_dtrace_ustack.o' failed
make[1]: *** [/tmp/iojs-smartos14-32/out/Debug/obj.target/iojs/src/node_dtrace_ustack.o] Error 1
make[1]: Leaving directory '/tmp/iojs-smartos14-32/out'
Makefile:39: recipe for target 'iojs_g' failed

/CC @nodejs/platform-solaris

[misterdjules]

@jbergstroem I apologize for not being able to help on this. It's on my radar, I just want to be done with higher priority issues (releasing v0.10.39 and v0.12.5 with OpenSSL upgrades) first.

[jbergstroem]

Just revisited this, looks like we're still experiencing this. Issues while objdump:ing?

[jbergstroem]

@No9 here's another issue if you're keen :)

[misterdjules]

@jbergstroem @No9 ./configure --debug && make works for me on SmartOS with latest nodejs/master and gcc 4.9.2. It takes a very long time to link, but it doesn't fail.

Is the error mentioned in the description of this issue the same error you're still having now when building nodejs/master with ./configure --debug && make on SmartOS?

[No9]

@misterdjules apologies meant to update this but couldn't replicate
Smart OS instance 15.2.0.

pkgin in git
pkgin in gcc49 
pkgin in gmake
export PATH=$PATH:/opt/local/gcc49/bin
git clone https://github.com/nodejs/node.git
cd node 
./configure --debug 
make
make install

Is all good
[Edit]
Also ran it on 4.0.0 at the time and couldn't see it

[jbergstroem]

From our 64-bit buildbot (gcc 4.9.1, joyent_20150417T032220Z):

$ git reset --hard f32a606e373ad57f684b0e511d6d6e4cbd48a812
$ ./configure --debug
<snip>
$ make -j5
<snip>
  g++ '-DNODE_ARCH="ia32"' '-DNODE_WANT_INTERNALS=1' '-DV8_DEPRECATION_WARNINGS=1' '-DHAVE_OPENSSL=1' '-DHAVE_DTRACE=1' '-D__POSIX__' '-DNODE_PLATFORM="sunos"' '-DHTTP_PARSER_STRICT=0' '-D_LARGEFILE_SOURCE' '-D_FILE_OFFSET_BITS=64' '-DDEBUG' '-D_DEBUG' -I../src -I../tools/msvs/genfiles -I../deps/uv/src/ares -I/root/io.js/out/Debug/obj/gen -I../deps/v8 -I../deps/cares/include -I../deps/v8/include -I../deps/openssl/openssl/include -I../deps/zlib -I../deps/http_parser -I../deps/uv/include  -Wall -Wextra -Wno-unused-parameter -m32 -pthreads -g -O0 -fno-rtti -fno-exceptions -std=gnu++0x -MMD -MF /root/io.js/out/Debug/.deps//root/io.js/out/Debug/obj.target/node/src/node_javascript.o.d.raw  -c -o /root/io.js/out/Debug/obj.target/node/src/node_javascript.o ../src/node_javascript.cc
  LD_LIBRARY_PATH=/root/io.js/out/Debug/lib.host:/root/io.js/out/Debug/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../.; mkdir -p /root/io.js/out/Debug/obj.target/node/src; dtrace -32 "-I/root/io.js/out/Debug/obj/gen" -Isrc -C -G -s src/v8ustack.d -o "/root/io.js/out/Debug/obj.target/node/src/node_dtrace_ustack.o"
dtrace: failed to compile script src/v8ustack.d: line 258: failed to resolve V8DBG_OFF_FP_CONTEXT: Unknown variable name
node_dtrace_ustack.target.mk:26: recipe for target '/root/io.js/out/Debug/obj.target/node/src/node_dtrace_ustack.o' failed
make[1]: *** [/root/io.js/out/Debug/obj.target/node/src/node_dtrace_ustack.o] Error 1

..so is this a subtle thing between gcc 4.9.1 and 4.9.2?

@misterdjules I think you have access to the machine if you want to play around. Happy to arrange the same for you, @No9.

Edit: @joaocgreis @misterdjules

[misterdjules]

@jbergstroem What do the following commands give you:

[root@dev ~/node-1]# nm ./out/Debug/libv8_base.a | grep -i V8DBG_OFF_FP_CONTEXT
00000000000000bc D v8dbg_off_fp_context
[root@dev ~/node-1]# grep V8DBG_OFF_FP_CONTEXT out/Debug/obj/gen/v8constants.h 
#define V8DBG_OFF_FP_CONTEXT -0x8
[root@dev ~/node-1]# 

?

[jbergstroem]

@misterdjules: that's what I checked last time as well -- the constant isn't in there;

$ nm ./out/Debug/libv8_base.a | grep -i V8DBG_OFF_FP_CONTEXT
000000b8 D v8dbg_off_fp_context
$ grep V8DBG_OFF_FP_CONTEXT out/Debug/obj/gen/v8constants.h 
$ # empty

[misterdjules]

@jbergstroem What is the output of:

$ ./tools/genv8constants.py /tmp/foo.out out/Debug/libv8_base.a && cat /tmp/foo.out

?

[jbergstroem]

/*
 * File automatically generated by genv8constants. Do not edit.
 *
 * The following offsets are dynamically from libv8_base.a.  See src/v8ustack.d
 * for details on how these values are used.
 */

#ifndef V8_CONSTANTS_H
#define V8_CONSTANTS_H

[misterdjules]

@jbergstroem Interesting. What's the output of python --version, objdump --version and objdump -z -D out/Debug/libv8_base.a?

[No9]

@jbergstroem this direction has started me thinking about this old issue #461
Apologies if its off track
Specifically So it would seem that the technique used to identify the V8_CONSTANTS in tools/genv8constants.py not going to work with the current build output of /usr/home/freebsd/io.js/out/Release/obj.target/deps/v8/tools/gyp/libv8_base.a

[misterdjules]

@No9 The symptoms are a bit similar, but it seems that everything is in place for the compiler/linker to generate the v8dbg_off_fp_context symbol that is missing when generating v8constants.h: gen-postmortem-metadata.py contains a reference to off_fp_context.

Moreover, it seems I'm able to build a debug build form the same commit on my SmartOS machine.

@jbergstroem if the output from objdump -z -D out/Debug/libv8_base.a is too large, then the output from objdump -z -D out/Debug/libv8_base.a | grep v8dbg would actually be enough.

[jbergstroem]

• Python 2.7.8
• objdump 2.24 (gnu binutils)

Output can be found here.

Also interesting:

$ objdump -z -D out/Debug/libv8_base.a > ~/objdump_output.log
Segmentation Fault (core dumped)

[misterdjules]

@jbergstroem I use the same version of objdump, and Python 2.7.9, which seems reasonably close to the version of Python you're using.

What is the output of pstack the_objdump_core_file?

Also, the output from your objdump run doesn't contain any debugging symbol, but at the same time it seems to have been truncated very quickly, probably when it segfaulted and dumped core (the file is only 56MBs, and at the end of the process it is normally around 3GBs IIRC).

[jbergstroem]

most likely as the result of the segfault i get this:

$ pstack ../objdump_output.log 
pstack: cannot examine ../objdump_output.log: no such process or core file

[misterdjules]

@jbergstroem by the_objdump_core_file I meant the core file generated by for the process that segfaulted, not the output of the command. pstack on that core file should give you the call stack at the time the process crashed.

[misterdjules]

@jbergstroem Any update on this? If that helps, could you give me access to that machine so that I can investigate too?

[jbergstroem]

@misterdjules sorry for the delay, travelling. I can give you access once I'm back at work in a few days. I'll also read the man page of pstack before making a bigger fool of myself :)

[misterdjules]

@jbergstroem No worries, my initial instructions were confusing :) Let me know how and when I can help.

[jbergstroem]

@misterdjules can you email me your pubkey?

[misterdjules]

@jbergstroem Sent :)

[misterdjules]

@jbergstroem So it turns out that building objdump's binutils-2_24 tag (from source) and using that objdump binary fixes the problem.

On a SmartOS machine that uses a 2014Q4 pkgsrc, the problem isn't present too. So I would think that upgrading to a 2014Q4 pkgsrc is probably the best thing we can do here.

[jbergstroem]

Ok. I'll look at bumping our packages/stack then.

[jbergstroem]

Just updated one of the machines (32-bit) to 2014Q4. Binutils still seems to be at 2.24 and objdump still acts the same :/

[misterdjules]

@jbergstroem OK, yes objdump's version is still 2.24, but IIRC the binaries are not the same. I'll see if I can find some time to investigate further.

[jbergstroem]

@misterdjules I'm doing a full clean build now; copied the sources over so there might have been something going on.

Edit: nope, same issue.

[bnoordhuis]

Closing, no activity in half a year. Reopen if necessary.