How to create multiple contexts in different threads?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

How to create multiple contexts in different threads?

clement.vuchener
Hi.

I am currently writing an application with mozjs-38 using multiple contexts, each with its own thread. They do not share any js value, so if I understand correctly, that should be possible.

Currently, I am creating one new runtime for each context/thread and that seems to work OK with Fedora's release build. But I tried a debug build from source (38.2.1.rc0 from documentation page) to make sure things are OK and assertions failed.

When creating the second runtime, I get:
Assertion failure: !currentThreadOwnsGCLock(), at /home/clement/src/mozjs-38.0.0/js/src/gc/GCRuntime.h:694

I tried creating a common parent runtime as I have read some suggestions for that but then I did not find a way to create runtimes or contexts or requests in a different thread then.

How should I create runtimes and contexts in this kind of application?
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: How to create multiple contexts in different threads?

Jason Orendorff-2
On Sat, Mar 26, 2016 at 7:12 AM, <[hidden email]> wrote:

> I am currently writing an application with mozjs-38 using multiple
> contexts, each with its own thread. They do not share any js value, so if I
> understand correctly, that should be possible.
>

Yes, this should work.

Currently, I am creating one new runtime for each context/thread and that
> seems to work OK with Fedora's release build. But I tried a debug build
> from source (38.2.1.rc0 from documentation page) to make sure things are OK
> and assertions failed.
>
> When creating the second runtime, I get:
> Assertion failure: !currentThreadOwnsGCLock(), at
> /home/clement/src/mozjs-38.0.0/js/src/gc/GCRuntime.h:694
>

OK. Does this happen when you call JS_NewRuntime, or later? Can you get a
stack trace?

I tried creating a common parent runtime as I have read some suggestions
> for that but then I did not find a way to create runtimes or contexts or
> requests in a different thread then.
>

It should work whether you use a parent runtime or not.


> How should I create runtimes and contexts in this kind of application?
>

Well ... the JS shell has some example code you could look at. It has an
evalInWorker() function that spawns a thread. The new thread is created
here:

https://hg.mozilla.org/integration/mozilla-inbound/file/e9954f2bede1/js/src/shell/js.cpp#l3027
and the function that runs in the thread is WorkerMain:

https://hg.mozilla.org/integration/mozilla-inbound/file/e9954f2bede1/js/src/shell/js.cpp#l2887

But from what you've said, it sounds like you are using the API correctly.
If you call JS_NewRuntime first thing in a new thread, it should succeed.
Something else is wrong. Get a stack trace.

-j
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: How to create multiple contexts in different threads?

clement.vuchener
In reply to this post by clement.vuchener
On Monday, March 28, 2016 at 11:42:43 PM UTC+2, Jason Orendorff wrote:

> On Sat, Mar 26, 2016 at 7:12 AM, Clément Vuchener wrote:
>
> > I am currently writing an application with mozjs-38 using multiple
> > contexts, each with its own thread. They do not share any js value, so if I
> > understand correctly, that should be possible.
> >
>
> Yes, this should work.
>
> Currently, I am creating one new runtime for each context/thread and that
> > seems to work OK with Fedora's release build. But I tried a debug build
> > from source (38.2.1.rc0 from documentation page) to make sure things are OK
> > and assertions failed.
> >
> > When creating the second runtime, I get:
> > Assertion failure: !currentThreadOwnsGCLock(), at
> > /home/clement/src/mozjs-38.0.0/js/src/gc/GCRuntime.h:694
> >
>
> OK. Does this happen when you call JS_NewRuntime, or later? Can you get a
> stack trace?

It happens in JS_NewRuntime. There may actually be different assertion depending on some race.

First case, one thread fails among two (the application crashes before the third one is created):
Assertion failure: !currentThreadOwnsGCLock(), at /home/clement/src/mozjs-38.0.0/js/src/gc/GCRuntime.h:694

