Closed Bug 949429 Opened 6 years ago Closed 6 years ago

Intermittent PROCESS-CRASH | java-exception | java.lang.IndexOutOfBoundsException: Invalid index 0, size is 0 at java.util.ArrayList.throwIndexOutOfBoundsException(ArrayList.java:257)

Categories

(Firefox for Android :: General, defect)

ARM
Android
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 29
Tracking Status
firefox27 --- unaffected
firefox28 --- unaffected
firefox29 --- fixed
firefox-esr24 --- unaffected

People

(Reporter: cbook, Assigned: lucasr)

References

(Blocks 1 open bug, )

Details

(Keywords: crash, intermittent-failure)

Attachments

(2 files)

Android 2.2 Armv6 Tegra fx-team opt test robocop-1 on 2013-12-12 03:47:29 PST for push 64376a7a08df

slave: tegra-144

https://tbpl.mozilla.org/php/getParsedLog.php?id=31866290&tree=Fx-Team

PROCESS-CRASH | java-exception | java.lang.IndexOutOfBoundsException: Invalid index 0, size is 0 at java.util.ArrayList.throwIndexOutOfBoundsException(ArrayList.java:257)

 at dalvik.system.NativeStart.main(Native Method)

"Binder Thread #2" prio=5 tid=7 NATIVE
  | group="main" sCount=1 dsCount=0 s=N obj=0x4838d468 self=0x1187d8
  | sysTid=1248 nice=0 sched=3/0 cgrp=unknown handle=1174248
  | schedstat=( 1091000 30801000 4 )
  at dalvik.system.NativeStart.run(Native Method)

"Binder Thread #1" prio=5 tid=6 NATIVE
  | group="main" sCount=1 dsCount=0 s=N obj=0x4838c838 self=0x11e7e8
  | sysTid=1243 nice=0 sched=3/0 cgrp=unknown handle=1173416
  | schedstat=( 2134000 30571000 10 )
  at dalvik.system.NativeStart.run(Native Method)

"Compiler" daemon prio=5 tid=5 VMWAIT
  | group="system" sCount=1 dsCount=0 s=N obj=0x48386348 self=0x11ee28
  | sysTid=1242 nice=0 sched=3/0 cgrp=unknown handle=1147464
  | schedstat=( 522000 7174000 4 )
  at dalvik.system.NativeStart.run(Native Method)

"JDWP" daemon prio=5 tid=4 VMWAIT
  | group="system" sCount=1 dsCount=0 s=N obj=0x483862a0 self=0x118060
  | sysTid=1241 nice=0 sched=3/0 cgrp=unknown handle=1180144
  | schedstat=( 263000 248000 7 )
  at dalvik.system.NativeStart.run(Native Method)

"Signal Catcher" daemon prio=5 tid=3 RUNNABLE
  | group="system" sCount=0 dsCount=0 s=N obj=0x483861e8 self=0x123630
  | sysTid=1236 nice=0 sched=3/0 cgrp=unknown handle=1203760
  | schedstat=( 186000 8852000 2 )
  at dalvik.system.NativeStart.run(Native Method)

"HeapWorker" daemon prio=5 tid=2 VMWAIT
  | group="system" sCount=1 dsCount=0 s=N obj=0x455ca340 self=0x120000
  | sysTid=1227 nice=0 sched=3/0 cgrp=unknown handle=1156288
  | schedstat=( 7117000 41747000 4 )
  at dalvik.system.NativeStart.run(Native Method)
Assignee: nobody → lucasr.at.mozilla
Blocks: lists
Depends on: 942231
This might happen if we try to redisplay the HomePager before it finishes loading its pages from HomeConfig.
Comment on attachment 8346654 [details] [diff] [review]
Correctly check HomePager presence and visibility on redisplay (r=rnewman)

The HomePager member might be non-null but not visible (in which case we shouldn't do anything). BrowserApp's isHomePagerVisible() does the correct check i.e. non-null + isVisible().
Attachment #8346654 - Flags: review?(rnewman)
Comment on attachment 8346655 [details] [diff] [review]
Properly handle redisplay() calls before HomePager config is loaded (r=margaret)

This is race caused by the async loading of HomePager pages. We need to gracefully handle the case where redisplay() is called before the HomePager config is loaded.
Attachment #8346655 - Flags: review?(margaret.leibovic)
Comment on attachment 8346654 [details] [diff] [review]
Correctly check HomePager presence and visibility on redisplay (r=rnewman)

Review of attachment 8346654 [details] [diff] [review]:
-----------------------------------------------------------------

This seems sane, but we ought to test it... (by hand, alas).
Attachment #8346654 - Flags: review?(rnewman) → review+
Comment on attachment 8346655 [details] [diff] [review]
Properly handle redisplay() calls before HomePager config is loaded (r=margaret)

Review of attachment 8346655 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/base/home/HomeAdapter.java
@@ +98,5 @@
>      public Page getPageAtPosition(int position) {
> +        // getPageAtPosition() might be called before HomeAdapter
> +        // has got its initial list of PageEntries. Just bail.
> +        if (mPageInfos.isEmpty()) {
> +            return null;

I followed the logic in HomePager to make sure we're safe to return null here, and it looks okay to me, but we should update some of the HomePager docs to make that clear (e.g. we end up passing a null page parameter to HomePager.show following this logic).

::: mobile/android/base/home/HomePager.java
@@ +185,5 @@
>  
>      public void redisplay(LoaderManager lm, FragmentManager fm) {
>          final HomeAdapter adapter = (HomeAdapter) getAdapter();
>  
> +        // If mInitialPage is non-null, this means the HomePager hasn't

Is this comment supposed to read "If mInitialPage is null..."?

@@ +193,5 @@
> +        if (mInitialPage != null) {
> +            currentPage = mInitialPage;
> +        } else {
> +            currentPage = adapter.getPageAtPosition(getCurrentItem());
> +        }

As a follow-up it might be nice to re-work this logic to just be part of show(), since show() is what actually sets mInitialPage, so it feels kinda round-about to pass mInitialPage in as the page parameter if it's not null.

But that's not important right now, this fix is fine to land.
Attachment #8346655 - Flags: review?(margaret.leibovic) → review+
You need to log in before you can comment on or make changes to this bug.