RESOLVED INVALID 97791
fast/profiler/apply.html fails with LLInt on 32 bit
https://bugs.webkit.org/show_bug.cgi?id=97791
Summary fast/profiler/apply.html fails with LLInt on 32 bit
Csaba Osztrogonác
Reported 2012-09-27 08:46:32 PDT
We enabled LLInt on Qt - https://trac.webkit.org/changeset/129760, but fast/profiler/apply.html started to fail on 32 bit (release/debug too) --- /home/webkitbuildbot/slaves/release32bit-NRWT/buildslave/qt-linux-32-release-NRWT/build/layout-test-results/fast/profiler/apply-expected.txt +++ /home/webkitbuildbot/slaves/release32bit-NRWT/buildslave/qt-linux-32-release-NRWT/build/layout-test-results/fast/profiler/apply-actual.txt @@ -6,7 +6,8 @@ Thread_1 (no file) (line 0) startTest apply.html (line 11) fakeObject apply.html (line 18) - fakeInteriorFunction apply.html (line 24) + apply (no file) (line 0) + fakeInteriorFunction apply.html (line 24) endTest profiler-test-JS-resources.js (line 1)
Attachments
Csaba Osztrogonác
Comment 1 2012-09-27 08:54:36 PDT
I skipped it by https://trac.webkit.org/changeset/129768, please unskip it with the proper fix.
Mark Lam
Comment 2 2012-10-02 13:33:01 PDT
I've confirmed that this issue reproduces on the 32-bit ASM llint as well but not the 64-bit ASM llint. It looks to be a regression in the 32-bit llint code.
Mark Lam
Comment 3 2012-10-02 13:34:13 PDT
(In reply to comment #2) > I've confirmed that this issue reproduces on the 32-bit ASM llint as well but not the 64-bit ASM llint. It looks to be a regression in the 32-bit llint code. To clarify, I reproduced this on a mac. This is not a Qt specific issue.
Ádám Kallai
Comment 4 2012-10-04 08:29:18 PDT
I found another test. This test fails on Qt 32 bit. (release/debug too) I'm going to skip this test on Qt. * http/tests/w3c/webperf/approved/navigation-timing/html/test_timing_xserver_redirect.html --- /ramdisk/qt-linux-32-release-webkit2/build/layout-test-results/http/tests/w3c/webperf/approved/navigation-timing/html/test_timing_xserver_redirect-expected.txt +++ /ramdisk/qt-linux-32-release-webkit2/build/layout-test-results/http/tests/w3c/webperf/approved/navigation-timing/html/test_timing_xserver_redirect-actual.txt @@ -8,6 +8,7 @@ FAIL Starting document.location.hostname is correct (127.0.0.1:8000) assert_equals: Starting document.location.hostname is correct (127.0.0.1:8000) expected "127.0.0.1:8000" but got "127.0.0.1"(stack: assert@http://127.0.0.1:8000/w3c/resources/testharness.js:1646 assert_equals@http://127.0.0.1:8000/w3c/resources/testharness.js:567 http://127.0.0.1:8000/w3c/webperf/resources/webperftestharness.js:145 +apply@[native code] step@http://127.0.0.1:8000/w3c/resources/testharness.js:876 test@http://127.0.0.1:8000/w3c/resources/testharness.js:338 wp_test@http://127.0.0.1:8000/w3c/webperf/resources/webperftestharness.js:67
Ádám Kallai
Comment 5 2012-10-04 08:48:41 PDT
I skipped it: Committed r130394: <http://trac.webkit.org/changeset/130394> Please unskip it with the proper fix.
Csaba Osztrogonác
Comment 6 2012-11-05 10:25:06 PST
The bug is still valid.
Csaba Osztrogonác
Comment 7 2012-11-21 05:08:21 PST
still valid bug ... Is there any plan to fix this LLINT bug?
Filip Pizlo
Comment 8 2012-11-21 05:27:39 PST
(In reply to comment #7) > still valid bug ... Is there any plan to fix this LLINT bug? I should hope so!
Joseph Pecoraro
Comment 9 2016-06-06 20:00:44 PDT
Legacy Profiler has been removed. This test no longer exists. Given how old this bug is, I'm going to close. It sounds like back in 2012 someone was able to reproduce on Mac, but if this was a serious LLInt issue it would have been addressed.
Note You need to log in before you can comment on or make changes to this bug.