1144656 - SettingDB lock timeout too short

Status: RESOLVED INCOMPLETE

(Core :: DOM: Device Interfaces, defect)

Description

[Thomas Zimmermann [:tzimmermann] [:tdz]]

On emulator-kk I see a bunch of these error messages during startup.

> W/GeckoConsole(   63): [JavaScript Error: "Settings queue head blocked at {a695b77d-1589-4fbd-8334-477930e6d7b7} for 68.421 secs, Settings API may be soft lockup. Lock from: SettingsServiceLock@jar:file:///system/b2g/omni.ja!/components/SettingsService.js:80:17
> W/GeckoConsole(   63): createLock@jar:file:///system/b2g/omni.ja!/components/SettingsService.js:291:16
> W/GeckoConsole(   63): " {file: "resource://gre/modules/SettingsRequestManager.jsm" line: 1031}]
> I/Gecko   (   63): -*- SettingsRequestManager: Settings queue head blocked at {a695b77d-1589-4fbd-8334-477930e6d7b7} for 68.421 secs, Settings API may be soft lockup. Lock from: SettingsServiceLock@jar:file:///system/b2g/omni.ja!/components/SettingsService.js:80:17
> I/Gecko   (   63): createLock@jar:file:///system/b2g/omni.ja!/components/SettingsService.js:291:16
> I/Gecko   (   63):

There's a lot of initialization going on in the background and the emulator is too slow to handle this quickly. The timeout in SettingsRequestManager.jsm is 30 seconds. I set it to 300 and the errors disappear.

Can we increase the timeout or make it configurable via system properties?

Comment 1

[Alexandre LISSY :gerard-majax]

Well it's just a warning for the sake of avoiding regressing the bad locking issues we had in the past, and in case it may happen, being able to track the root cause. The value of 30 secs was just a value I mostly picked to be good enough on startup of low devices, and still exposing quite fastly the locking issue when it happened.

A bad clock may also trigger it, as in bug 1119727

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Having had to use the emulator-kk builds recently too, I agree that it would be nice to parametrize this for those builds.  It looks like SettingsRequestManager.jsm is not currently preprocessed, and preprocessing JS files is horrible, so it seems like a pref in the already-preprocessed b2g/app/b2g.js for this situation would be ideal.  The pref could just be read at init time with the other prefs in the file (no need to update in real-time to changes to the pref.)

Comment 3

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

I second what :gerard-majax said in Comment 1.

Comment 4

[Edgar Chen [:edgar]]

Looks like bug 1119727 are going to provide a way to configure the timeout threshold.

Comment 5

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Cleaning up Device Interfaces component, and mass-marking old FxOS bugs as incomplete.

If any of these bugs are still valid, please let me know.