Closed Bug 1283167 Opened 5 years ago Closed 5 years ago

Remove MOZ_SELFHOSTEDJS

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
firefox51 --- fixed

People

(Reporter: wahib-mkadmi, Assigned: jorendorff)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Steps to reproduce:

1) Built Firefox from source (Tried 45 ESR, 46, 47) 
2) Invoked JS shell with the following: 
Wahib MKADMI@TayebTube ~/obj-i686-pc-mingw32/js/src
$ MOZ_SELFHOSTEDJS='./selfhosted.js' ./js

_______
Steps listed in the last section of this page: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/self-hosting


Actual results:

Error then crash: 

Assertion failure: IsGlobalLexicalScope(scopeChain) || script->hasNonSyntacticScope() (Only global scripts with non-syntactic scopes can be executed with interesting scopechains), at e:/Projects/Firefox/45-esr/js/src/vm/Interpreter.cpp:670

Firefox crashes without error.


Expected results:

Load selfhosted.js for testing.
Forgot to specify, selfhosted.js is vanilla, still haven't touched it. 

Thanks, and keep up the good work.
OS: Unspecified → All
Hardware: Unspecified → All
Running a browser build now to see if I can reproduce this.

I wonder if this environment variable is honored when running the browser. It shouldn't be: this feature is for engine hackers only. Right?
Hi, 

Thanks for your interest on the issue. 

I believe it is honored, have tested it. (Changed env var name, no error, changed file name: the regular no file found, so it's definitely honored).

It is indeed for engine hackers.
Hmm. I can't reproduce this using the latest sources. Maybe it was fixed recently. How are you building JS?
Flags: needinfo?(wahib-mkadmi)
I built it along with the whole browser (mach build). 
What other info do I need to provide ? (I'm still quite new to Mozilla source)
Here's the selfhosted.js I'm trying to use, just in case http://pastebin.com/nZ2iQyUZ
It loads correctly when compiled and ran in the browser.
(In reply to wahib-mkadmi from comment #5)
> I built it along with the whole browser (mach build). 

That's what I wanted to know.

----

I talked with Till, who added this feature. He thinks it's no longer necessary. Changes to self-hosted code can be done directly in the source files (such as js/src/builtin/Object.js).

After changing something, you'll have to rebuild, but that's not so bad. Rebuilds are faster now than they were when MOZ_SELFHOSTEDJS was originally added.
Flags: needinfo?(wahib-mkadmi)
Summary: Passing MOZ_SELFHOSTEDJS causes crash → Remove MOZ_SELFHOSTEDJS
Pardon my ignorance, but how does that relate to the error I'm encountering ?

Anyway, I downloaded the latest beta source, and built it and got my selfhosted.js, still the same problem, tried to run even in VM.

How are you setting your build up ? How are you successfully doing it ?
MozReview-Commit-ID: 6AqQsiNe6zN
Attachment #8766601 - Flags: review?(till)
Assignee: nobody → jorendorff
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I see you removed MOZ_SELFHOSTEDJS, is there an alternative ?
Comment on attachment 8766601 [details] [diff] [review]
Remove MOZ_SELFHOSTEDJS

Review of attachment 8766601 [details] [diff] [review]:
-----------------------------------------------------------------

Thank you.
Attachment #8766601 - Flags: review?(till) → review+
(In reply to wahib-mkadmi from comment #10)
> I see you removed MOZ_SELFHOSTEDJS, is there an alternative ?

Can you say a bit more about what you want to do? MOZ_SELFHOSTEDJS is just a debugging help for working on self-hosted JS that allows (allowed) one to test changes and add debug logs without recompiling. As Jason said above, that's less important than it used to be because touching self-hosted JS doesn't cause multi-minute build times for the browser anymore.
(In reply to Till Schneidereit [:till] from comment #12)

> Can you say a bit more about what you want to do? 

I'm trying to modify the behavior of the internationalization API for the built in modules, for example, for date, when `date.toLocaleString()` is called, I want to hook it so it returns the result formatted in a locale I provide (using registry, config file, you name it..) without changing the browser/system language. MOZ_SELFHOSTEDJS used to provide a simple way to do it since we dealt with plain JavsScript. 

> less important than it used to be because touching self-hosted JS doesn't cause multi-minute build times for the browser anymore.
So mach build on top of the built firefox will relaod self-hosted js ?
(In reply to wahib-mkadmi from comment #13)
> I'm trying to modify the behavior of the internationalization API for the
> built in modules, for example, for date, when `date.toLocaleString()` is
> called, I want to hook it so it returns the result formatted in a locale I
> provide (using registry, config file, you name it..) without changing the
> browser/system language. MOZ_SELFHOSTEDJS used to provide a simple way to do
> it since we dealt with plain JavsScript.

That's...an interesting use case.  And calling JS_SetDefaultLocale won't work because that would affect the rest of JS's behavior in the browser, including in chrome code?  That's really the supported API to determine how locale-aware Intl APIs should work without an explicitly chosen locale.

In any event, I don't think it's one that supports preserving MOZ_SELFHOSTEDJS as an "interface".  It might have "worked" for that purpose, but so many things can go wrong with miswritten self-hosted JS that it's really pretty dangerous for this to be an API.

(I'd be willing to bet the rest of the British currency I have on me, at the tail end of a trip to Britain, that your self-hosted JS causes observable deviations from specification requirements.  It'd be near-trivial for your changes to have security/stability/reliability ramifications, because of how fragile self-hosted code is.)
Well... since you're building a browser anyway, you could patch js/src/builtin/Intl.js. But depending on what you're doing, that may not solve your problem.

Can you tell us more about what you're trying to do? What locale? Ideally we'd support your locale natively.
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #14) 
> That's...an interesting use case.  And calling JS_SetDefaultLocale won't
> work because that would affect the rest of JS's behavior in the browser,
> including in chrome code?  That's really the supported API to determine how
> locale-aware Intl APIs should work without an explicitly chosen locale.
> 
> In any event, I don't think it's one that supports preserving
> MOZ_SELFHOSTEDJS as an "interface".  It might have "worked" for that
> purpose, but so many things can go wrong with miswritten self-hosted JS that
> it's really pretty dangerous for this to be an API.
> 
> (I'd be willing to bet the rest of the British currency I have on me, at the
> tail end of a trip to Britain, that your self-hosted JS causes observable
> deviations from specification requirements.  It'd be near-trivial for your
> changes to have security/stability/reliability ramifications, because of how
> fragile self-hosted code is.)

I didn't originally intend to change any logic except the code that decides which locale is finally to be used, but I guess I'm finally going with the JS_SetDefaultLocale approach.
I wouldn't place much bet on that though neither lol. 

(In reply to Jason Orendorff [:jorendorff] from comment #15)
> Well... since you're building a browser anyway, you could patch
> js/src/builtin/Intl.js. But depending on what you're doing, that may not
> solve your problem.
> 
> Can you tell us more about what you're trying to do? What locale? Ideally
> we'd support your locale natively.

My project is actually about an advanced fingerprint-spoofing browser. A common fingerprinting technique is using the toLocaleString methods as a fingerprinting vector. So I want to be able to modify the (default ?) locale to be used - more like https://trac.torproject.org/projects/tor/attachment/ticket/13019/0001-Bug-5926-Spoof-default-JavaScript-locale-as-en-US.patch but give the user the choice of this locale (through a separate software), but **without** affecting the language of the UI.
https://hg.mozilla.org/mozilla-central/rev/9193c55ec783
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in before you can comment on or make changes to this bug.