163846 2016-10-22 07:24:01 -0700 [GTK] JSC test wasm.yaml/wasm/js-api/test_basic_api.js.default-wasm and wasm.yaml/wasm/js-api/test_Module.js.default-wasm fail with Exception: ReferenceError: Can't find variable: WebAssembly 2016-10-26 14:12:35 -0700 1 1 1 Unclassified WebKit JavaScriptCore Other PC Linux RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=163963 P2 Normal --- 1 mcatanzaro ysuzuki bugs-noreply jfbastien keith_miller mcatanzaro ossy ysuzuki oldest_to_newest 1243367 0 mcatanzaro 2016-10-22 07:24:01 -0700 It looks like this has been broken for a long time. Note that ENABLE_WEBASSEMBLY is still set to OFF for all ports in both WebKitFeatures.cmake and FeatureList.pm: wasm.yaml/wasm/js-api/test_basic_api.js.default-wasm: Exception: ReferenceError: Can't find variable: WebAssembly 30747/37492 (failed 1) ............ wasm.yaml/wasm/js-api/test_basic_api.js.default-wasm: module code@/home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/Release/bin/jsc-stress-results/.tests/wasm.yaml/wasm/js-api/test_basic_api.js:26:28 30747/37492 (failed 1) ............ wasm.yaml/wasm/js-api/test_basic_api.js.default-wasm: evaluate@[native code] 30747/37492 (failed 1) ............ wasm.yaml/wasm/js-api/test_basic_api.js.default-wasm: moduleEvaluation@[native code] 30747/37492 (failed 1) ............ wasm.yaml/wasm/js-api/test_basic_api.js.default-wasm: [native code] 30747/37492 (failed 1) ............ wasm.yaml/wasm/js-api/test_basic_api.js.default-wasm: promiseReactionJob@[native code] 30747/37492 (failed 1) ............ wasm.yaml/wasm/js-api/test_basic_api.js.default-wasm: ERROR: Unexpected exit code: 3 1244527 1 mcatanzaro 2016-10-25 16:41:59 -0700 So I am confused as to how this test is passing on Mac, if WebAssembly is currently disabled everywhere. If this was a layout test, I would just skip the test. Do we have some mechanism for dealing with this in JS tests? If not, I guess it should be temporarily removed? 1244528 2 mcatanzaro 2016-10-25 16:43:16 -0700 Oh, one more failure now: 30760/37506 ........... wasm.yaml/wasm/js-api/test_Module.js.default-wasm: Exception: ReferenceError: Can't find variable: WebAssembly 30760/37506 ........... wasm.yaml/wasm/js-api/test_Module.js.default-wasm: EmptyModule@/home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/Release/bin/jsc-stress-results/.tests/wasm.yaml/wasm/js-api/test_Module.js:7:35 30760/37506 ........... wasm.yaml/wasm/js-api/test_Module.js.default-wasm: module code@/home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/Release/bin/jsc-stress-results/.tests/wasm.yaml/wasm/js-api/test_Module.js:9:3 30760/37506 ........... wasm.yaml/wasm/js-api/test_Module.js.default-wasm: evaluate@[native code] 30760/37506 ........... wasm.yaml/wasm/js-api/test_Module.js.default-wasm: moduleEvaluation@[native code] 30760/37506 ........... wasm.yaml/wasm/js-api/test_Module.js.default-wasm: [native code] 30760/37506 ........... wasm.yaml/wasm/js-api/test_Module.js.default-wasm: promiseReactionJob@[native code] 30760/37506 ........... 30761/37506 .......... 30761/37506 .......... wasm.yaml/wasm/js-api/test_basic_api.js.default-wasm: ERROR: Unexpected exit code: 3 30761/37506 .......... 30762/37506 (failed 1) ......... 30762/37506 (failed 1) .......... wasm.yaml/wasm/js-api/test_Module.js.default-wasm: ERROR: Unexpected exit code: 3 1244541 3 jfbastien 2016-10-25 16:52:16 -0700 I'm not an expert as how tests work, but I'm guessing the problem came from here: https://bugs.webkit.org/attachment.cgi?id=291661 When I added runWebAssembly: https://trac.webkit.org/browser/trunk/Tools/Scripts/run-jsc-stress-tests#L1157 Can you confirm that this is the case? Are the conditions at the top wrong for GTK? Sorry for asking all these questions, I don't understand how this all holds together. 1244548 4 mcatanzaro 2016-10-25 16:59:14 -0700 (In reply to comment #3) > I'm not an expert as how tests work, but I'm guessing the problem came from > here: > https://bugs.webkit.org/attachment.cgi?id=291661 > > When I added runWebAssembly: > > https://trac.webkit.org/browser/trunk/Tools/Scripts/run-jsc-stress- > tests#L1157 > > Can you confirm that this is the case? Nope, I honestly don't know how to check JS test results that far back. :( I'm sure there's a way.... > Are the conditions at the top wrong for GTK? They look sane to me. > Sorry for asking all these questions, I don't understand how this all holds > together. Me either! I think we need to figure out how it is that WebAssembly works at all on the Mac port, then decide if it's ready to be turned on for other ports or not. If it's not ready yet, then we should find a way to skip the test conditional on whether or not it's enabled. Alternatively, we could modify the test to pass whenever the WebAssembly variable is not defined, and assume that we would notice if such a major feature accidentally disappeared. 1244561 5 jfbastien 2016-10-25 17:15:38 -0700 > > Are the conditions at the top wrong for GTK? > > They look sane to me. Hmm, I don't think they are: $isFTLPlatform = !($architecture == "x86" || $architecture == "arm" || $hostOS == "windows" || $hostOS == "linux" && $architecture == "arm64") We'd need a way to see if the platform built with ENABLE(WEBASSEMBLY). I'm not sure how this is done. > Me either! I think we need to figure out how it is that WebAssembly works at > all on the Mac port, then decide if it's ready to be turned on for other > ports or not. If it's not ready yet, then we should find a way to skip the > test conditional on whether or not it's enabled. It's not ready yet, and we're only concentrating on Mac bits right now so some of the code will need Linux-isms to work well on Linux. I wouldn't enable it yet, unless someone is willing to do the Linux work. > Alternatively, we could modify the test to pass whenever the WebAssembly > variable is not defined, and assume that we would notice if such a major > feature accidentally disappeared. I'd rather not since the entire point is to test that WebAssembly works. It's unlikely that we'd mess that up, but still it's not released so nobody would notice. 1244596 6 ysuzuki 2016-10-25 18:42:57 -0700 (In reply to comment #5) > > > Are the conditions at the top wrong for GTK? > > > > They look sane to me. > > Hmm, I don't think they are: > > $isFTLPlatform = !($architecture == "x86" || $architecture == "arm" || > $hostOS == "windows" || $hostOS == "linux" && $architecture == "arm64") > > We'd need a way to see if the platform built with ENABLE(WEBASSEMBLY). I'm > not sure how this is done. > > > Me either! I think we need to figure out how it is that WebAssembly works at > > all on the Mac port, then decide if it's ready to be turned on for other > > ports or not. If it's not ready yet, then we should find a way to skip the > > test conditional on whether or not it's enabled. > > It's not ready yet, and we're only concentrating on Mac bits right now so > some of the code will need Linux-isms to work well on Linux. I wouldn't > enable it yet, unless someone is willing to do the Linux work. > > > > Alternatively, we could modify the test to pass whenever the WebAssembly > > variable is not defined, and assume that we would notice if such a major > > feature accidentally disappeared. > > I'd rather not since the entire point is to test that WebAssembly works. > It's unlikely that we'd mess that up, but still it's not released so nobody > would notice. It seems that ENABLE(WEBASSEMBLY) is ON in Mac ports by default, right? I think adding the following "darwin" check in runWebAssembly is preferable. if $hostOS == "darwin" WEBASSEMBLY flag can be enabled even if it is still under the development, and actually it seems that it is enabled in Mac ports. Why we can do that safely is there is runtime flag Options::useWebAssembly(). It prevents us from exposing the implementation under the heavy development. Basically, we can enable WEBASSEMBLY flag. The reason why we would like to disable this in Linux port is we have a part only focusing on Darwin right now. So, the reasonable choice is disabling the tests based on the $hostOS. 1244600 7 292863 ysuzuki 2016-10-25 18:56:37 -0700 Created attachment 292863 Patch 1244601 8 ysuzuki 2016-10-25 18:58:44 -0700 BTW, still the problem occurs in GTK port on Darwin. But I think we have a chance to enable it on Darwin. 1244604 9 292863 jfbastien 2016-10-25 19:16:39 -0700 Comment on attachment 292863 Patch Looks good, though I think we should file a bug to remove this on Linux (and link to it from the comment). Thanks for looking into it, I wasn't sure what the best fix was :-) 1244855 10 292863 mcatanzaro 2016-10-26 11:33:57 -0700 Comment on attachment 292863 Patch OK it looks sane, thanks. We don't have any GTK tests bots running Darwin so I don't really care toooo much if it's still broken on that platform, but indeed WebAssembly would not be available there either, so testing the port would make more sense than testing the OS, right? 1244863 11 ysuzuki 2016-10-26 11:54:03 -0700 (In reply to comment #10) > Comment on attachment 292863 [details] > Patch > > OK it looks sane, thanks. > > We don't have any GTK tests bots running Darwin so I don't really care toooo > much if it's still broken on that platform, but indeed WebAssembly would not > be available there either, so testing the port would make more sense than > testing the OS, right? (In reply to comment #10) > Comment on attachment 292863 [details] > Patch > > OK it looks sane, thanks. > > We don't have any GTK tests bots running Darwin so I don't really care toooo > much if it's still broken on that platform, but indeed WebAssembly would not > be available there either, so testing the port would make more sense than > testing the OS, right? Yeah, I think theoretically we can. But, in reality, I think it constantly causes some build/runtime errors until the implementation becomes ready to be ported. Anyway, this should be a transient workaround. As JF suggested, I'll open a bug and note this in FIXME. 1244896 12 ysuzuki 2016-10-26 14:12:35 -0700 Committed r207913: <http://trac.webkit.org/changeset/207913> 292863 2016-10-25 18:56:37 -0700 2016-10-26 11:33:57 -0700 Patch bug-163846-20161026105250.patch text/plain 1545 ysuzuki U3VidmVyc2lvbiBSZXZpc2lvbjogMjA3ODU4CmRpZmYgLS1naXQgYS9Ub29scy9DaGFuZ2VMb2cg Yi9Ub29scy9DaGFuZ2VMb2cKaW5kZXggMTkzMGVjZGJiMDc5NGQ4ZDFjMWE1YjY0NjQ4MDZlOTJm MjliZGI2MC4uYTk0YzVjYmIyOWE5MGJiYjFlNWI4ZjA2ODg2ZDMyNzU4ODdmNDVkZiAxMDA2NDQK LS0tIGEvVG9vbHMvQ2hhbmdlTG9nCisrKyBiL1Rvb2xzL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE1 IEBACisyMDE2LTEwLTI1ICBZdXN1a2UgU3V6dWtpICA8dXRhdGFuZS50ZWFAZ21haWwuY29tPgor CisgICAgICAgIFtHVEtdIEpTQyB0ZXN0IHdhc20ueWFtbC93YXNtL2pzLWFwaS90ZXN0X2Jhc2lj X2FwaS5qcy5kZWZhdWx0LXdhc20gYW5kIHdhc20ueWFtbC93YXNtL2pzLWFwaS90ZXN0X01vZHVs ZS5qcy5kZWZhdWx0LXdhc20gZmFpbCB3aXRoIEV4Y2VwdGlvbjogUmVmZXJlbmNlRXJyb3I6IENh bid0IGZpbmQgdmFyaWFibGU6IFdlYkFzc2VtYmx5CisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJr aXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNjM4NDYKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JP RFkgKE9PUFMhKS4KKworICAgICAgICBXZWJBc3NlbWJseSBpcyBub3cgZGV2ZWxvcGVkIGZvciBE YXJ3aW4gcmlnaHQgbm93LgorICAgICAgICBEaXNhYmxlIFdBU00gdGVzdHMgaW4gdGhlIG90aGVy IHBsYXRmb3Jtcy4KKworICAgICAgICAqIFNjcmlwdHMvcnVuLWpzYy1zdHJlc3MtdGVzdHM6CisK IDIwMTYtMTAtMjUgIEFudG9pbmUgUXVpbnQgIDxncmFvdXRzQGFwcGxlLmNvbT4KIAogICAgICAg ICBbTW9kZXJuIE1lZGlhIENvbnRyb2xzXSBNZWRpYSBDb250cm9sbGVyOiBza2lwIGJhY2sgc3Vw cG9ydApkaWZmIC0tZ2l0IGEvVG9vbHMvU2NyaXB0cy9ydW4tanNjLXN0cmVzcy10ZXN0cyBiL1Rv b2xzL1NjcmlwdHMvcnVuLWpzYy1zdHJlc3MtdGVzdHMKaW5kZXggMDJhMDkwZDM1YjZkZDQ0NTY1 NDQ3ZmRjMmRhMTVhNTJhZDM0ZDJmYy4uMWZhZmU5YzgzNjI2NzVmZTk2NTgzYWQ2NmYzNWM5MmYz ZjEyZDE4ZSAxMDA3NTUKLS0tIGEvVG9vbHMvU2NyaXB0cy9ydW4tanNjLXN0cmVzcy10ZXN0cwor KysgYi9Ub29scy9TY3JpcHRzL3J1bi1qc2Mtc3RyZXNzLXRlc3RzCkBAIC0xMTU3LDYgKzExNTcs NyBAQCBlbmQKIGRlZiBydW5XZWJBc3NlbWJseQogICAgIHJldHVybiBpZiAhJGppdFRlc3RzCiAg ICAgcmV0dXJuIGlmICEkaXNGVExQbGF0Zm9ybQorICAgIHJldHVybiBpZiAkaG9zdE9TICE9ICJk YXJ3aW4iICMgVGhlIGN1cnJlbnQgV2ViQXNzZW1ibHkgaW1wbGVtZW50YXRpb24gaW5jbHVkZXMg RGFyd2luIHNwZWNpZmljIHRoaW5ncy4KICAgICBtb2R1bGVzID0gRGlyW1dBU01URVNUU19QQVRI ICsgIiouanMiXS5tYXAgeyB8ZnwgRmlsZS5iYXNlbmFtZShmKSB9CiAgICAgcHJlcGFyZUV4dHJh QWJzb2x1dGVGaWxlcyhXQVNNVEVTVFNfUEFUSCwgWyJ3YXNtLmpzb24iXSkKICAgICBwcmVwYXJl RXh0cmFSZWxhdGl2ZUZpbGVzKG1vZHVsZXMubWFwIHsgfGZ8ICIuLi8iICsgZiB9LCAkY29sbGVj dGlvbikK