The backtrace for the failed thread:
#0  0x00007ffff6687c88 in js::gc::GCRuntime::assertCanLock (this=0x7fffe8000bf0) at /home/clement/src/mozjs-38.0.0/js/src/gc/GCRuntime.h:694
#1  0x00007ffff665286e in JSRuntime::assertCanLock (this=0x7fffe80008c0, which=js::HelperThreadStateLock) at /home/clement/src/mozjs-38.0.0/js/src/vm/Runtime.cpp:824
#2  0x00007ffff66528ea in js::AssertCurrentThreadCanLock (which=js::HelperThreadStateLock) at /home/clement/src/mozjs-38.0.0/js/src/vm/Runtime.cpp:836
#3  0x00007ffff659a98c in js::GlobalHelperThreadState::lock (this=0x7a5790) at /home/clement/src/mozjs-38.0.0/js/src/vm/HelperThreads.cpp:516
#4  0x00007ffff646a56c in js::AutoLockHelperThreadState::AutoLockHelperThreadState (this=0x7ffff1e0b9bf, _notifier=...) at /home/clement/src/mozjs-38.0.0/js/src/vm/HelperThreads.h:415
#5  0x00007ffff659a430 in js::GlobalHelperThreadState::ensureInitialized (this=0x7a5790) at /home/clement/src/mozjs-38.0.0/js/src/vm/HelperThreads.cpp:446
#6  0x00007ffff6598c46 in js::EnsureHelperThreadsInitialized () at /home/clement/src/mozjs-38.0.0/js/src/vm/HelperThreads.cpp:58
#7  0x00007ffff6650a70 in JSRuntime::init (this=0x7fffe80008c0, maxbytes=8388608, maxNurseryBytes=16777216) at /home/clement/src/mozjs-38.0.0/js/src/vm/Runtime.cpp:268
#8  0x00007ffff6ac7d08 in JS_NewRuntime (maxbytes=8388608, maxNurseryBytes=16777216, parentRuntime=0x0) at /home/clement/src/mozjs-38.0.0/js/src/jsapi.cpp:472

The backtrace for the other thread, also calling JS_NewRuntime:
#0  0x00007ffff4d7e49d in _int_malloc () from /lib64/libc.so.6
#1  0x00007ffff4d7f950 in malloc () from /lib64/libc.so.6
#2  0x00007ffff6ab19c1 in js_malloc (bytes=2384) at ../../dist/include/js/Utility.h:106
#3  0x00007ffff6ae7bec in dtoa_malloc (size=2384) at /home/clement/src/mozjs-38.0.0/js/src/jsdtoa.cpp:47
#4  0x00007ffff6ae7c1a in newdtoa () at /home/clement/src/mozjs-38.0.0/js/src/dtoa.c:498
#5  0x00007ffff6aed020 in js_NewDtoaState () at /home/clement/src/mozjs-38.0.0/js/src/jsdtoa.cpp:504
#6  0x00007ffff665015d in js::PerThreadData::init (this=0x7fffe4010920) at /home/clement/src/mozjs-38.0.0/js/src/vm/Runtime.cpp:98
#7  0x00007ffff659a545 in js::GlobalHelperThreadState::ensureInitialized (this=0x7a5790) at /home/clement/src/mozjs-38.0.0/js/src/vm/HelperThreads.cpp:461
#8  0x00007ffff6598c46 in js::EnsureHelperThreadsInitialized () at /home/clement/src/mozjs-38.0.0/js/src/vm/HelperThreads.cpp:58
#9  0x00007ffff6650a70 in JSRuntime::init (this=0x7fffe40008c0, maxbytes=8388608, maxNurseryBytes=16777216) at /home/clement/src/mozjs-38.0.0/js/src/vm/Runtime.cpp:268
#10 0x00007ffff6ac7d08 in JS_NewRuntime (maxbytes=8388608, maxNurseryBytes=16777216, parentRuntime=0x0) at /home/clement/src/mozjs-38.0.0/js/src/jsapi.cpp:472
#11 0x00000000004ed3e8 in JsHelpers::Thread::run (this=0x7fffec00e650) at /home/clement/projects/input-scripts/src/daemon/JsHelpers/Thread.cpp:71


Second case, two threads among three fail with:
Assertion failure: !HelperThreadState().isLocked(), at /home/clement/src/mozjs-38.0.0/js/src/vm/Runtime.cpp:822

The two failed threads have the same backtrace:
#0  0x00007ffff6652851 in JSRuntime::assertCanLock (this=0x7fffe80008c0, which=js::HelperThreadStateLock) at /home/clement/src/mozjs-38.0.0/js/src/vm/Runtime.cpp:822
#1  0x00007ffff66528ea in js::AssertCurrentThreadCanLock (which=js::HelperThreadStateLock) at /home/clement/src/mozjs-38.0.0/js/src/vm/Runtime.cpp:836
#2  0x00007ffff659a98c in js::GlobalHelperThreadState::lock (this=0x7a5790) at /home/clement/src/mozjs-38.0.0/js/src/vm/HelperThreads.cpp:516
#3  0x00007ffff646a56c in js::AutoLockHelperThreadState::AutoLockHelperThreadState (this=0x7ffff1e8c9bf, _notifier=...) at /home/clement/src/mozjs-38.0.0/js/src/vm/HelperThreads.h:415
#4  0x00007ffff659a430 in js::GlobalHelperThreadState::ensureInitialized (this=0x7a5790) at /home/clement/src/mozjs-38.0.0/js/src/vm/HelperThreads.cpp:446
#5  0x00007ffff6598c46 in js::EnsureHelperThreadsInitialized () at /home/clement/src/mozjs-38.0.0/js/src/vm/HelperThreads.cpp:58
#6  0x00007ffff6650a70 in JSRuntime::init (this=0x7fffe80008c0, maxbytes=8388608, maxNurseryBytes=16777216) at /home/clement/src/mozjs-38.0.0/js/src/vm/Runtime.cpp:268
#7  0x00007ffff6ac7d08 in JS_NewRuntime (maxbytes=8388608, maxNurseryBytes=16777216, parentRuntime=0x0) at /home/clement/src/mozjs-38.0.0/js/src/jsapi.cpp:472

The backtrace for the third thread:
#0  js::detail::HashTable<JS::Zone* const, js::HashSet<JS::Zone*, js::DefaultHasher<JS::Zone*>, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::initialized (this=0x7ffff168ba78)
    at ../../dist/include/js/HashTable.h:1161
#1  0x00007ffff660df29 in js::detail::HashTable<JS::Zone* const, js::HashSet<JS::Zone*, js::DefaultHasher<JS::Zone*>, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::init (this=0x7fffdc022d50,
    length=16) at ../../dist/include/js/HashTable.h:1118
#2  0x00007ffff65f9cf0 in js::HashSet<JS::Zone*, js::DefaultHasher<JS::Zone*>, js::SystemAllocPolicy>::init (this=0x7fffdc022d50, len=16) at ../../dist/include/js/HashTable.h:319
#3  0x00007ffff6759fd8 in JS::Zone::init (this=0x7fffdc022720, isSystemArg=true) at /home/clement/src/mozjs-38.0.0/js/src/gc/Zone.cpp:65
#4  0x00007ffff6650b5c in JSRuntime::init (this=0x7fffdc0008c0, maxbytes=8388608, maxNurseryBytes=16777216) at /home/clement/src/mozjs-38.0.0/js/src/vm/Runtime.cpp:278
#5  0x00007ffff6ac7d08 in JS_NewRuntime (maxbytes=8388608, maxNurseryBytes=16777216, parentRuntime=0x0) at /home/clement/src/mozjs-38.0.0/js/src/jsapi.cpp:472

The top level function for all my threads is:

