Kyle, what you're basically doing is the equivalent of returning
references into stack frames. That'll fail once the frame is gone. If
you build v8 with mode=debug you should hopefully get more and better
errors on the spot.
While all objects live in the V8 heap, the GC needs your help to
identify which objects you are referencing from native code. So you
don't get to point directly into the heap but through the Handle
indirection. The "Local" kind of handles does live on a stack, namely
in HandleScopes. Whenever a Local handle is created, it is allocated
within the currently active HandleScope. When the HandleScope closes,
it doesn't necessarily mean that the target of the reference is gone,
but that your Local is no longer known to V8 and it might relocate the
object or overwrite your Handle with something else.
So: never let a Local escape outside of its HandleScope. But how do
deal with returning a Handle from a nested scope? Use
"HandleScope::Close". It takes the argument, and returns an identical
Handle allocated in the parent scope, so you can safely leave the
current (A2_broken: L10: return handle_scope.Close(script->Run());).
If that helps, this is the equivalent of the Push/PopLocalFrame
functions of JNI.
I think you're just lucky that the getObj in B1&B2 work.
B2 doesn't look like the actual code anyway
(printf("$s\n",s3_2.c_str()); certainly won't print "undefined")
PS: Context::Scopes are thread-local, you don't need to open them in
every function you call. One outer Context::Scope is typically enough.
The same does hold for HandleScopes but here it is a good idea to
stack them and release references as early as possible.
On Sun, Jan 9, 2011 at 7:04 AM, getify <[email protected]> wrote:
> OK, thank you all for the help with variable conversions. I think I
> mostly have that part figured out.
>
> However, I've now run into a frustrating problems with calling
> JavaScript functions from c++. I made this gist to illustrate:
>
> https://gist.github.com/771459
>
> There's 4 snippets list there.
>
> `A1_works` and `A2_broken` show one variation of the problem, and how
> it works versus how it breaks.
>
> Similarly, `B1_works` and `B2_broken` shows (I think the same??)
> problem, and how it works versus how it breaks.
>
> In `A2_broken`, I create a helper function that captures and stores
> the JS function reference, and then returns that reference to be used
> in another context.
>
> In `B2_broken`, I do the reverse, and capture and store the JS
> function reference in the global scope, and try to use that global
> inside a function.
>
> If I interpret what I'm seeing correctly, when I capture in my C++ a
> reference to a JavaScript function, and store that in a variable, if I
> do that process in a different context scope than where I use that
> function reference to execute it (and get back its results), things go
> haywire.
>
> Can someone help me sort out what's going wrong here?
>
> --Kyle
>
> --
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
