Closed
Bug 1416551
Opened 8 years ago
Closed 1 year ago
Segfault in SpiderMonkey internals when running valid JavaScript
Categories
(Core :: JavaScript Engine, defect, P5)
Tracking
()
RESOLVED
INACTIVE
Tracking | Status | |
---|---|---|
firefox59 | --- | unaffected |
People
(Reporter: nathanrogers, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36
Steps to reproduce:
Check out a fresh copy of SpiderMonkey 45 standalone at https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Releases/45. Build it (I used --enable-debug and --disable-optimize).
$ cat index.js
class A {}
class B extends A {
constructor() {
try {
return;
} catch (e) {
try {
return;
} catch (e) {
}
}
}
}
try {
new B;
} catch (e) {
print("Caught: " + e);
}
$ dist/bin/js -f index.js
Assertion failure: !done(), at /tmp/mozjs-45.0.2/js/src/vm/ScopeObject.cpp:1483
Segmentation fault (core dumped)
$ gdb --args dist/bin/js -f index.js
(gdb) r
Assertion failure: !done(), at /tmp/mozjs-45.0.2/js/src/vm/ScopeObject.cpp:1483
Program received signal SIGSEGV, Segmentation fault.
0x0000000000c7f56a in js::ScopeIter::type (this=0x7fffffffcb70)
at /tmp/mozjs-45.0.2/js/src/vm/ScopeObject.cpp:1483
1483 MOZ_ASSERT(!done());
js/src/gdb/mozilla/asmjs.py: Allowing AsmJSFaultHandler to run.
Program received signal SIGSEGV, Segmentation fault.
0x0000000000c7f56a in js::ScopeIter::type (this=0x7fffffffcb70)
at /tmp/mozjs-45.0.2/js/src/vm/ScopeObject.cpp:1483
1483 MOZ_ASSERT(!done());
(gdb) bt
#0 0x0000000000c7f56a in js::ScopeIter::type (this=0x7fffffffcb70)
at /tmp/mozjs-45.0.2/js/src/vm/ScopeObject.cpp:1483
#1 0x0000000000bfd196 in PopScope (cx=0x7ffff6906c00, si=...)
at /tmp/mozjs-45.0.2/js/src/vm/Interpreter.cpp:925
#2 0x0000000000bfd2d9 in js::UnwindScope (cx=0x7ffff6906c00, si=...,
pc=0x7fffedef062e "\206\001\230\310V") at /tmp/mozjs-45.0.2/js/src/vm/Interpreter.cpp:953
#3 0x0000000000bfd57a in SettleOnTryNote (cx=0x7ffff6906c00, tn=0x7ffff69b45a0, si=..., regs=...)
at /tmp/mozjs-45.0.2/js/src/vm/Interpreter.cpp:1011
#4 0x0000000000bfd744 in ProcessTryNotes (cx=0x7ffff6906c00, si=..., regs=...)
at /tmp/mozjs-45.0.2/js/src/vm/Interpreter.cpp:1070
#5 0x0000000000bfdc79 in HandleError (cx=0x7ffff6906c00, regs=...)
at /tmp/mozjs-45.0.2/js/src/vm/Interpreter.cpp:1162
#6 0x0000000000c1536a in Interpret (cx=0x7ffff6906c00, state=...)
at /tmp/mozjs-45.0.2/js/src/vm/Interpreter.cpp:3908
#7 0x0000000000bfac4a in js::RunScript (cx=0x7ffff6906c00, state=...)
at /tmp/mozjs-45.0.2/js/src/vm/Interpreter.cpp:391
#8 0x0000000000bfbeb3 in js::ExecuteKernel (cx=0x7ffff6906c00, script=0x7ffff7e67160,
scopeChainArg=(JSObject &) @0x7ffff7e63070 [object Block], newTargetValue=...,
type=js::EXECUTE_GLOBAL, evalInFrame=AbstractFramePtr ((js::ScriptFrameIter::Data *) 0x0) = {...},
result=0x0) at /tmp/mozjs-45.0.2/js/src/vm/Interpreter.cpp:650
#9 0x0000000000bfc1ad in js::Execute (cx=0x7ffff6906c00, script=0x7ffff7e67160,
scopeChainArg=(JSObject &) @0x7ffff7e63070 [object Block], rval=0x0)
at /tmp/mozjs-45.0.2/js/src/vm/Interpreter.cpp:685
#10 0x00000000009dbead in ExecuteScript (cx=0x7ffff6906c00,
scope=(JSObject * const) 0x7ffff7e63070 [object Block] delegate, script=0x7ffff7e67160, rval=0x0)
at /tmp/mozjs-45.0.2/js/src/jsapi.cpp:4410
#11 0x00000000009dc25a in JS_ExecuteScript (cx=0x7ffff6906c00, scriptArg=0x7ffff7e67160)
at /tmp/mozjs-45.0.2/js/src/jsapi.cpp:4443
#12 0x00000000004323e2 in RunFile (cx=0x7ffff6906c00, filename=0x7fffffffdf09 "index.js",
file=0x7fffedd40c00, compileOnly=false) at /tmp/mozjs-45.0.2/js/src/shell/js.cpp:515
#13 0x00000000004334d2 in Process (cx=0x7ffff6906c00, filename=0x7fffffffdf09 "index.js",
forceTTY=false, kind=FileScript) at /tmp/mozjs-45.0.2/js/src/shell/js.cpp:728
#14 0x000000000044749f in ProcessArgs (cx=0x7ffff6906c00, op=0x7fffffffda20)
at /tmp/mozjs-45.0.2/js/src/shell/js.cpp:6175
#15 0x0000000000448957 in Shell (cx=0x7ffff6906c00, op=0x7fffffffda20, envp=0x7fffffffdc38)
at /tmp/mozjs-45.0.2/js/src/shell/js.cpp:6516
#16 0x0000000000449e29 in main (argc=3, argv=0x7fffffffdc18, envp=0x7fffffffdc38)
at /tmp/mozjs-45.0.2/js/src/shell/js.cpp:6877
I was also able to reproduce the crash in Firefox 45.0.1 and Firefox 45.9.0esr, however not Firefox 56.0.
Actual results:
See above, running the script resulted in a crash.
Expected results:
The script should run without any problems.
Comment 1•8 years ago
|
||
This is most likely a known bug that was fixed some time ago. If you find the bug in Bugzilla, you might be able to backport the patch. To find fixed bugs in Bugzilla you have to add RESO FIXED to the start of your search.
status-firefox59:
--- → unaffected
Priority: -- → P5
Comment 2•8 years ago
|
||
After some discussion with the team, we're updating the wiki to stop acting like the standalone SpiderMonkey tarball is an official product that we actively support. It really isn't. Some projects and companies do use it, and we take patches for it, but it is not a typical C/C++ library. We break source compatibility and change the build system often.
Reporter | ||
Comment 3•8 years ago
|
||
(In reply to Jason Orendorff [:jorendorff] from comment #2)
> After some discussion with the team, we're updating the wiki to stop acting
> like the standalone SpiderMonkey tarball is an official product that we
> actively support. It really isn't. Some projects and companies do use it,
> and we take patches for it, but it is not a typical C/C++ library. We break
> source compatibility and change the build system often.
Hmm, interesting. Thank you for clarifying whether the standalone SpiderMonkey releases are officially supported or not.
My project was currently waiting for the standalone release of 52 in order to rebase our SpiderMonkey up to a newer version, however if this is true, do you recommend we just use the SpiderMonkey in the latest Firefox esr release (or possibly even just the latest Firefox release) instead?
Comment 4•8 years ago
|
||
At the moment, we put *slightly* more effort into supporting what we've been calling "release" versions, so if you're going to be at the same version for a long time, there's an argument for picking one of those. On the other hand, if you're on the current firefox release, you'll get much, much more support. And the closer to the current release you are, the more luck you'll have getting help with things.
I really see two main paths: stick to the official unofficial release, which up to now has been associated with an esr; or use the latest released firefox version. In either case, if you want to be up to date with security fixes, you'll have to track our firefox updates, since historically we haven't been good at all about re-releasing updated standalone packages when security dot releases go out. Tracking the latest firefox release will be much better for support, but also means a steady rate of change (as opposed to sticking to esr, where you'll have large chunks of change every so often.)
I think which path to choose depends on what you're using it for. Both will result in a perfectly functional embedded JS engine. Both will fall behind on security updates if left alone.
We don't have a good way to find the latest autobuilt package. For esr, https://index.taskcluster.net/v1/task/gecko.v2.mozilla-esr52.latest.firefox.sm-package-opt/artifacts/public/build/mozjs-52.4.0.tar.bz2 gives you the latest for a particular version, but that's not going to help when we release a new one. (And those expire; that link 404s right now because we haven't built 52.4.0 for a long time.) The only way I know of to get the right one is to go to https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr52&filter-searchStr=spidermonkey-sm-package and look for a green SM(pkg) link, which will point you to a package that looks something like "artifact uploaded: mozjs-52.5.1.tar.bz2".
For the released version, that would be https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&filter-searchStr=spidermonkey-sm-package which currently points to https://queue.taskcluster.net/v1/task/e8X3tKITQTeSFhtdirD7Xg/runs/0/artifacts/public/build/mozjs-57.0.1.tar.bz2
I'll try to come up with some things to make this a little less awful.
Updated•3 years ago
|
Severity: normal → S3
Updated•1 year ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•