void Thread::run ()
{
        JSRuntime *rt = JS_NewRuntime (8ul*1024ul*1024ul);
        if (!rt) {
                throw std::runtime_error ("JS_NewRuntime failed");
        }

        JSContext *cx = JS_NewContext (rt, 8192);
        if (!cx) {
                throw std::runtime_error ("JS_NewContext failed");
        }
        JS_SetContextPrivate (cx, this);

        JS_SetErrorReporter (rt, errorReporter);

        try {
                run (cx);
        }
        catch (std::exception &e) {
                Log::error () << "Script failed: " << e.what () << std::endl;
        }

        JS_DestroyContext (cx);
        JS_DestroyRuntime (rt);
}

>
> I tried creating a common parent runtime as I have read some suggestions
> > for that but then I did not find a way to create runtimes or contexts or
> > requests in a different thread then.
> >
>
> It should work whether you use a parent runtime or not.
>
>
> > How should I create runtimes and contexts in this kind of application?
> >
>
> Well ... the JS shell has some example code you could look at. It has an
> evalInWorker() function that spawns a thread. The new thread is created
> here:
>
> https://hg.mozilla.org/integration/mozilla-inbound/file/e9954f2bede1/js/src/shell/js.cpp#l3027
> and the function that runs in the thread is WorkerMain:
>
> https://hg.mozilla.org/integration/mozilla-inbound/file/e9954f2bede1/js/src/shell/js.cpp#l2887
>
> But from what you've said, it sounds like you are using the API correctly.
> If you call JS_NewRuntime first thing in a new thread, it should succeed.
> Something else is wrong. Get a stack trace.
>
> -j

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: How to create multiple contexts in different threads?

Jason Orendorff-2
On Tue, Mar 29, 2016 at 4:16 AM, Clément Vuchener <
[hidden email]> wrote:

> > OK. Does this happen when you call JS_NewRuntime, or later? Can you get a
> > stack trace?
>
> It happens in JS_NewRuntime. There may actually be different assertion
> depending on some race.
>

This is good information.

