Bug 142792 - Objects with numeric properties intermittently get a phantom 'length' property
Summary: Objects with numeric properties intermittently get a phantom 'length' property
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: iPhone / iPad iOS 8.1
: P2 Normal
Assignee: Michael Saboff
URL:
Keywords: InRadar
: 142575 (view as bug list)
Depends on:
Blocks: 108645
  Show dependency treegraph
 
Reported: 2015-03-17 14:53 PDT by osolo
Modified: 2015-04-08 07:15 PDT (History)
12 users (show)

See Also:


Attachments
Converted supplied test into a regression test (2.53 KB, patch)
2015-03-26 16:16 PDT, Michael Saboff
no flags Details | Formatted Diff | Diff
Patch (5.15 KB, patch)
2015-03-27 07:06 PDT, Michael Saboff
ossy: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description osolo 2015-03-17 14:53:56 PDT
There is a timing bug in iOS8 that causes mobile Safari to incorrectly report a 'length' on objects that don't have one.

To the best of my knowledge, this happens on iOS8+, possibly only on 64-bit systems. The bug is triggered for objects that have only numeric properties. For example:

  foo = { 1: 'a', 2: 'b', 3: 'c' } 

In this case, if you query foo.length then mobile Safari will sometimes return 4 (the highest property + 1).

This causes strange failures in functions like jQuery's $.each() or Underscore's _.each() since the appearance of the '.length' property makes them believe the object is an array.

When the bug manifests itself, the following be true:
  a = foo.length;
  b = typeof a;
  c = foo.hasOwnProperty('length')
-->
  a == 4         // should have been undefined
  b == 'number'  // should have been 'undefined'
  c == false     // correct

Both jQuery and Underscore to use the 'typeof' test on the length property, and I have advised them to add an 'hasOwnProperty' check as well.

You can see more background and some repro steps at the following Stack Overflow discussion: http://stackoverflow.com/questions/28155841/misterious-failure-of-jquery-each-and-underscore-each-on-ios

The Underscore team have apparently managed to create an automated test for this: https://github.com/jashkenas/underscore/issues/2081

The jQuery issue is here: https://github.com/jquery/jquery/issues/2145
Comment 1 Radar WebKit Bug Importer 2015-03-26 04:12:05 PDT
<rdar://problem/20307461>
Comment 2 Yusuke Suzuki 2015-03-26 08:04:12 PDT
ossy, now I think it may be related to aarch64 failures with "length" property.
Comment 3 Michael Saboff 2015-03-26 15:49:40 PDT
I can reproduce on iOS ARM64 in ToT (r182023) WebKit.  It doesn't happen in on ARM32 or Mac.  Curious.
Comment 4 Michael Saboff 2015-03-26 16:16:48 PDT
Created attachment 249534 [details]
Converted supplied test into a regression test
Comment 5 Michael Saboff 2015-03-26 17:18:06 PDT
Looks like we have a bad instruction optimization when comparing a literal with a single bit to a register in MacroAssemblerARM64::branchTest32().

Patch in progress.
Comment 6 Michael Saboff 2015-03-27 07:06:00 PDT
Created attachment 249564 [details]
Patch
Comment 7 Csaba Osztrogonác 2015-03-27 07:18:05 PDT
Comment on attachment 249564 [details]
Patch

nice catch, r=me
Comment 8 Michael Saboff 2015-03-27 07:29:15 PDT
Committed r182058: <http://trac.webkit.org/changeset/182058>
Comment 9 Mark Hahnenberg 2015-03-27 10:26:54 PDT
This might be my favorite bug/fix ever.
Comment 10 Csaba Osztrogonác 2015-03-27 11:03:12 PDT
*** Bug 142575 has been marked as a duplicate of this bug. ***
Comment 11 Michał Gołębiowski-Owczarek 2015-03-27 16:25:54 PDT
It would be great to have it backported to iOS 8. If that's not planned (or if it's planned but we're be notified about that) we'll have to publish another patch release of jQuery dedicated to Safari; the first one was:
http://blog.jquery.com/2014/12/18/jquery-1-11-2-and-2-1-3-released-safari-fail-safe-edition/