bp-d415d91d-969a-4cb5-8de6-dfc782130102 java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:796) at java.util.HashMap$ValueIterator.next(HashMap.java:828) at org.mozilla.gecko.Tabs.refreshThumbnails(Tabs.java:317) at org.mozilla.gecko.TabsTray.show(TabsTray.java:116) at org.mozilla.gecko.TabsPanel.show(TabsPanel.java:162) at org.mozilla.gecko.BrowserApp.showTabs(BrowserApp.java:451) at org.mozilla.gecko.BrowserApp.showLocalTabs(BrowserApp.java:440) at org.mozilla.gecko.BrowserToolbar.toggleTabs(BrowserToolbar.java:415) at org.mozilla.gecko.BrowserToolbar.access$200(BrowserToolbar.java:48) at org.mozilla.gecko.BrowserToolbar$3.onClick(BrowserToolbar.java:158) at android.view.View.performClick(View.java:2532) at android.view.View$PerformClick.run(View.java:9293) at android.os.Handler.handleCallback(Handler.java:587) at android.os.Handler.dispatchMessage(Handler.java:92) at android.os.Looper.loop(Looper.java:150) at android.app.ActivityThread.main(ActivityThread.java:4263) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:507) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597) at dalvik.system.NativeStart.main(Native Method) https://crash-stats.mozilla.com/report/list?signature=java.util.ConcurrentModificationException%3A+at+java.util.HashMap%24HashIterator.nextEntry%28HashMap.java%29

cc'ing a couple front end devs to see if they have any ideas about this crash.

Is there an STR for this? Tabs are being touched by two threads!

Since the only methods that modify mTabs are addTab and removeTab, you should just add thread assertions in those methods. Then if they get called from the wrong thread you'll find out right away.

The tabs code has changed quite a bit. I wonder if we're still getting any similar crashers? Kevin?

This seems to be a common but not top crash on 27b6 which is our most recent beta. However I only see one crash for 26.0.1 and no crashes in Aurora/Nightly. We would need to see if the crash is still present in Firefox 28 beta in a couple weeks to know for sure if it has dropped to a rare crash again.

Comment on attachment 8364330 [details] [diff] [review] Thread-safety improvements in Tabs (r=bnicholson) i.e. all iterations on mOrder must be synchronized on the Tabs instance.

Comment on attachment 8364330 [details] [diff] [review] Thread-safety improvements in Tabs (r=bnicholson) Review of attachment 8364330 [details] [diff] [review]: ----------------------------------------------------------------- mOrder is a CopyOnWriteArrayList, so iterations do not need to be synchronized. Taking a look at Tabs, I ran into a couple other unnecessary synchronized blocks, which I filed bug 963288 for. Enhanced for loops can be expanded to the following form [1]: for (I #i = Expression.iterator(); #i.hasNext(); ) { VariableModifiersopt TargetType Identifier = (TargetType) #i.next(); Statement } A reference to the iterator is retrieved and stored at the beginning of the loop and used for all iterations of that loop. Note that Expression is read only once. In this case, Expression is mOrder; since mOrder is a CopyOnWriteArrayList, the Iterable we're currently iterating -- the "old" mOrder list -- is not touched. The mOrder variable itself may be modified during iteration, but that won't matter since we never look at Expression again. Note that ConcurrentModificationExceptions are often thrown when modifying a list on the *same* thread being iterated; see https://bugzilla.mozilla.org/show_bug.cgi?id=834399#c10 for another situation where we've hit this. Not saying that's necessarily the case here, but something worth investigating as a cause. [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.14.2

Actually, never mind. First, I incorrectly assumed mOrder was a traditional List container. Second, this bug is not actually a top crashers. In fact, afaik, this crasher is not happening anymore. Closing. ps: sorry for the noise.

I would prefer to keep this open until we understand the 28 crash rate. Hence the whiteboard [closeme 2014-02-28].

Resolved per whiteboard