I'm at a loss. If I were investigating this locally, I would start by
printing the value of lockOwner and PR_GetCurrentThread() in the relevant
places. The initial goal is to figure out if the bug is in SM or NSPR. (You
can do this with GDB rather than messing with the code and recompiling, but
I guess it's a bit of a pain either way.)

How are you building SpiderMonkey and your app? Can you post the configure
command line? Does configuring with --enable-posix-nspr-emulation make it
go away?

At this point, it could still be just about anything, but wild guesses
include:
- enabling exceptions in the app, and not in SpiderMonkey, might mess up
the ABI somehow;
- there could be some NSPR or SM header-vs-runtime version mismatch;
- maybe DEBUG is #defined when compiling some SM source files but not
others, perhaps due to a build system bug when building with unusual options

-j
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: How to create multiple contexts in different threads?

clement.vuchener
In reply to this post by clement.vuchener
On Tuesday, March 29, 2016 at 8:48:32 PM UTC+2, Jason Orendorff wrote:

> On Tue, Mar 29, 2016 at 4:16 AM, Clément Vuchener <
> [hidden email]> wrote:
>
> > > OK. Does this happen when you call JS_NewRuntime, or later? Can you get a
> > > stack trace?
> >
> > It happens in JS_NewRuntime. There may actually be different assertion
> > depending on some race.
> >
>
> This is good information.
>
> I'm at a loss. If I were investigating this locally, I would start by
> printing the value of lockOwner and PR_GetCurrentThread() in the relevant
> places. The initial goal is to figure out if the bug is in SM or NSPR. (You
> can do this with GDB rather than messing with the code and recompiling, but
> I guess it's a bit of a pain either way.)
>
> How are you building SpiderMonkey and your app? Can you post the configure
> command line?

I am using the command line from the documentation: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Build_Documentation with a prefix added.
../configure --enable-debug --disable-optimize --prefix=$HOME/opt/mozjs-38.2.1.rc0-debug

I also tried cloning the mozilla-esr38 repo and I have same problem.

For my application, I am using cmake 3.x with the pkg-config module.
$ PKG_CONFIG_PATH=$HOME/opt/mozjs-38.2.1.rc0-debug/lib/pkgconfig/ pkg-config --cflags --libs js
-include /home/clement/opt/mozjs-38.2.1.rc0-debug/include/mozjs-/js/RequiredDefines.h -I/home/clement/opt/mozjs-38.2.1.rc0-debug/include/mozjs- -I/usr/include/nspr4 -L/home/clement/opt/mozjs-38.2.1.rc0-debug/lib -lmozjs-
Is there anything wrong?

> Does configuring with --enable-posix-nspr-emulation make it go away?

No.

>
> At this point, it could still be just about anything, but wild guesses
> include:
> - enabling exceptions in the app, and not in SpiderMonkey, might mess up
> the ABI somehow;
> - there could be some NSPR or SM header-vs-runtime version mismatch;
> - maybe DEBUG is #defined when compiling some SM source files but not
> others, perhaps due to a build system bug when building with unusual options
>
> -j

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: How to create multiple contexts in different threads?

Boris Zbarsky
On 3/30/16 7:43 AM, Clément Vuchener wrote:
> For my application, I am using cmake 3.x with the pkg-config module.
> $ PKG_CONFIG_PATH=$HOME/opt/mozjs-38.2.1.rc0-debug/lib/pkgconfig/ pkg-config --cflags --libs js
> -include /home/clement/opt/mozjs-38.2.1.rc0-debug/include/mozjs-/js/RequiredDefines.h -I/home/clement/opt/mozjs-38.2.1.rc0-debug/include/mozjs- -I/usr/include/nspr4 -L/home/clement/opt/mozjs-38.2.1.rc0-debug/lib -lmozjs-

Is DEBUG #defined when compiling your application?  It's defined when
compiling SpiderMonkey (you passed --enable-debug) and it's very
important that the DEBUG state of your application and SpiderMonkey
match, because there are things in the SpiderMonkey headers that are
#ifdef DEBUG.

-Boris
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: How to create multiple contexts in different threads?

clement.vuchener
On Wednesday, March 30, 2016 at 3:35:52 PM UTC+2, Boris Zbarsky wrote:

> On 3/30/16 7:43 AM, Clément Vuchener wrote:
> > For my application, I am using cmake 3.x with the pkg-config module.
> > $ PKG_CONFIG_PATH=$HOME/opt/mozjs-38.2.1.rc0-debug/lib/pkgconfig/ pkg-config --cflags --libs js
> > -include /home/clement/opt/mozjs-38.2.1.rc0-debug/include/mozjs-/js/RequiredDefines.h -I/home/clement/opt/mozjs-38.2.1.rc0-debug/include/mozjs- -I/usr/include/nspr4 -L/home/clement/opt/mozjs-38.2.1.rc0-debug/lib -lmozjs-
>
> Is DEBUG #defined when compiling your application?  It's defined when
> compiling SpiderMonkey (you passed --enable-debug) and it's very
> important that the DEBUG state of your application and SpiderMonkey
> match, because there are things in the SpiderMonkey headers that are
> #ifdef DEBUG.
>
> -Boris

I tried adding -D flags used in the js shell compilation since evalInWorker works with it: -DDEBUG -DTRACING -DEXPORT_JS_API -DIMPL_MFBT -DAB_CD= -DNO_NSPR_10_SUPPORT -DMOZILLA_CLIENT. I also fixed my cmake script because the "-include [...]/RequiredDefines.h" from pkg-config was not added. But after all that, I still get the same assertion failures.
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: How to create multiple contexts in different threads?

Jason Orendorff-2
In reply to this post by Boris Zbarsky
Buiding SpiderMonkey creates a header, dist/include/js-config.h, that
defines all these. It is included from jsapi.h (-> jspubtd.h -> jstypes.h
-> js-config.h). I think the easiest way to mess it up is not by failing to
-DDEBUG, but by compiling correctly --- and then linking against the wrong
SM shared library.

-j

On Wed, Mar 30, 2016 at 8:35 AM, Boris Zbarsky <[hidden email]> wrote:

> On 3/30/16 7:43 AM, Clément Vuchener wrote:
>
>> For my application, I am using cmake 3.x with the pkg-config module.
>> $ PKG_CONFIG_PATH=$HOME/opt/mozjs-38.2.1.rc0-debug/lib/pkgconfig/
>> pkg-config --cflags --libs js
>> -include
>> /home/clement/opt/mozjs-38.2.1.rc0-debug/include/mozjs-/js/RequiredDefines.h
>> -I/home/clement/opt/mozjs-38.2.1.rc0-debug/include/mozjs-
>> -I/usr/include/nspr4 -L/home/clement/opt/mozjs-38.2.1.rc0-debug/lib -lmozjs-
>>
>
> Is DEBUG #defined when compiling your application?  It's defined when
> compiling SpiderMonkey (you passed --enable-debug) and it's very important
> that the DEBUG state of your application and SpiderMonkey match, because
> there are things in the SpiderMonkey headers that are #ifdef DEBUG.
>
> -Boris
>
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: How to create multiple contexts in different threads?

clement.vuchener
In reply to this post by Boris Zbarsky
On Wednesday, March 30, 2016 at 6:24:38 PM UTC+2, Jason Orendorff wrote:
> Buiding SpiderMonkey creates a header, dist/include/js-config.h, that
> defines all these. It is included from jsapi.h (-> jspubtd.h -> jstypes.h
> -> js-config.h). I think the easiest way to mess it up is not by failing to
> -DDEBUG, but by compiling correctly --- and then linking against the wrong
> SM shared library.

I am sure I am using the correct library, the path is everywhere: in the assertion message, in the backtrace, ... And the offsetof warning tell me which header are included.

I rewrote a simple program:
#include <cstdlib>
#include <cstdio>
#include <jsapi.h>
extern "C" {
#include <pthread.h>
}

constexpr uint32_t RT_MAX_BYTES = 8ul*1024ul*1024ul;
JSRuntime *main_rt;

void *worker (void *arg)
{
        JSRuntime *rt = JS_NewRuntime (RT_MAX_BYTES, JS::DefaultNurseryBytes, main_rt);
        if (!rt)
                fprintf (stderr, "JS_NewRuntime failed");
        printf ("in worker\n");
        JS_DestroyRuntime (rt);
}

int main ()
{
        int ret;

        if (!JS_Init ()) {
                fprintf (stderr, "JS_Init failed\n");
                return EXIT_FAILURE;
        }

        main_rt = JS_NewRuntime (RT_MAX_BYTES);
        if (!main_rt)
                fprintf (stderr, "JS_NewRuntime failed");

        pthread_t thread;
        if (0 != (ret = pthread_create (&thread, nullptr, worker, nullptr))) {
                fprintf (stderr, "pthread_create failed: %s\n", strerror (ret));
        }
        pthread_join (thread, nullptr);

        JS_DestroyRuntime (main_rt);

        JS_ShutDown ();
        return EXIT_SUCCESS;
}
This should work, right?

Assertion failure: !isLocked(), at /home/clement/src/mozilla-esr38/js/src/vm/HelperThreads.cpp:515

(gdb) bt
#0  0x00007ffff67abd12 in js::GlobalHelperThreadState::lock (this=0x614ca0) at /home/clement/src/mozilla-esr38/js/src/vm/HelperThreads.cpp:515
#1  0x00007ffff667a422 in js::AutoLockHelperThreadState::AutoLockHelperThreadState (this=0x7ffff4f09dbf, _notifier=...) at /home/clement/src/mozilla-esr38/js/src/vm/HelperThreads.h:415
#2  0x00007ffff67ab78a in js::GlobalHelperThreadState::ensureInitialized (this=0x614ca0) at /home/clement/src/mozilla-esr38/js/src/vm/HelperThreads.cpp:446
#3  0x00007ffff67a9f5a in js::EnsureHelperThreadsInitialized () at /home/clement/src/mozilla-esr38/js/src/vm/HelperThreads.cpp:58
#4  0x00007ffff6862fc4 in JSRuntime::init (this=0x7fffc80008c0, maxbytes=8388608, maxNurseryBytes=16777216) at /home/clement/src/mozilla-esr38/js/src/vm/Runtime.cpp:268
#5  0x00007ffff6cdccaa in JS_NewRuntime (maxbytes=8388608, maxNurseryBytes=16777216, parentRuntime=0x615020) at /home/clement/src/mozilla-esr38/js/src/jsapi.cpp:472
#6  0x0000000000400a5b in worker (arg=0x0) at main.cpp:13
#7  0x00007ffff620d60a in start_thread () from /lib64/libpthread.so.0
#8  0x00007ffff56aca4d in clone () from /lib64/libc.so.6
(gdb) info threads
  Id   Target Id         Frame
* 10   Thread 0x7ffff4f0a700 (LWP 18925) "a.out" 0x00007ffff67abd12 in js::GlobalHelperThreadState::lock (this=0x614ca0) at /home/clement/src/mozilla-esr38/js/src/vm/HelperThreads.cpp:515
  9    Thread 0x7ffff4f8b700 (LWP 18924) "Analysis Helper" 0x00007ffff6212b10 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  8    Thread 0x7ffff500c700 (LWP 18923) "Analysis Helper" 0x00007ffff6212b10 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  7    Thread 0x7ffff508d700 (LWP 18922) "Analysis Helper" 0x00007ffff6212b10 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  6    Thread 0x7ffff510e700 (LWP 18921) "Analysis Helper" 0x00007ffff6212b10 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  5    Thread 0x7ffff518f700 (LWP 18920) "Analysis Helper" 0x00007ffff6212b10 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  4    Thread 0x7ffff7ec6700 (LWP 18919) "Analysis Helper" 0x00007ffff6212b10 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  3    Thread 0x7ffff7f47700 (LWP 18918) "Analysis Helper" 0x00007ffff6212b10 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  2    Thread 0x7ffff7fc8700 (LWP 18917) "Analysis Helper" 0x00007ffff6212b10 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  1    Thread 0x7ffff7fca740 (LWP 18912) "a.out" 0x00007ffff620e6ad in pthread_join () from /lib64/libpthread.so.0

Compiled with:
g++ -g -std=c++11 main.cpp -include /home/clement/opt/mozjs-38.hg-debug/include/mozjs-38/js/RequiredDefines.h -I/home/clement/opt/mozjs-38.hg-debug/include/mozjs-38 -I/usr/include/nspr4 -L/home/clement/opt/mozjs-38.hg-debug/lib -lmozjs-38 -lpthread
and LD_LIBRARY_PATH=/home/clement/opt/mozjs-38.hg-debug/lib/

I don't know enough about SM internals to know the relevant places to test that but when the assertion fails lockOwner is null. PR_GetCurrentThread () also returns 0.
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: How to create multiple contexts in different threads?

clement.vuchener
On Wednesday, March 30, 2016 at 9:09:46 PM UTC+2, [hidden email] wrote:
> PR_GetCurrentThread () also returns 0.

That should not happen according to the documentation. I added an assertion in isLock to make sure it was not because gdb and it fails:
Assertion failure: PR_GetCurrentThread()!=nullptr, at /home/clement/src/mozilla-esr38/js/src/vm/HelperThreads.cpp:537

Any idea about why this happens? Should I ask on a NSPR mailing list instead?
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: How to create multiple contexts in different threads?

clement.vuchener
On Wednesday, March 30, 2016 at 9:17:53 PM UTC+2, [hidden email] wrote:
> On Wednesday, March 30, 2016 at 9:09:46 PM UTC+2, [hidden email] wrote:
> > PR_GetCurrentThread () also returns 0.
>
> That should not happen according to the documentation. I added an assertion in isLock to make sure it was not because gdb and it fails:
> Assertion failure: PR_GetCurrentThread()!=nullptr, at /home/clement/src/mozilla-esr38/js/src/vm/HelperThreads.cpp:537
>
> Any idea about why this happens? Should I ask on a NSPR mailing list instead?

I think I solved most of my problems.

The PR_GetCurrentThread problem was solved by using --with-system-nspr configure option. I am still unsure where the broken NSPR that was used before came from.

I then got some race with signal handler installation. From AsmJSSignalHandlers.js:1011 (js::EnsureSignalHandlersInstalled)
    // All the rest of the handlers are process-wide and thus must only be
    // installed once. We assume that there are no races creating the first
    // JSRuntime of the process.
So I created a parent runtime before every other to make sure there was no race when initializing global data.

And there was some segfault because of undefined DEBUG (js-config.h only defines JS_DEBUG, but DEBUG is used in some public headers, is that a bug?).

Finally there was some more assertion failures but they were the kind I was expecting from a debug build in order to fix my code.

Thanks for your help.
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: How to create multiple contexts in different threads?

Jason Orendorff-2
On Thu, Mar 31, 2016 at 6:13 AM, <[hidden email]> wrote:

> On Wednesday, March 30, 2016 at 9:17:53 PM UTC+2, [hidden email]
> wrote:
> > On Wednesday, March 30, 2016 at 9:09:46 PM UTC+2, [hidden email]
> wrote:
> > > PR_GetCurrentThread () also returns 0.
> >
> > That should not happen according to the documentation. I added an
> assertion in isLock to make sure it was not because gdb and it fails:
> > Assertion failure: PR_GetCurrentThread()!=nullptr, at
> /home/clement/src/mozilla-esr38/js/src/vm/HelperThreads.cpp:537
> >
> > Any idea about why this happens? Should I ask on a NSPR mailing list
> instead?
>
> I think I solved most of my problems.
>

I'm relieved to hear it.

The PR_GetCurrentThread problem was solved by using --with-system-nspr
> configure option. I am still unsure where the broken NSPR that was used
> before came from.
>

Can GDB tell you this? Perhaps with:
  (gdb) info sharedlibrary
or by stepping into the PR_GetCurrentThread function.

I'd really like to understand what's going on here. I believe the default
is --enable-posix-nspr-emulation, which means that no NSPR is linked or
#included at all. Instead the shim code in js/src/vm/PosixNSPR.cpp is used.
But I don't see how that file's implementation of PR_GetCurrentThread could
possibly return nullptr, no matter how broken pthreads is.

I then got some race with signal handler installation. From
> AsmJSSignalHandlers.js:1011 (js::EnsureSignalHandlersInstalled)
>     // All the rest of the handlers are process-wide and thus must only be
>     // installed once. We assume that there are no races creating the first
>     // JSRuntime of the process.
> So I created a parent runtime before every other to make sure there was no
> race when initializing global data.
>

This is documented in the comment on JS_NewRuntime in jsapi.h, at least.
The state of the documentation, admittedly, is awful.

And there was some segfault because of undefined DEBUG (js-config.h only
> defines JS_DEBUG, but DEBUG is used in some public headers, is that a bug?).
>

Well, yes. ...But looking closer, I'm now unsure just how we should fix it.
Filed <https://bugzilla.mozilla.org/show_bug.cgi?id=1261161>.

Thanks for your help.
>

I'm not sure we were any help to you at all, but thanks for posting here
and thanks for following up.

-j
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine