fast/profiler/apply.html fails with LLInt on 32 bit

• Component: JavaScriptCore
• Status: RESOLVED INVALID

[Csaba Osztrogonác]

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)

[Csaba Osztrogonác]

I skipped it by https://trac.webkit.org/changeset/129768, 
please unskip it with the proper fix.

[Mark Lam]

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]

(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]

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]

I skipped it: Committed r130394: <http://trac.webkit.org/changeset/130394>
Please unskip it with the proper fix.

[Csaba Osztrogonác]

The bug is still valid.

[Csaba Osztrogonác]

still valid bug ... Is there any plan to fix this LLINT bug?

[Filip Pizlo]

(In reply to comment #7)
> still valid bug ... Is there any plan to fix this LLINT bug?

I should hope so!

[Joseph Pecoraro]

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.