maybe you just got lucky before? The API didn't change for a while now, you can always check bit.ly/v8-api-changes for updates
Anyways, you get the old behavior by using the SetWeak methods that take a WebCallbackData (instead of ...Info), i.e., https://code.google.com/p/chromium/codesearch#chromium/src/v8/include/v8.h&l=564 On Tue, Apr 12, 2016 at 8:26 PM <[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. > -- -- 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.
