Last Comment Bug 852467 - nsDisableOldMaxSmartSizePrefEvent runs on the gecko main thread, blocks for long periods of time
: nsDisableOldMaxSmartSizePrefEvent runs on the gecko main thread, blocks for l...
Product: Core
Classification: Components
Component: Networking: Cache (show other bugs)
: 22 Branch
: All Android
: -- normal (vote)
: mozilla23
Assigned To: Michal Novotny (:michal)
: Patrick McManus [:mcmanus]
Depends on:
Blocks: 797615 834243 856811 864103
  Show dependency treegraph
Reported: 2013-03-19 02:52 PDT by Kartikaya Gupta (
Modified: 2013-04-26 23:56 PDT (History)
13 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

fix (1.14 KB, patch)
2013-04-24 09:31 PDT, Michal Novotny (:michal)
honzab.moz: review+
Details | Diff | Splinter Review

Description Kartikaya Gupta ( 2013-03-19 02:52:56 PDT

The fact that this runnable runs on the gecko main thread and blocks on the cache in the call to nsCacheService::SetDiskSmartSize(); means that other things that need to run on the gecko main thread (e.g. some quick compositor operations) don't get to run for many seconds (I reported seeing a delay of ~18 seconds in bug 797615 comment 326). The Java UI thread needs to run these operations synchronously and times out waiting for the operations to run, which snowballs into various graphics initialization errors and much badness.

Also tagging as snappy because an 18-second block on the gecko main thread seems pretty bad.
Comment 1 Kartikaya Gupta ( 2013-03-19 16:55:36 PDT
Disabling the disk cache also fixes the intermittent testSystemPages failure. (
Comment 2 Jason Duell [:jduell] (needinfo me) 2013-03-20 11:17:13 PDT
Poked at this, and it looks like the only obvious thing that could cause the blocking here is that the code grabs the cache lock.  So the real culprit is whatever other code is holding the lock for that time.
Comment 3 Kartikaya Gupta ( 2013-03-20 15:31:58 PDT
The try build log at [1] has the stack traces for all the threads (there are 12 instances of the crash in that log file, but they are all very similar). As an example, from the first crash in that log, there are threads running in methods like:



nsDiskCacheBlockFile::Open(nsIFile*, unsigned int, unsigned int, nsDiskCache::CorruptCacheInfo*)

I don't know this code that well but it looks like that second one is probably holding the cache lock.

Comment 4 Brad Lassey [:blassey] (use needinfo?) 2013-04-08 07:10:41 PDT
the bug this is blocking is tracking firefox 21
Comment 5 bhavana bajaj [:bajaj] 2013-04-10 14:58:00 PDT
Patrick, spoke to :kats and we believe this falls under the necko team helping out with investigation/next steps here.
Assigning this to you to help with reassignment as needed.

Bug 834243 - which is a top-crasher is blocked on investigation due to this.
Comment 6 Doug Turner (:dougt) 2013-04-22 20:36:38 PDT
Bajaj, How is this bug related to bug 834243?
Comment 7 bhavana bajaj [:bajaj] 2013-04-22 21:08:36 PDT
(In reply to Doug Turner (:dougt) from comment #6)
> Bajaj, How is this bug related to bug 834243?

Doug, Check : , . I also checked with :kats & he said we need help from necko team resolve this issue to move forward on the top- crasher.
Comment 8 Kartikaya Gupta ( 2013-04-23 07:03:25 PDT
Most of my investigation about why this is a problem is on bug 797615. See comment 342 and nearby comments on that bug.
Comment 9 Doug Turner (:dougt) 2013-04-23 12:13:42 PDT
Kats, do you know what the other threads are doing when we are holding that lock?
Comment 10 Michal Novotny (:michal) 2013-04-23 12:27:14 PDT
(In reply to Doug Turner (:dougt) from comment #9)
> Kats, do you know what the other threads are doing when we are holding that
> lock?

The thread that is holding the lock is opening the disk cache. It seems that just opening few files and reading headers/bitmaps takes ages on android. 

I'm currently testing a fix for this issue on try server
Comment 11 Michal Novotny (:michal) 2013-04-24 09:31:34 PDT
Created attachment 741377 [details] [diff] [review]
Comment 13 Ryan VanderMeulen [:RyanVM] 2013-04-26 18:53:43 PDT

Note You need to log in before you can comment on or make changes to this bug.