deps: update v8 to 4.4.63.26

[targos]

Includes cherry-picks for:

• JitCodeEvent patch: https://crrev.com/f7969b1d5a55e66237221a463daf422ac7611788
• argparse patch: https://crrev.com/44bc918458481d60b08d5566f0f31a79e39b85d7

This is the v8 version of stable Chrome 44.

[ofrobots]

Rubberstamp LGTM.

[rvagg]

I'd love a way to verify that what's in tree is what's upstream, a diff -r perhaps, would that work if I had V8 checked out too? Otherwise I'm hesitant to give an 'lgtm' when I just don't know!

[targos]

@rvagg I just tried your suggestion and it works :)

[ofrobots]

@rvagg that's precisely what I verified before my LGTM. This PR seems to be the equivalent to git diff 4.4.63.12 4.4.63.19 with the exception of the patch we are floating for https://crrev.com/f7969b1d5a55e66237221a463daf422ac7611788.

[targos]

CI: https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/184/

[Fishrock123]

The Centos CI boxes are failing because of this. I suspect the Centos dists we are using use Python 2.6, while argparse was added in Python 2.7.

[Fishrock123]

cc @nodejs/build

[ofrobots]

See previous conversation about this here: #2022 (comment)

[targos]

It has been fixed with https://crrev.com/44bc918458481d60b08d5566f0f31a79e39b85d7 but not backported to 4.4. I will include the patch tomorrow.
Thanks @ofrobots.

[targos]

I cherry-picked the argparse fix.
New CI: https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/189/

[rvagg]

af162c8 lgtm

[targos]

Sorry for the delay, Chrome jumped to 4.4.63.25 so I updated the PR.
https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/198/

[bnoordhuis]

LGTM. The last two regress-crbug tests I missed on the last upgrade, mea culpa.

@targos Maybe you can run the CI one more time? The test-vm-debug-context.js failure on the pi1-raspbian-wheezy is probably a flake but it would be good to have that confirmed.

[targos]

https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/200/

[targos]

@bnoordhuis test-vm-debug-context.js failed again.
I don't have a Pi1, what can I do to investigate ?

[bnoordhuis]

Maybe someone from @nodejs/build can give you temp access?

[targos]

@rvagg gave me access and I could successfully compile but after that I lost control of the machine and I cannot connect anymore.

[ofrobots]

I wonder if it would be possible to reproduce the failure on an QEmu ARM machine. Some instructions here.

[rvagg]

it turns out that ssh tunnel from that machine could only handle one connection, after which it fails to properly accept additional connections, I've set up a tunnel using a different machine to do the same thing and it should be fine .. I hope

[targos]

I'm connected, it is fine, thank you.

[targos]

I've tracked the issue to the following part of the test:

var vm = require('vm');
var assert = require('assert');

// See https://github.com/nodejs/io.js/issues/1190, accessing named interceptors
// and accessors inside a debug event listener should not crash.
(function() {
  var Debug = vm.runInDebugContext('Debug');
  var breaks = 0;

  function ondebugevent(evt, exc) {
    if (evt !== Debug.DebugEvent.Break) return;
    exc.frame(0).evaluate('process.env').properties();  // Named interceptor.
    exc.frame(0).evaluate('process.title').getTruncatedValue();  // Accessor.
    breaks += 1;
  }

  function breakpoint() {
    debugger;
  }

  assert.equal(breaks, 0);
  Debug.setListener(ondebugevent);
  assert.equal(breaks, 0);
  breakpoint();
  assert.equal(breaks, 1);
})();

Crash happens when breakpoint() is called.

The way the process crashes is variable. Here are 3 cases I had:

Segmentation fault

#
# Fatal error in ../deps/v8/src/type-feedback-vector.cc, line 323
# Check failed: feedback == *vector()->UninitializedSentinel(isolate).
#

==== C stack trace ===============================

(empty)
Aborted

module.js:430
  return compiledWrapper.apply(self.exports, args);
                         ^

TypeError: compiledWrapper.apply is not a function
    at Module._compile (module.js:430:26)
    at Object.Module._extensions..js (module.js:448:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Function.Module.runMain (module.js:471:10)
    at startup (node.js:117:18)
    at node.js:947:3

[targos]

Here is a very minimal test case:

var vm = require('vm');

var Debug = vm.runInDebugContext('Debug');

function breakpoint() {
  debugger;
}

Debug.setListener(function(){console.log('debug event')});

console.log('before break');
breakpoint();
console.log('after break');

Output:

before break
debug event
after break


#
# Fatal error in ../deps/v8/src/type-feedback-vector.cc, line 323
# Check failed: feedback == *vector()->UninitializedSentinel(isolate).
#

==== C stack trace ===============================

(empty)
Aborted

The crash happens outside of my script

[bnoordhuis]

Long shot: does it work when you pass --novector_ics?

[targos]

@bnoordhuis yes it does !

[targos]

I'm sorry I don't know what to do now, it is beyond my understanding of v8

[bnoordhuis]

You could disable it in src/node.cc for now, grep for --nofast_math for another ARM example (which could be removed in next+1 but that aside.)

It might be worthwhile to file a V8 issue for it.

[targos]

OK, let's try again with that change

CI: https://jenkins-iojs.nodesource.com/job/node-test-commit/62/