tst.postmortem_jsstack.js fails for node 6.11.2

[jordanhendricks]

Issue #88 mentioned that tst.postmortem_jsstack.js fails on 6.11.2 for both 32-bit and 64-bit.

I ran into this again when running the test suite from the latest master (d31211b9d47360f044fc63e67deaec3605f8d081).

For reference, the output summary of the tests is:

Summary:
0.10.48 sunos x86: success
0.10.48 sunos x64: success
0.12.17 sunos x86: success
0.12.17 sunos x64: success
4.8.4   sunos x86: success
4.8.4   sunos x64: success
6.11.2  sunos x86: fail
6.11.2  sunos x64: fail

Both 32-bit and 64-bit 6.11.2 failed on tst.postmortem_jsstack.js as follows:

$ cat /var/tmp/catest.54316/failure.0/54316.err

assert.js:85
  throw new assert.AssertionError({
  ^
AssertionError: unexpected frame where stalloogle was expected; core retained as /var/tmp/node.54479
    at ChildProcess.<anonymous> (/root/mdb_v8/test/standalone/tst.postmortem_jsstack.js:130:11)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)

Running ::jsstack on the core, we see that there is an extra stack frame (loadavg called by stalloogle), as noted in #88 :

> ::jsstack
native: libc.so.1`__getloadavg+0x15
native: uv_loadavg+0x19
native: v8::internal::FunctionCallbackArguments::Call+0x117
native: _ZN2v88internal12_GLOBAL__N_119HandleApiCallHelperEPNS0_7Isolate...
native: _ZN2v88internalL21Builtin_HandleApiCallEiPPNS0_6ObjectEPNS0_7Iso...
        (1 internal frame elided)
js:     loadavg
js:     stalloogle
js:     bagnoogle
js:     doogle
js:     ontimeout
js:     tryOnTimeout
js:     listOnTimeout
        (1 internal frame elided)
        (1 internal frame elided)
native: v8::internal::Execution::Call+0xb1
native: v8::Function::Call+0x120
native: v8::Function::Call+0x57
native: node::AsyncWrap::MakeCallback+0x165
native: node::TimerWrap::OnTimeout+0xaf
native: uv__run_timers+0x8e
native: uv_run+0x314
native: node::Start+0x616
native: main+0x63
native: _start+0x83

We should update the tests to account for the loadavg stack frame.

[jordanhendricks]

This PR changed the exported os.loadavg function from a function from node's native internal modules to be an exported javascript function, which explains the additional stack frame in the core from 6.11.2.

[jordanhendricks]

CR at https://cr.joyent.us/#/c/2952/.

Summary
This change causes the loadavg frame to be ignored by the test as it verifies the JS stack frames in the core dump. Additionally, the tests will blow an assertion if the major node version is less than 6, which is when the change to os.loadavg was introduced.

I chose to ignore the loadavg frame, as opposed to changing the tests to expect it based on the node version, for a few reasons:

• There is not an additional stack frame for all major versions of node from 6 and onward. (It isn't there, for instance, in version 7, but it is in 8.)
• Similarly, there may not be a JS stack frame for later versions of node.
• The tests verify the "arg1" output for the first JS frame in the test. This code would need to be modified depending on the version of node the test was running as well, which introduces additional complexity to the test.

You could also imagine a fix in which we ignore all stack frames until the first JS frame expected, the stalloogle frame, is found. I opted to not do this approach out of concern that it could hide other bugs from the test. The tradeoff is that we may have to make a similar change to this change again if os.loadavg introduces an additional JS stack frame in later node versions. Given that this is probably unlikely, and this change is relatively straightforward, that this tradeoff seems reasonable to me.

Testing Notes

• make prepush clean
• tools/runtests_node run <versions dir passes for all versions