SM38 Weird Windows CompileOptions Behavior

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

SM38 Weird Windows CompileOptions Behavior

markus.moenig
Hi,

using SM 38 on Windows I get some strange behavior.

Rooted<Value> *JSHost::executeScript( const char *script, const char *fileName )
{
    JS::CompileOptions options(cx);
    options.setFileAndLine( fileName, 1 );

    bool ok = JS::Evaluate( cx, *global, options, script, strlen(script), &rcValue );

    ...
}

Basically when this function returns, Windows is displaying a heap corruption and the app terminates.

Now, when I move the CompileOptions out of the function context and into the global namespace it works.

To avoid further crashes, I always have to reuse this one CompileOptions structure, otherwise I get a heap corruption again.

All this works fine on the Mac.

Thanks,

Markus
_______________________________________________
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: SM38 Weird Windows CompileOptions Behavior

Steve Fink-4
On 09/22/2015 02:53 AM, Markus wrote:

> Hi,
>
> using SM 38 on Windows I get some strange behavior.
>
> Rooted<Value> *JSHost::executeScript( const char *script, const char *fileName )
> {
>      JS::CompileOptions options(cx);
>      options.setFileAndLine( fileName, 1 );
>
>      bool ok = JS::Evaluate( cx, *global, options, script, strlen(script), &rcValue );
>
>      ...
> }
>
> Basically when this function returns, Windows is displaying a heap corruption and the app terminates.
>
> Now, when I move the CompileOptions out of the function context and into the global namespace it works.
>
> To avoid further crashes, I always have to reuse this one CompileOptions structure, otherwise I get a heap corruption again.
>
> All this works fine on the Mac.

I can't spot the problem here, but what I can tell you is (1) be sure
you're using a debug build of spidermonkey to develop against (it's very
hard to get things right otherwise, even if you're fairly familiar with
JSAPI), and (2) your rooting isn't right.

Where is rcValue declared? It should be in a local Rooted<Value>
variable, and you should just be returning rcValue. Do not uses Rooted<>
or Rooted<>* as a return value; just return a plain Value. The caller
will very probably want to immediately store it into a Rooted<Value>:

   Rooted<Value> scriptResult(host->cx, host->executeScript("...", "..."));

or

   Rooted<Value> scriptResult(host->cx);
   scriptResult = host->executeScript("...", "...");

though I'd note that the error checking smells a little off here.

Don't use a global Rooted<T>, or use Rooted<T> as a class data member
unless that class is only ever going to be allocated on the stack.
Rooting is cheap; don't avoid it for perf reasons, especially since it's
really really easy to shoot yourself in the foot by being too clever.
Your problem here *might* be that your Rooteds are getting created and
destroyed in non-FIFO order.
_______________________________________________
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: SM38 Weird Windows CompileOptions Behavior

markus.moenig
Thanks again. Will test this once I get everything working again.

Couldnt resist upgrading to Windows 10 and VS 2015 and now SpiderMonkey 38 fails to builld. Trying to figure this out first.

In general porting SM code from the Mac to Windows is a bit of a shock as on the Mac the tolerance level seems to be much higher for SM than under Windows.
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine