Yep, we diagnosed the same yesterday. What happens is this: When trying to construct an External value, we check if the given void* fits in a Smi. If it does, we return a Smi, otherwise we create a Foreign object which wraps the void*. The latter case is problematic, and this is exactly what is intentionally caught by the recently introduced checks: Foreign is a v8-internal data structure which gets suddenly exposed on the JavaScript side, but you can't do anything with it apart from reading and storing it, everything else will crash v8.
We don't want to loosen the checks, because we want to catch exactly those kind of non-JavaScript values returned from native getters/interceptors, something which indicates a bug in the binding. So the correct fix is that External::New should always return a valid JavaScript object. Currently I see two ways of implementing it: * Continue encoding it as a Smi if it fits, but use the 64bit payload of a HeapNumber for all other void*. This would give us "floating pointers"... :-) It's a bit of a hack, but probably the quickest way of fixing the problem at hand. * Create an empty new JavaScript Object which carries the void* as a hidden property (probably as a Foreign). This is the cleaner solution, and I'd like to try this first. Anyway, any sane binding should keep the External value private, so our choice how to fix this shouldn't matter for the embedder. As a quick intermediate workaround, make sure that ENABLE_EXTRA_CHECKS is #undefined when building SilkJS, but this should really only be a temporary measure. Cheers, S. On Thu, Sep 6, 2012 at 8:14 PM, mschwartz <myk...@gmail.com> wrote: > Returns External::New() [...] > -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users
