Another change you might want to consider is if you really need to resurrect an object after it has become weak.
I recently moved Node.js-core away from the deprecated SetWeak API. With a little bit of cleanup, I was able to avoid all the cases where node core was resurrecting an object in the weak callback. It depends on what you are ultimately doing weak references, but it is worth considering if you really need to resurrect objects. On Tue, Apr 12, 2016 at 11:26 AM, <[email protected]> wrote: > We were using NAN 2.x before with node-weak and node.js 4.x without this > issue so I assume that the V8 update to 46 alters the behaviour of the > callback passed into the SetWeak method. > > Can you clarify how I would be able to get the old behaviour back by > changing the node-weak module? > > On Tuesday, April 12, 2016 at 8:22:25 PM UTC+2, Jochen Eisinger wrote: >> >> ok, so the update to NAN 2.0 broke the node-weak module. Using the >> kParameter weakness type means that the weak callback will come after the >> object was already GC'd, and it's no longer safe to access the object in >> the callback. >> >> In fact, the requirement for the callback is that it doesn't invoke any >> function in the VM but resets the persistent handle. If you need to do any >> post-processing, you can register a second-pass callback that will be >> invoked later when it's again safe to call into v8. >> >> If you require the old behavior of getting a pointer to object before it >> dies, you have to rely on the deprecated SetWeak methods (I guess we should >> consider undeprecating it...) >> >> On Tue, Apr 12, 2016 at 8:11 PM <[email protected]> wrote: >> >>> Evaluating callback on that stack: 0x5a738dc0 >>> {weakref.node!Nan::imp::FunctionCallbackWrapper(const >>> v8::FunctionCallbackInfo<v8::Value> &)} >>> >>> On Tuesday, April 12, 2016 at 7:48:11 PM UTC+2, Jochen Eisinger wrote: >>> >>>> What function is "callback" in the HandleApiCallHelper frame pointing >>>> to? >>>> >>>> On Tue, Apr 12, 2016, 7:36 PM <[email protected]> wrote: >>>> >>>>> I should have mentioned my original bug report against V8: >>>>> https://bugs.chromium.org/p/v8/issues/detail?id=4830 >>>>> >>>>> The stacktrace (with node running in debug mode) would be: >>>>> https://gist.github.com/bpasero/fb5f8a6022b37f7b1a34 >>>>> >>>>> I am sitting in the Visual Studio debugger right at the FAIL call and >>>>> can examine the object. Typing "this" just returns that it is a >>>>> v8::internal::Object with a value of 0x0baffedf {...} >>>>> >>>>> Btw I am able to run IsOddball() and that returns false. >>>>> >>>>> On Tuesday, April 12, 2016 at 7:31:23 PM UTC+2, Jochen Eisinger wrote: >>>>> >>>>>> and the value of "this" when you hit the FATAL() >>>>>> >>>>>> On Tue, Apr 12, 2016 at 7:33 PM Jochen Eisinger <[email protected]> >>>>>> wrote: >>>>>> >>>>> Could you post a stack trace that leads to the FATAL()? >>>>>>> >>>>>>> On Tue, Apr 12, 2016 at 7:27 PM Ben Noordhuis <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> On Tue, Apr 12, 2016 at 7:11 PM, <[email protected]> wrote: >>>>>>>> > Hi, >>>>>>>> > >>>>>>>> > we (Microsoft VS Code team) are tracking down a very weird native >>>>>>>> crash in >>>>>>>> > our use of node.js (5.10.0, V8 46) that only ever shows up since >>>>>>>> we updated >>>>>>>> > from node.js 4.x (V8 45). It seems that changes (around the >>>>>>>> Garbace >>>>>>>> > Collector?) in V8 46 have an impact to the crash. >>>>>>>> > >>>>>>>> > Specifically, we are using the node-weak module >>>>>>>> > (https://github.com/TooTallNate/node-weak) to be able to get >>>>>>>> weak references >>>>>>>> > onto JavaScript objects. This used to work relatively good in >>>>>>>> node.js 4.x, >>>>>>>> > but with node.js 5.x we suddenly get the entire node.js program >>>>>>>> to terminate >>>>>>>> > with a fatal crash. >>>>>>>> > >>>>>>>> > Today we were finally able to track the location of where the >>>>>>>> crash >>>>>>>> > originates and it seems to happen when our application simply >>>>>>>> calls into a >>>>>>>> > property of the object that is weakly referenced. This call at >>>>>>>> one point >>>>>>>> > reaches the following assertion: >>>>>>>> > >>>>>>>> > void Object::VerifyApiCallResultType() { >>>>>>>> > #if DEBUG >>>>>>>> > if (!(IsSmi() || IsString() || IsSymbol() || IsSpecObject() || >>>>>>>> > IsHeapNumber() || IsSimd128Value() || IsUndefined() || >>>>>>>> IsTrue() || >>>>>>>> > IsFalse() || IsNull())) { >>>>>>>> > FATAL("API call returned invalid object"); >>>>>>>> > } >>>>>>>> > #endif // DEBUG >>>>>>>> > } >>>>>>>> > >>>>>>>> > >>>>>>>> > The process terminates from the FATAL call, as none of the >>>>>>>> previous checks >>>>>>>> > in this method hold. >>>>>>>> > >>>>>>>> > >>>>>>>> > Now, the interesting question is: How would it be possible to >>>>>>>> have a JS >>>>>>>> > object where calling properties on it would fail in such a fatal >>>>>>>> way? It >>>>>>>> > seems to us that the object we are calling a property on is a >>>>>>>> pointer to a >>>>>>>> > location in memory where no V8 object exists anymore. It almost >>>>>>>> seems that >>>>>>>> > the object was garbage collected (or moved to another address?) >>>>>>>> without the >>>>>>>> > JS side (or more specifically the node-weak side) getting to know. >>>>>>>> > >>>>>>>> > >>>>>>>> > Since this only reproduces with using node-weak, it seems very >>>>>>>> likely that >>>>>>>> > there is an issue with either node-weak or NAN. In fact, >>>>>>>> node-weak is >>>>>>>> > calling into SetWeak() >>>>>>>> > ( >>>>>>>> https://github.com/TooTallNate/node-weak/blob/master/src/weakref.cc#L174 >>>>>>>> ) >>>>>>>> > and relies on the fact that the callback passed in is triggered >>>>>>>> and maybe >>>>>>>> > this callback is not triggered anymore in a sync fashion but >>>>>>>> rather async? >>>>>>>> > >>>>>>>> > >>>>>>>> > I would appreciate some pointers if there is something that could >>>>>>>> have >>>>>>>> > probably changed in V8 46 that could have an impact on this. >>>>>>>> >>>>>>>> If you have a simple test case (stress on 'simple'), I'll have a >>>>>>>> look. >>>>>>>> >>>>>>>> -- >>>>>>>> -- >>>>>>>> v8-dev mailing list >>>>>>>> >>>>>>> [email protected] >>>>>>> >>>>>>> >>>>>>>> http://groups.google.com/group/v8-dev >>>>>>>> --- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "v8-dev" group. >>>>>>>> >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>> >>>>>>> >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> -- >>>>> -- >>>>> v8-dev mailing list >>>>> [email protected] >>>>> http://groups.google.com/group/v8-dev >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "v8-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>> -- >>> v8-dev mailing list >>> [email protected] >>> http://groups.google.com/group/v8-dev >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "v8-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Ali -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
