Re: weird assertion failure in js::NewContext (JS60)

I found out what my problem was.

My interpreter global is this:

JS::PersistentRooted<JS Object *> global;

So since it's a JS::PersistentRootedObject, it needs this before it's 
assigned a value:

global.init(context);

This will cause a problem if there is an active JSAutoRequest.  The init 
has to happen before entering the request.

I found another request-related issue -- if you're building for 
Debugging, Spidermonkey throws an error if you call JS::DestroyContext 
with a request still outstanding.

On 3/28/19 12:29 PM, [email protected] wrote:
> On Wednesday, March 27, 2019 at 5:40:45 PM UTC-4, Kent Williams wrote:
>> This is an app that embeds JS60 SpiderMonkey (checked out from github
>> and based on the the JS60 release tag)
>>
>> The same code seems to work fine in a bunch of my own tests.  I passed
>> it off to another programmer, and he somehow gets it to segfault.
>>
>> My mystery is that the stuff he's doing follows EXACTLY the same path
>> into the SpiderMonkey code as everything else I've done.
>>
>> The crash comes on this line:
>>
>>       MOZ_RELEASE_ASSERT(!TlsContext.get());
>>
>> at the top of js::NewContext()
>>
>> I don't know what TlsContext.get() is supposed to return, except in this
>> case it's returning NULL/nullptr.
>>
>> Any clues.
> The TlsContext here is an accessor for the JSContext bound to the current thread. The assert is checking that there currently is no existing JSContext and suggests that the js::NewContext() was called twice on the same thread.
>
> --Ted
> _______________________________________________
> dev-tech-js-engine mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
_______________________________________________
dev-tech-js-engine mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine