Crash in webserver when declaring very first HandleScope

[Charles Lowell]

Hi,

I noticed that if I initialize v8 in one thread, and then try and do
*anything* in a different thread without using a v8::Locker (even
creating a new HandleScope), that I get a crash. I still get a crash
even though the code is synchronized by other means and never
executing at the same time. That's ok, I just want to make sure that
the behavior is intentional and I'm not missing something.

cheers,
Charles

[Mads Sig Ager]

Hi Charles,

that is the intended behavior. One V8 isolate can only be used without
Lockers from only one thread. If you want to use multiple threads in
one isolate you have to use Lockers even if you know that they are not
accessing V8 at the same time. One of the things you will typically
see when one isolate from multiple threads without Lockers is
stack-overflow exceptions. These are caused by using the stack limit
from one thread while using V8 with another thread. Using Lockers
ensures exclusive access and also sets up various things used
internally such as the stack guard.

Cheers, -- Mads

> --
> v8-users mailing list
> v8-u...@googlegroups.com
> http://groups.google.com/group/v8-users
>

[Stephan Beal]

On Tue, Jun 7, 2011 at 7:50 AM, Charles Lowell <cow...@thefrontside.net> wrote:

I noticed that if I initialize v8 in one thread, and then try and do
*anything* in a different thread without using a v8::Locker (even

...

To expand a tiny bit on Mads' answer: if your library-level routines will use a Locker, be sure that you main() (or pre-v8-setup) routine also contains a Locker in place. If you don't, the lib-level routines will crash with a v8 assertion (incorrect use of the Locker). When used in main() (or equivalent), the Locker needs to be the first v8 routine/class used, with the exception that V8::SetFlagsFromCommandLine() may (apparently) be legally called before the Locker is in place. There is an example here:

http://code.google.com/p/v8-juice/source/browse/trunk/src/client/shell/shell.cc

search for "Locker".

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

[Charles Lowell]

Fantastic! As always, thanks so much for your help guys.

cheers,
Charles


On Jun 7, 3:02 am, Stephan Beal <sgb...@googlemail.com> wrote:

> On Tue, Jun 7, 2011 at 7:50 AM, Charles Lowell <cowb...@thefrontside.net>wrote:
>
> > I noticed that if I initialize v8 in one thread, and then try and do
> > *anything* in a different thread without using a v8::Locker (even
> > ...
>
> To expand a tiny bit on Mads' answer: if your library-level routines will
> use a Locker, be sure that you main() (or pre-v8-setup) routine also
> contains a Locker in place. If you don't, the lib-level routines will crash
> with a v8 assertion (incorrect use of the Locker). When used in main() (or
> equivalent), the Locker needs to be the first v8 routine/class used, with
> the exception that V8::SetFlagsFromCommandLine() may (apparently) be legally
> called before the Locker is in place. There is an example here:
>

> http://code.google.com/p/v8-juice/source/browse/trunk/src/client/shel...
>
> <http://code.google.com/p/v8-juice/source/browse/trunk/src/client/shel...>search

[Stephan Beal]

On Tue, Jun 7, 2011 at 10:02 AM, Stephan Beal <sgb...@googlemail.com> wrote:

On Tue, Jun 7, 2011 at 7:50 AM, Charles Lowell <cow...@thefrontside.net> wrote:

I noticed that if I initialize v8 in one thread, and then try and do
*anything* in a different thread without using a v8::Locker (even

...

To expand a tiny bit on Mads' answer: if your library-level routines will use a Locker, be sure that you main() (or pre-v8-setup) routine also contains a Locker in place. If you don't, the lib-level routines will crash with a

Correction: if you use an UNLocker in library-level code, be sure that at least one Locker is in place (ideally in main() or equivalent).

A bit of background: i added a v8 binding for the C sleep() routine and it looked something like this:

Unlocker sentry;

::sleep(...);

the point being to free up v8 for activity while sleep() was doing nothing.

The problem is that if there is no Locker in place, the Unlocker will trigger an assertion, killing v8 and your app. When working at the library-level, as opposed to the app level, we cannot assume that a Locker is always in place (as that assumption causes the above code to crash the client's app), and we have no way of knowing if one is active.

So i recommend adding a Locker to the base v8 initialization code for a given app, since that app might run scripts which themselves run a function (like sleep()) which uses an Unlocker.