This might affect loads too. As per discussion with Ed the frontend should check what the permissible maximum displacement is (which the backend exports as a symbol) and then split up the store into a sti(add(base, disp), 0). This could be done in the LirWriter. We already have a bunch of helpers there that do similar things.
Ed points out that we have to make sure that constant folding doesn't generate too large displacements again after we split them.
Summary: TM: arm fails if sti/stqi have displacements > 12 bits → TM: arm fails if sti/stqi have displacements > 12 bits [nanojit]
If we're right about the consequences of this, it should be security-sensitive.
Is there a wallpaper/band-aid approach on this that can correct our issue on ARM Windows Mobile until a proper solution is offered?
Gal proposed this as a testcase for this issue, but I am not able to hit the same assertion (or any crash, for that matter), running this testcase: for (var i = 0; i < 1950; ++i) this["x" + i] = 1; for (var j = 0; j < 10; ++j) ;
Created attachment 404075 [details] [diff] [review] fixes the assert on WINCE This patch is by no means "the patch", but it fixes the assertion on WINCE, perhaps "the patch" for now is to simply ifdef WINCE this?
Errr, woops. 512, not 2048 (was playing w/ other sizes, but 512 is the only one that works).
Created attachment 404076 [details] [diff] [review] hg qref BEFORE uploading the patch next time.
Attachment #404075 - Attachment is obsolete: true
Created attachment 404376 [details] [diff] [review] patch
Attachment #404364 - Attachment is obsolete: true
Created attachment 404378 [details] [diff] [review] patch
Created attachment 404379 [details] [diff] [review] patch
Comment on attachment 404379 [details] [diff] [review] patch good enough, thanks.
Attachment #404379 - Flags: review?(graydon) → review+
Why is this bug hidden? We have never shipped an ARM product, have we?
tracking-fennec: --- → ?
OS: Mac OS X → All
Priority: -- → P1
Hardware: x86 → ARM
I dunno, I figured it might be on at least a few thousand phones, etc., but perhaps I am overly optimistic. (or pessimistic) Feel free to open it, if you like.
I recommend opening up the bug. Usually someone from the security group makes that call though so cc'ing Jesse.
Follow-up fix for ARM. http://hg.mozilla.org/tracemonkey/rev/9adc8fa19990
> I recommend opening up the bug. Are there any nightly or beta users on ARM? If there are, we should be nice to them and hold bugs private until they've had a chance to update.
yea, we have maemo users on beta and winmo users on alpha. Both also have nightly users without a working update channel.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
status1.9.2: --- → final-fixed
Does this bug affect the 1.9.1 branch, and if so would we bother to fix it there? If not we can probably unhide this bug now.
status1.9.1: --- → ?
You need to log in before you can comment on or make changes to this bug.