This error occurs if the pointer is 0. That's an even number last time I looked.
I have been using this facility to storing flags to avoid Object overhead, now all my flags have to be >0 and even :) Stuart. On Thursday, January 3, 2013 7:17:32 AM UTC-5, Stephan Beal wrote: > > On Thu, Jan 3, 2013 at 12:53 PM, Sven Panne <[email protected]<javascript:> > > wrote: > >> Lacking any proof, I somehow doubt that the problem is in v8: :-) Chrome >> uses the aligned pointer API quite heavily for some time now without any >> known problems. >> > > Conversely, lacking any breakage until this change, i doubt the problem is > in my dev environment ;). My code was basically doing the following, but > with a good deal of template-level abstraction/indirection going on around > it: > > T t = new T; > obj->SetPointerInInternalField( n, t ); > > that had worked fine for 2+ years until we were forced to switch to the > strictly-aligned version, at which point the new assertion was triggered. > > >> Could you set a breakpoint in Utils::ReportApiFailure and check that the >> value of the pointer when the error happens? >> > > The problem was resolved/worked around a couple of weeks ago, and i don't > intend on going back to the old sources to check this (especially since > nobody else is reporting this problem). While trying to figure out what was > going on i was spitting out the value from my (new T) call, which was > subsequently stuffed into the internal field, to stderr and did verify that > it was an even number. As i honestly don't expect the strict-alignment code > to be of any use outside of Chromium, my attitude towards it is, "if it > works for Chromium, then it works." That wasn't my experience, but my > experience is now irrelevant ;). The _only_ reason i ever used > SetPointerInInternalField() was because i assumed (wrongly, it turns out) > that it was a convenience form of SetInternalField(x, External::New(...)). > Since Internal Fields hold Value Handles, it never occurred to me that > SetPointerIn... could be anything but a wrapper around an External Value > (famous last assumptions...). > > As you've probably figured out, using External is not really cheap, >> because it involves allocating 2 objects: One JavaScript object with a >> hidden field containing a Foreign, see Heap::AllocateExternal. >> > > i actually hadn't figured that out - as a rule i don't peek into/mess > around with the internals of large/complex libraries i'm using only at the > client level. Anything which isn't in the public API, i pretend it doesn't > exist. That said, i'm not all that worried about a few more bytes in this > context - nobody who's binding JS code to C++ objects truly expects (i > think) them to be featherweights in terms of memory requirements. > > Management summary: let's call this "cannot reproduce" until/unless > someone else has a problem with it. > > :) > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" 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/groups/opt_out.
