Closed Bug 518227 Opened 11 years ago Closed 10 years ago

TM: spilled quads are passed incorrectly when calling a function [ARM, nanojit]

Categories

(Core :: JavaScript Engine, defect, P1, blocker)

ARM
Windows Mobile 6 Professional
defect

Tracking

()

VERIFIED FIXED
Tracking Status
status1.9.2 --- beta1-fixed
fennec 1.0a4-wm+ ---

People

(Reporter: aakashd, Assigned: gal)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(6 files)

Build Id:

Mozilla/5.0 (Windows; U; WindowsCE 5.2; en-US; rv:1.9.2a2pre) Gecko/20090922 Fennec/1.0a3

and

Mozilla/5.0 (Windows; U; WindowsCE 5.2; en-US; rv:1.9.3a1pre) Gecko/20090922
Fennec/1.0a3

dougt mentioned he's seeing the same issue on today's nightly branch build for his ht touch pro.

Steps to Reproduce:
1. Open any nightly build on the htc touch pro from 9/22
2. Open any webpage

Actual Results:
The content pane brings up a whole bunch of seriously weird things such as the search bar, parts of the page, static, etc.

Expected Results:
The webpage with content in a proper layout should come up.
tracking-fennec: --- → ?
tracking-fennec: ? → 1.0a4-wm+
Attached image Going to mail.com
I see this on the touch pro, but not the omnia II
9/17, 9/19 and 9/21 nightlies all crash on start up so unfortunately the regression window is 9/16 - 9/22.

I've tried backing out 0787e89e3e0d, aba4d636382d and 7799cfb99362 (which ended up being backed out for real) with no luck.
if I disable chrome and content jit (by editing my prefs.js) and then reboot my device this problem goes away.  If I then re-enable the jit and reboot it comes back.  The fact that a reboot is required for the prefs.js edit to take effect is a little odd (is this a by-product of faststart?), but it seems pretty solidly related to the jit being enabled.
Assignee: nobody → general
Component: Windows Mobile → JavaScript Engine
OS: Windows Mobile 6 Standard → Windows Mobile 6 Professional
Product: Fennec → Core
QA Contact: mobile-windows → general
We did have some problems around double handling.  Are there any test cases that we can be running to test and verify the jit?
Assignee: general → crowder
We need better testing ... this is the 4th time and counting we run into this. Doug, what do you mean with "problems around double handling"? Any patch you suspect?
It's my sincere hope that this is caused by bug 519805; I'm testing that theory now.
This is now happening on both trunk AND 1.9.2 with today's nightly build:

Mozilla/5.0 (Windows; U; WindowsCE 5.2; en-US; rv:1.9.2b1pre) Gecko/20091005 Fennec/1.0a3


for any winmo device. Originally, I only saw it on the htc touch pro.
Priority: -- → P1
Summary: content on winmo nightly builds on 9/22 are wonky for htc touch pro → content on winmo nightly builds on 9/22 are wonky
Okay, I've been trying to bisect for this all weekend and a couple of days last week w/ no luck.  The problem is that bisecting in tracemonkey yields far more totally unbootable (ie., the browser starts and then simply shuts down) builds than otherwise.  I'll bug the js guys today as I debug.
Aakash, do you know when this new behavior started on trunk?
Regression range on trunk is in comment #5
Attached image MobileMe screenshot
Attached image More MobileMe screens
This looks more like corruption than the previous.
We are using a preindex store with 0 offset. I think thats an invalid instructions. For all other stack stores we just use stores and maintain an internal offset (stkd), so the 2nd store actually clobbers sp imo. Attaching a patch and confirming with crowder.

006056550c   ldr ip, [fp, #-112]    r2(fsub3) r3(callh24) r4(ld305) r5(state) r6(ld212) r7(sp) r8(ld207) r9(ld206) r10(ld205)
  0060565510   str ip, [sp, #0]!      r2(fsub3) r3(callh24) r4(ld305) r5(state) r6(ld212) r7(sp) r8(ld207) r9(ld206) r10(ld205)
  0060565514   ldr ip, [fp, #-108]    r2(fsub3) r3(callh24) r4(ld305) r5(state) r6(ld212) r7(sp) r8(ld207) r9(ld206) r10(ld205)
  0060565518   str ip, [sp, #4]!      r2(fsub3) r3(callh24) r4(ld305) r5(state) r6(ld212) r7(sp) r8(ld207) r9(ld206) r10(ld205)
Summary: content on winmo nightly builds on 9/22 are wonky → spilled quads are passed incorrectly when calling a function [nanojit]
Summary: spilled quads are passed incorrectly when calling a function [nanojit] → TM: spilled quads are passed incorrectly when calling a function [ARM, nanojit]
Attached patch patchSplinter Review
Assignee: crowder → gal
crowder confirmed that this fixes the issues
Comment on attachment 404867 [details] [diff] [review]
patch

Begone, non-virtual stack!
Attachment #404867 - Flags: review+
Flags: blocking1.9.2+
This can also hit VFP and EABI, so all arm targets really. Should block 1.9.2.
http://hg.mozilla.org/tracemonkey/rev/3b4353d2832a
Whiteboard: fixed-in-tracemonkey
This is very obviously wrong and 1.9.2 and m-c are not useable on winmo without it, so I suggest immediate landing on m-c and 1.9.2
I'm still not sure I know what landing caused this...?
The regressor must be an arm merge that introduced the virtual call stack.
Comment on attachment 404867 [details] [diff] [review]
patch

This definitely fixes the problem; tested in both opt and debug builds.
verified FIXED on build:

Mozilla/5.0 (Windows; U; WindowsCE 5.2; en-US; rv:1.9.3a1pre) Gecko/20091008 Fennec/1.0a3
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.