1005793 - xulrunner mozjs.lib not compiled with JSGC_TRACK_EXACT_ROOTS defined but mozjs.dll in FF delivery is

Status: RESOLVED DUPLICATE of bug 1083464

(Core :: JavaScript Engine, defect)

Description

[Reinhold Degenfellner]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36

Steps to reproduce:

We're using xulrunner 29.0 to interact with FF.
sizeof(JS::CompileOptions) is different in mozjs.dll context than in our code (found by debugger). The reason seams to be additional data members in JS::Rooted (prev, stack) which I guess is caused by compiling with JSGC_TRACK_EXACT_ROOTS. This wasn't the case in prior FF versions.
Is this by intention or a problem with the build?


Actual results:

this prevents us from updating FF support for our product (Silk Test). When compiling our code with JSGC_TRACK_EXACT_ROOTS it doesn't link as the constructor is missing in mozjs.lib and if we compile without it corrupts our memory because of the different sizes of the classes.


Expected results:

not corrupt memory

Comment 1

[Boris Zbarsky [:bzbarsky]]

Reinhold, I'm trying to understand how xulrunner comes into this.

Which set of headers are you compiling against?  What libraries are you linking against?  What libraries are your running against?

Comment 2

[Reinhold Degenfellner]

I guess I was not precise enough.

We use the xulrunner-sdk (http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/29.0/sdk/).
The libraries we are linking are mozjs.lib, xul.lib, xpcomglue_s_nomozalloc.lib, and nss3.lib.
At least the mozjs.lib is just an import library to access the functions from mozjs.dll.
So if i write code using the nsIScriptContext::EvaluateString method some code in mozjs.dll gets called.
This method needs a parameter of type JS::CompileOptions, so we do something like the following:

      nsCxPusher pusher;
      pusher.Push(win.mJsContext);

      JS::CompileOptions compileOptions(win.mJsContext);

      JS::Value retVal;

      JS::RootedObject jsGlobalObject(win.mJsContext, win.mJsGlobalObject);
      if(!NS_SUCCEEDED(win.pScriptGlobalContext->EvaluateString(strCode, jsGlobalObject, compileOptions, true, &retVal))) {
        return SILKTEST_CURRENT_LOCATION_W;
      }

by using JS::CompileOptions on the stack the constructor which resides in mozjs.dll is called.
As JSGC_TRACK_EXACT_ROOTS (IMHO) was defined for compiling FF29 mozjs.dll it adds some debug code to the Rooted<> class which includes adding additional data members.
But usually when you compile against the xulrunner sdk headers we don't need to define JSGC_TRACK_EXACT_ROOTS, so my code reserves to less memory for the additional data members. This leads to a memory corruption on the stack in this case.

The other interesting part is, I tried of course to use JSGC_TRACK_EXACT_ROOTS to get properly sized instances but this ends with a link error as the destructor (CompileOptions::~CompileOptions) is not included in the mozjs.lib which is provided by the xulrunner sdk.

Does that shed some light on my request?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Yep.  Sounds like the real issue is that the SDK is not built with exact rooting support, while Firefox is, so compiling code against the SDK but then running it against Firefox won't work...

Benjamin, do you know what the story on that is?

Comment 4

[Jeff Walden [:Waldo]]

This sounds a bit like the DEBUG versus JS_DEBUG thing wrt embedders on Linux building with debug flags, then having structs with different ABI between the two depending whether the embedder's code was/wasn't compiled as debug.  See bug 939505.

Comment 5

[Benjamin Smedberg]

1) external code shouldn't be using JSAPI. It's a recipe for all kinds of disaster.
2) The SDK is currently built from XULRunner but we should really fix bug 672509 and stop doing XR builds altogether.
3) Nobody really audits the XR build flags, but in general we should try to make them match Firefox.
4) I don't actually see any exact-rooting flags in the Firefox mozconfigs. What build flags actually control this, and why are they ending up as Firefox-specific?

Comment 6

[Reinhold Degenfellner]

This flag is also caused by some other flags e.g. js_debug
Hopefully you don't remove the xr builds too soon, we are relying on that.
We know we shouldn't but it's less pain than doing it again in js currently

Comment 7

[Boris Zbarsky [:bzbarsky]]

> I don't actually see any exact-rooting flags in the Firefox mozconfigs.

Hmm.  It's on by default, but I see nothing in the xulrunner mozconfigs that would disable it either.

Comment 8

[Reinhold Degenfellner]

But is wasn't on with versions prior too 29, am I right with that?
And how would we explain the link error?

Comment 9

[Boris Zbarsky [:bzbarsky]]

> But is wasn't on with versions prior too 29, am I right with that?

Correct.

Comment 10

[Benjamin Smedberg]

http://mxr.mozilla.org/mozilla-central/source/browser/confvars.sh#70 is where this ends up getting set in Firefox.

Comment 11

[Philip Chimento [:ptomato]]

Could this be a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1083464?

Comment 12

[Reinhold Degenfellner]

FYI: As far as we are concerned we can close this issue. We finally moved away from using the sdk.

Comment 13

[Boris Zbarsky [:bzbarsky]]

> Could this be a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1083464?

Effectively yes, though really it's a duplicate of the bug that removed JSGC_TRACK_EXACT_ROOTS...