Closed Bug 869225 Opened 11 years ago Closed 7 years ago

StrictMode policy violation in GeckoApp.getSessionRestoreState(GeckoApp.java:1726)

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set
normal

Tracking

(firefox55 fixed)

RESOLVED FIXED
Firefox 55
Tracking Status
firefox55 --- fixed

People

(Reporter: rnewman, Assigned: JanH)

References

Details

Attachments

(1 file)

Reading SharedPreferences from the main thread.

D/StrictMode(16578): StrictMode policy violation; ~duration=178 ms: android.os.StrictMode$StrictModeDiskReadViolation: policy=31 violation=2
D/StrictMode(16578): 	at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk(StrictMode.java:1198)
D/StrictMode(16578): 	at android.app.SharedPreferencesImpl.awaitLoadedLocked(SharedPreferencesImpl.java:184)
D/StrictMode(16578): 	at android.app.SharedPreferencesImpl.getBoolean(SharedPreferencesImpl.java:241)
D/StrictMode(16578): 	at org.mozilla.gecko.GeckoApp.getSessionRestoreState(GeckoApp.java:1726)
D/StrictMode(16578): 	at org.mozilla.gecko.GeckoApp.onCreate(GeckoApp.java:1411)
D/StrictMode(16578): 	at org.mozilla.gecko.BrowserApp.onCreate(BrowserApp.java:343)
D/StrictMode(16578): 	at android.app.Activity.performCreate(Activity.java:5066)
D/StrictMode(16578): 	at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1102)
D/StrictMode(16578): 	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2288)
D/StrictMode(16578): 	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2368)
D/StrictMode(16578): 	at android.app.ActivityThread.access$600(ActivityThread.java:151)
D/StrictMode(16578): 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1330)
D/StrictMode(16578): 	at android.os.Handler.dispatchMessage(Handler.java:99)
D/StrictMode(16578): 	at android.os.Looper.loop(Looper.java:155)
D/StrictMode(16578): 	at android.app.ActivityThread.main(ActivityThread.java:5536)
On my local builds, this seems to totally kill about:home, and other background tasks that were queued up. Very annoying.
Actually, that might be a lie. Hard to tell with strict mode.
Hmm, I'm not seeing those particular violations any more (even though we're still reading shared prefs to determine whether we should restore or not), but instead there are a number of those caused by checking whether our last session crashed or not. I think it should be safe to move those bits into the the background thread runnable that does the actual session file parsing.
Assignee: nobody → jh+bugzilla
Comment on attachment 8867334 [details]
Bug 869225 - Move decision whether to restore session or not onto background thread.

https://reviewboard.mozilla.org/r/138842/#review145516

mShouldRestore seems to be used later on the UI thread -> Are you sure it's safe to set it on a background thread (that might run a bit later)? Also doesn't mShouldRestore need to be defined as volatile in this case? I didn't investigate too much here, so I r+ in case you think it's safe.
Attachment #8867334 - Flags: review?(s.kaspari) → review+
Comment on attachment 8867334 [details]
Bug 869225 - Move decision whether to restore session or not onto background thread.

https://reviewboard.mozilla.org/r/138842/#review145516

I'm updating the commit message to update my reasoning, but yes, it should be a) safe and b) no worse than the mixed access we're already having today.
Pushed by mozilla@buttercookie.de:
https://hg.mozilla.org/integration/autoland/rev/89319dc2a1d0
Move decision whether to restore session or not onto background thread. r=sebastian
https://hg.mozilla.org/mozilla-central/rev/89319dc2a1d0
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 55
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: