175100 2017-08-02 16:58:23 -0700 [Linux] JSTests/wasm/stress/oom.js should not run on Linux 2017-08-03 10:41:35 -0700 1 1 1 Unclassified WebKit Tools / Tests WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=175140 InRadar P2 Normal --- 1 clopez clopez aperez bugs-noreply fpizlo gustavo jfbastien lforschler mark.lam ossy saam webkit-bug-importer ysuzuki zan oldest_to_newest 1334493 0 clopez 2017-08-02 16:58:23 -0700 The JSC test JSTests/wasm/stress/oom.js seems to be specifically designed to try to use all the available memory until an out of memory exception happens. Trying to do something like that on Linux is not fine, as Linux handles very badly out of memory situations. In the best case the system will freeze during several seconds and in the worst case it may be several minutes until it starts responding back. We should try to avoid running tests like this on Linux. 1334502 1 317035 clopez 2017-08-02 17:06:22 -0700 Created attachment 317035 Patch 1334505 2 317035 mark.lam 2017-08-02 17:13:34 -0700 Comment on attachment 317035 Patch r=me. Please add your rationale for why this change is needed in the ChangeLog. Thanks. 1334520 3 jfbastien 2017-08-02 17:34:20 -0700 I don’t think this is the right fix. Can you instead run under ulimit ? 1334523 4 317035 fpizlo 2017-08-02 17:35:57 -0700 Comment on attachment 317035 Patch r=me too. I know that you elaborated in the bugzilla comment, but it would be even nicer if the ChangeLog also contained the text about why this test doesn't make sense on Linux. 1334524 5 fpizlo 2017-08-02 17:37:19 -0700 (In reply to JF Bastien from comment #3) > I don’t think this is the right fix. Can you instead run under ulimit ? I think it's more pragmatic to just do this fix. We're always open to ports skipping tests without much fuss. In particular, I would have even been OK with Carlos landing this change without review, since test gardening technically does not need review. 1334564 6 clopez 2017-08-02 18:36:08 -0700 (In reply to JF Bastien from comment #3) > I don’t think this is the right fix. Can you instead run under ulimit ? ulimit is pretty broken on Linux, as limiting by rss (ulimit -m) doesn't work at all on Linux (since kernels 2.4.x) and limiting by vsize (ulimit -v ) requires some hard-to-get-right ad-hoc knowledge about how much virtual size is acceptable for a process to allocate. For example, this test is allocating ~15GB of RSS and ~57GB of VSZ before giving the out of memory error on a Linux machine with 16GB of RAM. So, how should I know that I should set an ulimit on 57GB other than by try and error? Playing with limiting the vsize seems a bit fragile to me. The only thing that I know works ok on Linux for limiting memory usage are cgroups. But cgroups are meant to limit the memory usage of a group of process (its usually used with containers). They are not really meant to limit the memory usage of a single process like we would like to do in this case. There is also the issue that this problem will not only trigger on the bots, but also on the developers machines. Any WebKit Linux developer trying to run this test will likely run into desktop freezes. I'm seizing this to comment also about a related issue at https://bugs.webkit.org/show_bug.cgi?id=171630#c11 where I observed that WebKit/JSC is pretty unique in the sense that we allow a script to use all possible RAM of the system. Other JS engines seem to limit this value to some sane amount (like 4 GBs). I see how on MacOS allow this is not a problem as the Mac kernel seems to handle fine this situations, but on Linux we run into problems when this happens. 1334566 7 clopez 2017-08-02 18:42:23 -0700 Committed r220173: <http://trac.webkit.org/changeset/220173> 1334567 8 webkit-bug-importer 2017-08-02 18:43:30 -0700 <rdar://problem/33691382> 1334583 9 jfbastien 2017-08-02 19:08:25 -0700 (In reply to Carlos Alberto Lopez Perez from comment #6) > (In reply to JF Bastien from comment #3) > > I don’t think this is the right fix. Can you instead run under ulimit ? > > ulimit is pretty broken on Linux, as limiting by rss (ulimit -m) doesn't > work at all on Linux (since kernels 2.4.x) and limiting by vsize (ulimit -v > ) requires some hard-to-get-right ad-hoc knowledge about how much virtual > size is acceptable for a process to allocate. > > For example, this test is allocating ~15GB of RSS and ~57GB of VSZ before > giving the out of memory error on a Linux machine with 16GB of RAM. So, how > should I know that I should set an ulimit on 57GB other than by try and > error? Playing with limiting the vsize seems a bit fragile to me. The test just tries to run out. Doesn’t matter at how much memory. > The only thing that I know works ok on Linux for limiting memory usage are > cgroups. But cgroups are meant to limit the memory usage of a group of > process (its usually used with containers). They are not really meant to > limit the memory usage of a single process like we would like to do in this > case. > > There is also the issue that this problem will not only trigger on the bots, > but also on the developers machines. Any WebKit Linux developer trying to > run this test will likely run into desktop freezes. > > > I'm seizing this to comment also about a related issue at > https://bugs.webkit.org/show_bug.cgi?id=171630#c11 where I observed that > WebKit/JSC is pretty unique in the sense that we allow a script to use all > possible RAM of the system. Other JS engines seem to limit this value to > some sane amount (like 4 GBs). I see how on MacOS allow this is not a > problem as the Mac kernel seems to handle fine this situations, but on Linux > we run into problems when this happens. 317035 2017-08-02 17:06:22 -0700 2017-08-02 17:13:34 -0700 Patch bug-175100-20170803020621.patch text/plain 1050 clopez U3VidmVyc2lvbiBSZXZpc2lvbjogMjIwMTYwCmRpZmYgLS1naXQgYS9KU1Rlc3RzL0NoYW5nZUxv ZyBiL0pTVGVzdHMvQ2hhbmdlTG9nCmluZGV4IDk3ZThjNTFjMTVmYmUyNjRkOTMzZDZhZDliYTkz ODgyNDM5NWVhY2UuLjYyMmE3MWUyNzlkNGUyOGQ3NGU4YmU2NzJlMGEzZjQyODZiMmYxYTAgMTAw NjQ0Ci0tLSBhL0pTVGVzdHMvQ2hhbmdlTG9nCisrKyBiL0pTVGVzdHMvQ2hhbmdlTG9nCkBAIC0x LDMgKzEsMTIgQEAKKzIwMTctMDgtMDIgIENhcmxvcyBBbGJlcnRvIExvcGV6IFBlcmV6ICA8Y2xv cGV6QGlnYWxpYS5jb20+CisKKyAgICAgICAgW0xpbnV4XSBKU1Rlc3RzL3dhc20vc3RyZXNzL29v bS5qcyBzaG91bGQgbm90IHJ1biBvbiBMaW51eAorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0 Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTc1MTAwCisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZ IChPT1BTISkuCisKKyAgICAgICAgKiB3YXNtL3N0cmVzcy9vb20uanM6CisKIDIwMTctMDgtMDEg IE9sZWtzYW5kciBTa2FjaGtvdiAgPGdza2FjaGtvdkBnbWFpbC5jb20+CiAKICAgICAgICAgW0pT Q10gUmVtb3ZlIHVubmVjZXNzYXJ5IHByaW50IGZyb20gc3RyZXNzXHByb21pc2UtZmluYWxseS5q cyB0ZXN0CmRpZmYgLS1naXQgYS9KU1Rlc3RzL3dhc20vc3RyZXNzL29vbS5qcyBiL0pTVGVzdHMv d2FzbS9zdHJlc3Mvb29tLmpzCmluZGV4IDA3NmVhNzYwMzM5ZDc0MzM3ZDJmYzIyMDRlN2M4OTQ4 Y2FhZGQ1MmQuLjZjNjc1YWJhMjYyYzk2ZjMxMmNjZWIwZDUyNTQwZjI0MmRkZDJlZDkgMTAwNjQ0 Ci0tLSBhL0pTVGVzdHMvd2FzbS9zdHJlc3Mvb29tLmpzCisrKyBiL0pTVGVzdHMvd2FzbS9zdHJl c3Mvb29tLmpzCkBAIC0xLDUgKzEsNSBAQAogLy8gV2UgZG9uJ3QgbmVlZCBOIHZlcnNpb25zIG9m IHRoaXMgc2ltdWx0YW5lb3VzbHkgZmlsbGluZyB1cCBSQU0uCi0vL0AgcnVuRGVmYXVsdAorLy9A IGlmICRob3N0T1MgPT0gImxpbnV4IiB0aGVuIHNraXAgZWxzZSBydW5EZWZhdWx0IGVuZAogCiBj b25zdCB2ZXJib3NlID0gZmFsc2U7CiAK