68990 2011-09-28 03:16:21 -0700 [Qt]REGRESSION(r95912): It made sputnik tests flakey 2022-02-27 23:23:24 -0800 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) All All RESOLVED FIXED Qt, QtTriaged P1 Critical --- 69102 68764 68860 1 ossy zherczeg ggaren loki oliver ossy zherczeg oldest_to_newest 474634 0 ossy 2011-09-28 03:16:21 -0700 r95912, r95914(buildfix), r95917(buildfix) and r96068(regression fix) made sputnik tests flakey on Qt platform. I think it isn't a QtWebKit bug, but a hidden JSC bug revealed by QtWebKit bots. 474636 1 ossy 2011-09-28 03:23:27 -0700 r96068 fixed zillion crash, but there are timeout sputnik tests: On Qt ARM bot: http://build.webkit.sed.hu/results/ARMv5%20Linux%20Qt%20Release%20%28Test%29/r96068%20%283791%29/results.html On Qt 4.8 bot: http://build.webkit.sed.hu/results/x86-32%20Linux%20Qt-4.8.x%20Release/r96068%20%2824137%29/results.html On Qt 32-bit debug bot: http://build.webkit.sed.hu/results/x86-32%20Linux%20Qt%20Debug/r96068%20%2818568%29/results.html 474637 2 ossy 2011-09-28 03:29:30 -0700 You can reproduce timeouts with Qt 4.7.4 in release mode 32-bit (Same as our official bot on build.webkit.org) with ORWT if you run all tests. (Unfortunately NRWT runs tests in different order and the bug doesn't occur with it on the official bot.) I tried revert r95912, r95914, r95917 and r96068 locally and then all tests pass for me. 474645 3 ossy 2011-09-28 03:38:27 -0700 One more thing: This bug only appears on 32 bit x86 platfom and on ARM. 474668 4 ossy 2011-09-28 04:56:10 -0700 I managed to reproduce it in a small example: $ Tools/Scripts/old-run-webkit-tests LayoutTests/sputnik/Conformance/15_Native_Objects/15.1_The_Global_Object/15.1.3/15.1.3.1_decodeURI --exit-after-n-failures 1 --verbose running sputnik/Conformance/15_Native_Objects/15.1_The_Global_Object/15.1.3/15.1.3.1_decodeURI/S15.1.3.1_A1.1_T1.html -> succeeded running sputnik/Conformance/15_Native_Objects/15.1_The_Global_Object/15.1.3/15.1.3.1_decodeURI/S15.1.3.1_A1.2_T1.html -> succeeded running sputnik/Conformance/15_Native_Objects/15.1_The_Global_Object/15.1.3/15.1.3.1_decodeURI/S15.1.3.1_A1.2_T2.html -> succeeded running sputnik/Conformance/15_Native_Objects/15.1_The_Global_Object/15.1.3/15.1.3.1_decodeURI/S15.1.3.1_A1.3_T1.html -> timed out 475341 5 ossy 2011-09-29 03:02:28 -0700 Any GC expert volunteer for this bug? :) 475556 6 ggaren 2011-09-29 11:48:04 -0700 Is there a way to reproduce this on a non-Qt system? 475560 7 ossy 2011-09-29 11:50:34 -0700 (In reply to comment #6) > Is there a way to reproduce this on a non-Qt system? I don't know. But Zoltan started to fix it, he confirmed that it is a GC related bug. I think he will provide the fix tomorrow. 475562 8 oliver 2011-09-29 11:52:35 -0700 (In reply to comment #7) > (In reply to comment #6) > > Is there a way to reproduce this on a non-Qt system? > > I don't know. But Zoltan started to fix it, he confirmed that it is a GC related bug. I think he will provide the fix tomorrow. We might be able to fix it if we had any information about what is going wrong -- currently we can't repro, but zoltan has found the bug and hasn't commented on what that bug is so we can't help in any way :-/ 475702 9 ossy 2011-09-29 15:00:33 -0700 It seems http://trac.webkit.org/changeset/96354 fixed the bug. But let's wait for Zoltan's confirmation. 475951 10 zherczeg 2011-09-30 00:08:08 -0700 > We might be able to fix it if we had any information about what is going wrong -- currently we can't repro, but zoltan has found the bug and hasn't commented on what that bug is so we can't help in any way :-/ I will check the fix Ossy mentioned. Probably I still need to debug it to see that the fix hides the issue or really fix it. But it is a good lead at least. ClassInfo.h:66: for (const ClassInfo* ci = this; ci; ci = ci->parentClass) in this case ci == ci->parentClass, so it is an infinite loop. This happens after the calling of GC. The 'this' pointer contains JSDOMWindow, namely the JSDOMWindow of S15.1.3.1_A1.2_T1.html. The GC call and infinite loop happens during the run of S15.1.3.1_A1.2_T2.html. And the mentioned parentClass is the 3rd parent. p structure()->classInfo()->parentClass->parentClass == 0xf12d3fb0 p structure()->classInfo()->parentClass->parentClass->parentClass == 0xf12d3fb0 and this repeats forever. 476046 11 109288 zherczeg 2011-09-30 05:51:24 -0700 Created attachment 109288 minor change 476048 12 zherczeg 2011-09-30 05:57:35 -0700 I did the debugging. The Structure was freed, but still have references from a "should be freed" object (unused JSDOMWindow). The cell is allocated again and the new memory data cause the infinite loop (it could be a crash of course). After the signed chars changed to int both of them are correctly collected. 476050 13 109288 ossy 2011-09-30 05:59:50 -0700 Comment on attachment 109288 minor change View in context: https://bugs.webkit.org/attachment.cgi?id=109288&action=review > Source/JavaScriptCore/ChangeLog:8 > + Changint signed char to int in r96354 solved the typo: Changint -> Changing 476239 14 109288 ggaren 2011-09-30 12:16:55 -0700 Comment on attachment 109288 minor change r=me with typo fix. 476831 15 zherczeg 2011-10-03 00:34:44 -0700 Landed in http://trac.webkit.org/changeset/96483 109288 2011-09-30 05:51:24 -0700 2022-02-27 23:23:24 -0800 minor change 0001-minor-fix.patch text/plain 1771 zherczeg RnJvbSA5MjBjY2Y4YTg4MTc3NDAxOGUyOWE5YzNiMmY4OGEyMmFmNjZlOWE2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBab2x0YW4gSGVyY3plZyA8emhlcmN6ZWdAd2Via2l0Lm9yZz4K RGF0ZTogRnJpLCAzMCBTZXAgMjAxMSAwNTo0Mzo0NiAtMDcwMApTdWJqZWN0OiBbUEFUQ0hdIG1p bm9yLWZpeAoKLS0tCiBTb3VyY2UvSmF2YVNjcmlwdENvcmUvQ2hhbmdlTG9nICAgICAgICAgICB8 ICAgMTQgKysrKysrKysrKysrKysKIFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9ydW50aW1lL1N0cnVj dHVyZS5oIHwgICAgMiArLQogMiBmaWxlcyBjaGFuZ2VkLCAxNSBpbnNlcnRpb25zKCspLCAxIGRl bGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cg Yi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvQ2hhbmdlTG9nCmluZGV4IGI5Mjc5OTcuLjNlZGY4OTQg MTAwNjQ0Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKKysrIGIvU291cmNl L0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE3IEBACisyMDExLTA5LTMwICBa b2x0YW4gSGVyY3plZyAgPHpoZXJjemVnQHdlYmtpdC5vcmc+CisKKyAgICAgICAgW1F0XVJFR1JF U1NJT04ocjk1OTEyKTogSXQgbWFkZSBzcHV0bmlrIHRlc3RzIGZsYWtleQorICAgICAgICBodHRw czovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9Njg5OTAKKworICAgICAgICBSZXZp ZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBDaGFuZ2ludCBzaWduZWQgY2hhciB0 byBpbnQgaW4gcjk2MzU0IHNvbHZlZCB0aGUKKyAgICAgICAgcHJvYmxlbS4gSG93ZXZlciB0cmFu c2l0aW9uQ291bnQgc3RpbGwgcmV0dXJucworICAgICAgICB3aXRoIGEgc2lnbmVkIGNoYXIgYW5k IHNob3VsZCBiZSBjaGFuZ2VkIHRvIGludC4KKworICAgICAgICAqIHJ1bnRpbWUvU3RydWN0dXJl Lmg6CisgICAgICAgIChKU0M6OlN0cnVjdHVyZTo6dHJhbnNpdGlvbkNvdW50KToKKwogMjAxMS0w OS0yOSAgWXVxaWFuZyBYaWFuICA8eXVxaWFuZy54aWFuQGludGVsLmNvbT4KIAogICAgICAgICBB ZGQgb3BfY2FsbC9vcF9jb25zdHJ1Y3RvciBzdXBwb3J0IHRvIEpTVkFMVUUzMl82NCBERkcgSklU CmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvcnVudGltZS9TdHJ1Y3R1cmUuaCBi L1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9ydW50aW1lL1N0cnVjdHVyZS5oCmluZGV4IGU4MzIzNDYu LmNkMTkxZGMgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9ydW50aW1lL1N0cnVj dHVyZS5oCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9ydW50aW1lL1N0cnVjdHVyZS5oCkBA IC0yMjksNyArMjI5LDcgQEAgbmFtZXNwYWNlIEpTQyB7CiAgICAgICAgICAgICAgICAgbWF0ZXJp YWxpemVQcm9wZXJ0eU1hcChnbG9iYWxEYXRhKTsKICAgICAgICAgfQogCi0gICAgICAgIHNpZ25l ZCBjaGFyIHRyYW5zaXRpb25Db3VudCgpIGNvbnN0CisgICAgICAgIGludCB0cmFuc2l0aW9uQ291 bnQoKSBjb25zdAogICAgICAgICB7CiAgICAgICAgICAgICAvLyBTaW5jZSB0aGUgbnVtYmVyIG9m IHRyYW5zaXRpb25zIGlzIGFsd2F5cyB0aGUgc2FtZSBhcyBtX29mZnNldCwgd2Uga2VlcCB0aGUg c2l6ZSBvZiBTdHJ1Y3R1cmUgZG93biBieSBub3Qgc3RvcmluZyBib3RoLgogICAgICAgICAgICAg cmV0dXJuIG1fb2Zmc2V0ID09IG5vT2Zmc2V0ID8gMCA6IG1fb2Zmc2V0ICsgMTsKLS0gCjEuNy4y LjUKCg==