GNOME Bugzilla – Bug 616193
Test suite fails when run with JIT enabled
Last modified: 2017-07-17 23:57:39 UTC
I'm trying to build gjs against xulrunner 1.9.2 on Ubuntu, and seeing a test suite failure which only seems to affect i386. The log from the failure is here: JS CTX: Ignoring second exception: 'Second different exception foo' JS CTX: Enabling JIT JS CTX: Changing JavaScript version to 1.8 from default JS CTX: Creating load context for runtime 0x850ce68 JS CTX: Enabling JIT JS CTX: Changing JavaScript version to 1.8 from default JS IMPORT: Initialized class GjsFileImporter prototype 0x8531720 JS IMPORT: Defining parent 0x85313a0 of 0x8531740 'imports' is mod 0 JS IMPORT: Defined importer 'imports' 0x8531740 in 0x85313a0 JS CTX: Destroying JS context JS CTX: Clearing call context JS CTX: Call context cleared JS CTX: Clearing load context JS CTX: Destroying JS context (load context) JS CTX: Load context cleared JS CTX: Destroying JS runtime JS CTX: Destroying any remaining dataset items on runtime JS CTX: Enabling JIT JS CTX: Changing JavaScript version to 1.8 from default JS CTX: Creating load context for runtime 0x8096080 JS CTX: Enabling JIT JS CTX: Changing JavaScript version to 1.8 from default JS IMPORT: Initialized class GjsFileImporter prototype 0x80bf720 JS IMPORT: Defining parent 0x80bf3a0 of 0x80bf740 'imports' is mod 0 JS IMPORT: Defined importer 'imports' 0x80bf740 in 0x80bf3a0 JS CTX: Script evaluation succeeded JS IMPORT: JS import 'signals' not found in /tmp/buildd/gjs-0.5/_build/test/modules JS IMPORT: Importing '/tmp/buildd/gjs-0.5/_build/./modules/signals.js' JS IMPORT: Defining parent 0x80bf740 of 0x80bf8a0 'signals' is mod 1 JS IMPORT: successfully imported module 'signals' JS LOG: running test testSimple JS LOG: Received signal 'bar' JS LOG: running test testDisconnectDuringEmit JS LOG: Received signal 'bar', disconnecting others JS LOG: running test testMultipleSignals JS LOG: Received signal 'bar' JS LOG: Received signal 'bar' (handler 2) JS LOG: Received signal 'bonk' JS LOG: Received signal 'bar' JS LOG: Received signal 'bar' (handler 2) JS LOG: running test testExceptionInCallback JS LOG: Received signal 'bar' (throwing exception) JS ERROR: !!! Exception in callback for signal: bar JS ERROR: !!! message = 'Exception we are throwing on purpose' JS ERROR: !!! lineNumber = '119' JS ERROR: !!! fileName = '/tmp/buildd/gjs-0.5/_build/test/js/testSignals.js' JS ERROR: !!! stack = 'Error("Exception we are throwing on purpose")@:0 ([object Object])@/tmp/buildd/gjs-0.5/_build/test/js/testSignals.js:119 _emit("bar")@/tmp/buildd/gjs-0.5/_build/./modules/signals.js:124 testExceptionInCallback()@/tmp/buildd/gjs-0.5/_build/test/js/testSignals.js:128 gjstestRun()@/tmp/buildd/gjs-0.5/_build/modules/jsUnit.js:471 @/tmp/buildd/gjs-0.5/_build/test/js/testSignals.js:138 ' JS LOG: Received signal 'bar' (handler 2) JS LOG: Received signal 'bar' (throwing exception) JS ERROR: !!! Exception in callback for signal: bar JS ERROR: !!! message = 'Exception we are throwing on purpose' JS ERROR: !!! lineNumber = '119' JS ERROR: !!! fileName = '/tmp/buildd/gjs-0.5/_build/test/js/testSignals.js' JS ERROR: !!! stack = 'Error("Exception we are throwing on purpose")@:0 ([object Object])@/tmp/buildd/gjs-0.5/_build/test/js/testSignals.js:119 _emit("bar")@/tmp/buildd/gjs-0.5/_build/./modules/signals.js:124 testExceptionInCallback()@/tmp/buildd/gjs-0.5/_build/test/js/testSignals.js:133 gjstestRun()@/tmp/buildd/gjs-0.5/_build/modules/jsUnit.js:471 @/tmp/buildd/gjs-0.5/_build/test/js/testSignals.js:138 ' JS LOG: Received signal 'bar' (handler 2) JS CTX: Script evaluation succeeded JS CTX: Script returned integer code 0 JS MEMORY: Memory report: before destroying context JS MEMORY: 1 objects currently alive JS MEMORY: boxed = 0 JS MEMORY: closure = 0 JS MEMORY: database = 0 JS MEMORY: dbus_exports = 0 JS MEMORY: function = 0 JS MEMORY: importer = 1 JS MEMORY: ns = 0 JS MEMORY: object = 0 JS MEMORY: param = 0 JS MEMORY: repo = 0 JS MEMORY: resultset = 0 JS MEMORY: weakhash = 0 JS CTX: Destroying JS context JS CTX: Clearing call context JS CTX: Call context cleared JS CTX: Clearing load context JS CTX: Destroying JS context (load context) JS CTX: Load context cleared JS CTX: Destroying JS runtime JS CTX: Destroying any remaining dataset items on runtime JS MEMORY: Memory report: after destroying context JS MEMORY: 1 objects currently alive JS MEMORY: boxed = 0 JS MEMORY: closure = 0 JS MEMORY: database = 0 JS MEMORY: dbus_exports = 0 JS MEMORY: function = 0 JS MEMORY: importer = 1 JS MEMORY: ns = 0 JS MEMORY: object = 0 JS MEMORY: param = 0 JS MEMORY: repo = 0 JS MEMORY: resultset = 0 JS MEMORY: weakhash = 0 The failure doesn't occur with GJS_DISABLE_JIT. I ran the test through GDB, and I do see a call to js_GC with GC_LAST_CONTEXT after calling JS_DestroyContext on the last context. However, I never see a call to importer_finalize or JS_FinalizeStub (which I expected to see when finalizing the global object). I see calls to importer_finalize and JS_FinalizeStub on amd64, where it seems to be working ok. I'll attach a minimal reproducer which I can use to trigger the issue on i386, which is basically just a very stripped down gjstestRun. Running the script with gjs-console triggers the issue
Created attachment 159087 [details] Reproducer script
As discussed on IRC, here's a patch I've applied in Ubuntu which disables the memory report for now, and just print a debug message instead <walters> i think for now all i can tell you is to patch out the memory report test with a debug note, i can't context switch myself right now to debugging it <chrisccoulson> walters - ok, i can do that for now then <walters> in practice this doesn't really matter since none of our apps depend on being able to destroy a context <walters> it all gets cleaned up when the process exits anyways <chrisccoulson> oh, ok, so it's not too much of an issue then <walters> if you were doing a browser with gjs, it might matter, but not right now no <walters> actually can you file a bug with that patch if you do make it?
Created attachment 159088 [details] [review] 01_disable_memcheck.patch
Attachment 170911 [details], attached to bug 630413 and committed as 58ecae8 disabled the JIT during test runs as a workaround for this.
Review of attachment 159088 [details] [review]: This is still a problem, but I'm rejecting this patch so it doesn't show up in the review queue, because this is definitely not the way to solve it. My plan would be to try re-enabling the JIT during test runs once we're updated to the latest SpiderMonkey version, and see if the JIT bug is still present. If it is, then at least we can give Mozilla an up-to-date bug report. I'll retitle the issue accordingly.
Whatever long-standing JIT bug was causing this, has been fixed in SpiderMonkey 52.
Pushed a commit to master re-enabling JIT on tests.