Closed Bug 752828 Opened 13 years ago Closed 7 years ago

android.database.sqlite.SQLiteDatabaseLockedException: database is locked at android.database.sqlite.SQLiteStatement.native_executeSql(Native Method) on ICS

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(firefox15-, firefox16+ wontfix, firefox17+ wontfix, firefox18- affected, firefox19 affected, firefox20 affected, firefox21 affected, firefox22 affected, firefox23 affected, firefox24 affected, firefox25 affected, fennec+)

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox15 - ---
firefox16 + wontfix
firefox17 + wontfix
firefox18 - affected
firefox19 --- affected
firefox20 --- affected
firefox21 --- affected
firefox22 --- affected
firefox23 --- affected
firefox24 --- affected
firefox25 --- affected
fennec + ---

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash, reproducible, topcrash-android-armv7, Whiteboard: [native-crash][startupcrash])

Crash Data

Attachments

(3 files)

Output of logcat for bug #752828
140.57 KB, text/plain
Details
Output of logcat for bug #778935
54.45 KB, text/plain
Details
Full output of logcat with verbose settings
431.68 KB, text/plain
Details
There are two crashes after the fix of bug 741224: bp-3826cdee-c599-4a81-8fb4-eb1d42120507. android.database.sqlite.SQLiteDatabaseLockedException: database is locked at android.database.sqlite.SQLiteStatement.native_executeSql(Native Method) at android.database.sqlite.SQLiteStatement.executeUpdateDelete(SQLiteStatement.java:90) at android.database.sqlite.SQLiteDatabase.executeSql(SQLiteDatabase.java:2032) at android.database.sqlite.SQLiteDatabase.execSQL(SQLiteDatabase.java:1972) at android.database.sqlite.SQLiteDatabase.endTransaction(SQLiteDatabase.java:748) at org.mozilla.fennec.db.BrowserProvider.update(BrowserProvider.java:1366) at android.content.ContentProvider$Transport.update(ContentProvider.java:219) at android.content.ContentResolver.update(ContentResolver.java:862) at org.mozilla.gecko.db.LocalBrowserDB.updateVisitedHistory(LocalBrowserDB.java:216) at org.mozilla.gecko.db.BrowserDB.updateVisitedHistory(BrowserDB.java:123) at org.mozilla.gecko.GlobalHistory.add(GlobalHistory.java:154) at org.mozilla.gecko.Tab$7.run(Tab.java:462) at android.os.Handler.handleCallback(Handler.java:605) at android.os.Handler.dispatchMessage(Handler.java:92) at android.os.Looper.loop(Looper.java:137) at org.mozilla.gecko.GeckoBackgroundThread.run(GeckoBackgroundThread.java:31) More reports at: https://crash-stats.mozilla.com/report/list?signature=android.database.sqlite.SQLiteDatabaseLockedException%3A+database+is+locked+at+android.database.sqlite.SQLiteStatement.native_executeSql%28Native+Method%29
It's #10 top crasher in 15.0.1, #27 in 16.0b2, #28 in 17.0a2.
tracking-fennec: --- → ?
tracking-firefox15: --- → ?
tracking-firefox16: --- → ?
Summary: android.database.sqlite.SQLiteDatabaseLockedException: database is locked at android.database.sqlite.SQLiteStatement.native_executeSql(Native Method) → android.database.sqlite.SQLiteDatabaseLockedException: database is locked at android.database.sqlite.SQLiteStatement.native_executeSql(Native Method) on ICS
Whiteboard: [native-crash] → [native-crash][startupcrash]
Won't track for 15 at this volume of crash with no apparent fix we are unlikely to look at a 15.0.2 at this stage in the cycle. Leaving 16? for now until Fennec triage makes a call on tracking-fennec.
tracking-firefox15: ? → -
Lucas/Brad, what do you need to make this issue actionable? It's sitting at #12 on 15.0.1.
Assignee: nobody → lucasr.at.mozilla
tracking-firefox16: ? → +
tracking-firefox17: --- → +
Keywords: topcrash
This doesn't seem to happen as much on fx16, maybe it's the lower number of users. Last time we made a fix for this, we had real STR. We need those again to try to fix this.
(In reply to Mark Finkle (:mfinkle) from comment #4) > This doesn't seem to happen as much on fx16, maybe it's the lower number of > users. > > Last time we made a fix for this, we had real STR. We need those again to > try to fix this. Is there anything we can point QA directly at? Rebooting the phone during usage, something related to sync, etc? We're not seeing external reports of this crash specifically.
Keywords: qawanted, steps-wanted
tracking-fennec: ? → 18+
(In reply to Alex Keybl [:akeybl] from comment #5) > (In reply to Mark Finkle (:mfinkle) from comment #4) > > This doesn't seem to happen as much on fx16, maybe it's the lower number of > > users. > > > > Last time we made a fix for this, we had real STR. We need those again to > > try to fix this. > > Is there anything we can point QA directly at? Rebooting the phone during > usage, something related to sync, etc? We're not seeing external reports of > this crash specifically. The "database is locked" problem used to happen either after a crash or after a nightly update because of zombie processes holding a database connection (see bug 750950). I need specific STR in order to work on this.
Looks like something with updating and deleting the db? I think it might have something to do with the visited db? I'll try playing around with the idea.
We're close to untracking this for release, given it's been present in the build for a while now and still isn't actionable. Are there any speculative/debug fixes that we could take to help investigate?
QA Contact: nhirata.bugzilla
Flags: needinfo?(lucasr.at.mozilla)
Keywords: qawanted
One thing to look at here is: when the "database is locked" exception happens, have a look at the list of processes (ps aux). There shouldn't be any zombie processes around.
Flags: needinfo?(lucasr.at.mozilla)
(In reply to Naoki Hirata :nhirata from comment #8) > Looks like something with updating and deleting the db? I think it might > have something to do with the visited db? I'll try playing around with the > idea. Naoki, any luck reproducing? (In reply to Lucas Rocha (:lucasr) from comment #10) > One thing to look at here is: when the "database is locked" exception > happens, have a look at the list of processes (ps aux). There shouldn't be > any zombie processes around. Is there no hardening we can do here? If it's impossible to find STR, and we can't take speculative fixes, then I'm not sure what we can do. Which is a huge shame for the #4 top crasher in 17.0b3.
I'm not familiar with this code. Are we sure there isn't another thread that can be accessing this thread? Is it possible to get the Java Stack Trace for the other java threads?
Looks like we can't get the state of the other java threads but it could be another thread trying to use it. We could test this theory by catching the error and dumping the state of all threads to the crash report before we crash. Checking with wesj since he touched this file a lot.
Flags: needinfo?(wjohnston)
(In reply to Benoit Girard (:BenWa) from comment #13) > Looks like we can't get the state of the other java threads but it could be > another thread trying to use it. We could test this theory by catching the > error and dumping the state of all threads to the crash report before we > crash. > > Checking with wesj since he touched this file a lot. The code to open database connections for each profile in the Content Provide is all synchronized so I'd be surprised if this is multi-thread related. See: http://mxr.mozilla.org/projects-central/source/accessibility/mobile/android/base/db/BrowserProvider.java.in#990
With no resolution here to consider for uplift, we have to wontfix this on 17 at this stage in the beta cycle.
status-firefox17: --- → wontfix
status-firefox18: --- → affected
status-firefox19: --- → affected
Version: Firefox 15 → Trunk
It's now #1 top crasher in 17.0 with many dupes. It accounts for 5% of all crashes.
It looks like this pops up with every major release update we ship, is this related to some updates of databases or so?
QA, maybe the easiest way to reproduce this is by upgrading? Something worth trying I guess.
This is within the top positions in early 18 beta data as well, so nominating.
tracking-firefox18: --- → ?
I don't think we can really consider this to be release specific any longer. Investigation needs to occur outside of the releases. Adding qawanted for Comment 18.
tracking-firefox18: ? → -
Keywords: qawanted
Kats is landing a patch in 20 to annotate crash reports with the last 200 lines of logcat, which may allow us to figure out STR. Let's track for 20.
tracking-fennec: 18+ → 20+
Note that my patch only has an effect on API levels 16 and higher. The handful of crash reports I looked at for this bug all happened on API level 15 - if that is the case for all of them my patch may not be useful here.
Keywords: qawanted
It's #1 top crasher in the first hours of 18.0.
This is still #2 after a couple weeks for 18.0, here's a device split of those crashes on 18 release: android.database.sqlite.SQLiteDatabaseLockedException: database is locked at android.database.sqlite.SQLiteStatement.native_executeSql(Native Method) 571 HUAWEI U8815 52 Samsung SGH-I727 41 Kyocera C5155 39 Hisense E860 36 Hisense AD683G 32 Samsung SGH-T989 21 HUAWEI U8860 18 Kyocera C5170 18 NEC N-07D 17 Samsung SGH-I747 16 Sony ST21i 16 KYOCERA URBANO PROGRESSO 13 Samsung SGH-I727R 12 Sony ST23i 11 FUJITSU T-02D 11 SHARP SH-09D 10 SHARP SH-07D 10 Asus PadFone 9 Samsung SGH-T989D 8 PANTECH PantechP9070 8 PANASONIC P-07D 7 SHARP ISW16SH 7 SHARP SBM106SH 7 Samsung SHV-E160K 6 Sony ST26i 6 PANTECH ADR910L 5 SHARP SH-10D 5 ZTE Blade III 5 TCT ALCATEL_one_touch_995 5 HUAWEI U8815N 5 FUJITSU MOBILE COMMUNICATIONS LIMITED 101F 5 Acer E330 4 NEC N-04D 4 Samsung SHV-E120K 4 SHARP SH-01E 4 PANTECH IM-A830L 4 SHARP IS17SH 4 Sony ST21i2 3 HUAWEI U8666E 3 NEC N-05D 3 ZTE Turkcell Maxi Plus 5 3 Hisense GT-i9300 3 Basewin T1Ci 3 Motorola XT901 3 Motorola MB886 3 Samsung SPH-L710 2 Unknown A21 2 Samsung SCH-I535 2 TCT ALCATEL ONE TOUCH 993D 2 PANTECH IM-A810K 2 Motorola 201M 2 Motorola XT925 2 Micromax A100 2 GIGABYTE GSmart G1342 2 PANTECH IM-A800S 2 HUAWEI C8812 2 HUAWEI U8666N 2 HUAWEI U8818 2 HUAWEI C8950D 1 Unknown CM Flare Oxygenated 1 TCT Telenor_One_Touch_S 1 FUJITSU F-11D 1 FUJITSU F-09D 1 Xiaomi MI-ONE Plus 1 ZTE ZTE Blade III 1 ZTE ZTE N880E 1 ZTE ZTE T22 1 ZTE ZTE V880E 1 ZTE ZTE BLADE III 1 ZTE V9S 1 HUAWEI TURKCELL MaxiPRO5 1 ZTE Acqua 1 Asus ME171 1 Anpei N10 1 Xiaomi MI 1S 1 Samsung SHV-E160S 1 SHARP SBM107SH 1 PANTECH IM-A760S 1 NEC N-08D 1 Aaron S100 1 PANTECH IM-A820L 1 PANTECH PantechP8010 1 PANTECH IM-A830S 1 SHARP IS15SH 1 NEC N-06D 1 Motorola XT897 1 HUAWEI U8825-1 1 Samsung SHV-E160L 1 PANTECH IM-A840S 1 Kyocera Rise 1 MLW Telecom SpeedUp S3 1 Motorola DROID RAZR HD 1 Medion MEDION LIFE P4012 1 Sony ST21a 1
Fx 20 and Fx21 support including a bit of the Android logcat in the raw JSON submitted with the crash, but only for Android versions 16 and 17 (Jelly bean versions). Is it possible to search for any crash reports that are Android 16 or 17? Getting the logcat might be able to shed some light on the problem.
(In reply to Mark Finkle (:mfinkle) from comment #25) > Is it possible to search for any crash reports that are > Android 16 or 17? There's no search for that at this time (better search has been a plan for a long time but hugely delayed by infrastructure issues), but if you look through a list like the "Reportsa" tab on https://crash-stats.mozilla.com/report/list?signature=android.database.sqlite.SQLiteDatabaseLockedException%3A+database+is+locked+at+android.database.sqlite.SQLiteStatement.native_executeSql%28Native+Method%29 you can somewhat guess Android versions by looking at kernel versions.
As far as I can tell this crash only happens on Android API 15. I grabbed the crash-analysis tarball for the 26th and am grepping all of the crash reports with this signature. It's still going but I've checked hundreds of them and so far they all happened on 15. The few that I found with API level 17 had the signature in bug 791958 and happened on Fx 19 so there's no logcat there either. There were some other ones with native_executeSql but different java stacks, e.g. bp-279bc132-efd6-495c-b7ce-255622130126 and bp-c830bc0c-b7e9-4887-a818-88e4b2130126 that happened on other Android versions.
My script finished and there's no changes. 1519 of the 1537 crash reports happened on API level 15; the remaining crashes where either like [1] or [2] (API 15 or less, or only on Fx 19+). [1] https://crash-stats.mozilla.com/report/index/f06bc533-5d34-40e5-8e46-1ec022130126 [2] https://crash-stats.mozilla.com/report/index/93c53460-72b1-44bc-8174-631b62130126
To clarify Kats last two statements Android API 15 is Android 4.0.3. https://developer.android.com/about/versions/android-4.0.3.html We would need to reflash a GNex or similar to 4.0.3.
Here's some stats on the 18.0 crashes and number of installations: date | crashes | installations ------------+---------+--------------- 2013-02-05 | 961 | 746 2013-02-06 | 987 | 764 2013-02-07 | 863 | 683 And here's 19.0 beta stats: date | crashes | installations ------------+---------+--------------- 2013-02-05 | 49 | 42 2013-02-06 | 34 | 31 2013-02-07 | 55 | 42 Used queries to find this were as follows: SELECT version,COUNT(*) as crashes,COUNT(DISTINCT client_crash_date - install_age * interval '1 second') as installations FROM reports WHERE product='FennecAndroid' AND signature='android.database.sqlite.SQLiteDatabaseLockedException: database is locked at android.database.sqlite.SQLiteStatement.native_executeSql(Native Method)' AND utc_day_is(date_processed, '2013-02-05') GROUP BY version;
Hello, I own one of the affected devices: the Huawei Y201 Pro (U8666E) sold on the german market. I can quite easily reproduce both #752828 and #778935 with Fennec 18. How to reproduce: Option 1: Open the browser and be fast to enter something into the url bar. Option 2: Open a new tab and be fast to enter something into the url bar. It doesn’t work with a new profile. I have to fill up the history for up to five minutes to get the browser crashing. I will attach trunkated output of logcat to this bug (grep $pid_of_browser). I have sent these and the full logfiles to lucasr a few days ago. Here’s an interesting observation I made: With the nightly version (21.0a1) I cannot reproduce these crashes. The UI seems to block keyboard input until everything is fine. Please ask if I might be able to help to solve this issue.
Thanks for the info Marcus.
Keywords: steps-wanted
Marcus - This is fantastic news. You might be able to get more info to appear in the logcat output by enabling DEBUG level output using: adb shell setprop log.tag.GeckoBrowserProvider DEBUG This will show a lot more DB related output in the log. It might show us what activity is happening in the DB that is causing it to be locked. Could you try that with a new profile?
Keywords: reproducible
Hi Marcus - Just wondering if you'll have time to try getting more detailed logs for us?
Flags: needinfo?(wjohnston) → needinfo?(marcus.husar)
Purchased the top crashing phone from comment 24 will be in MTV Thursday. Huawei Ascend G300
Thus far still only able to semi-reproduce a locked database/zombie processes only by schema downgrading (i.e, m-r 19 -> m-r18; my profile persisted somehow). Still no luck forward.
(In reply to Mark Finkle (:mfinkle) from comment #36) > Hi Marcus - Just wondering if you'll have time to try getting more detailed > logs for us? You’re welcome. What do I have to do? If I shall install a special apk with more detailed logging, just send it over.
Flags: needinfo?(marcus.husar)
Depends on: 843029
No longer depends on: 843029
Depends on: 843029
(In reply to Marcus Husar from comment #39) > (In reply to Mark Finkle (:mfinkle) from comment #36) > > Hi Marcus - Just wondering if you'll have time to try getting more detailed > > logs for us? > > You’re welcome. What do I have to do? If I shall install a special apk with > more detailed logging, just send it over. Marcus - If you have the device connected to your computer via USB and can use ADB (which it seems like you can), just use this command to turn on verbose log output: adb shell setprop log.tag.GeckoBrowserProvider DEBUG or adb shell setprop log.tag.GeckoBrowserProvider VERBOSE Now, when you capture the logcat it will have a lot more information in it.
Marcus - I forgot to mention: You don't need a new APK. The detailed logs will work with your existing Firefox install.
In parallel, I'm going to try to write some integration tests using Sync's test framework, see if I can replicate the live race in a test and bully the DB into complaining.
(In reply to Mark Finkle (:mfinkle) from comment #35) > adb shell setprop log.tag.GeckoBrowserProvider DEBUG > > This will show a lot more DB related output in the log. It might show us > what activity is happening in the DB that is causing it to be locked. > > Could you try that with a new profile? I'd go so far as to say VERBOSE, not DEBUG. Also: adb shell setprop log.tag.FxSync VERBOSE — one of the entities that interacts with the DB is Sync. Thanks!
Hi, I used the VERBOSE settings for log.tag.GeckoBrowserProvider and log.tag.FxSync. Because I couldn’t create a crash within 20 minutes with Fennec 19, I installed version 18.02.
The crash appears on line 3745.
Marcos, what are the steps you used to reproduce this bug?
(In reply to Lucas Rocha (:lucasr) from comment #46) > Marcos, what are the steps you used to reproduce this bug? Do you have the "Don't keep activities" setting turned on in your device?
To reproduce this bug there are a few possibilities. Option 1: Open the browser as fast as you can and enter something into the url bar. Then hit the search/go button on the soft keyboard. Option 2: Open a new tab as fast as you can, enter something (into the url bar, and hit the search/go button. Option 3: Repeat option 2 up to ten times in sequence. This doesn’t work with a new profile. You have to fill up the history for five to ten minutes before it is possible to get the browser crashing. > Marcus, what are the steps you used to reproduce this bug? I don’t have this feature turned on. I didn’t even know it existed.
status-firefox22: --- → affected
Bug 843029 doesn't help so much as it's still #8 in 20.0b2 and #4 in 21.0a2.
tracking-fennec: 20+ → +
Lucas, are we waiting for a device to get into your hands so you can repro?
Flags: needinfo?(lucasr.at.mozilla)
(In reply to Scoobidiver from comment #49) > Bug 843029 doesn't help so much as it's still #8 in 20.0b2 and #4 in 21.0a2. Confirmed in 20.0 where it's #3 top crasher.
status-firefox23: --- → affected
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #50) > Lucas, are we waiting for a device to get into your hands so you can repro? Not sure. FWIW, mfinkle has fixed some DB-related stuff in the awesome screen which might help here. e.g. bug 856739.
Flags: needinfo?(lucasr.at.mozilla)
Depends on: 856739
We aren't showing any crashes past 4/11 with this signature. Still monitoring.
ignore last comment. I was able to pull up some crashes with today's build 20130415004014 : https://crash-stats.mozilla.com/report/index/07a7b585-a2e9-4d05-a58a-74a3a2130415
This is down somewhat since we shipped 20.0.1 and 21.0b2, but between half and all of that decline has been scooped up by bug 790922 instead.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #55) > This is down somewhat since we shipped 20.0.1 and 21.0b2, but between half > and all of that decline has been scooped up by bug 790922 instead. These two bugs have the same breakdown per device. Here are the highest ones: Sony ST21i 115 HUAWEI U8815 109 Kyocera C5155 81 Sony ST23i 70 Hisense AD683G 53 HUAWEI U8666E 42 Kyocera C5170 36 KYOCERA URBANO PROGRESSO 34 Hisense E860 34 Sony ST26i 33 ZTE ZTE BLADE III 31 HUAWEI U8860 29 TCT ALCATEL ONE TOUCH 993D 20 FUJITSU F-11D 19 NEC N-07D 17 PANTECH PantechP9070 16 SHARP SH-07D 15 ZTE Turkcell Maxi Plus 5 13 FUJITSU T-02D 13 Kyocera Event 13 PANASONIC P-07D 12 Sony ST21i2 12 Samsung SGH-I727 10 Sony ST23a 10
status-firefox24: --- → affected
Assignee: lucasr.at.mozilla → nobody
status-firefox25: --- → affected
I think those are all very low-end phones, but we might have guessed that from the kind of problem already. ;-)
If you look at the "Mobile Device" section" of the Signature Summary in https://crash-stats.mozilla.com/report/list?signature=android.database.sqlite.SQLiteDatabaseLockedException%3A+database+is+locked+at+android.database.sqlite.SQLiteStatement.native_executeSql%28Native+Method%29 you'll see that all those reports are on Android API level 15. Not sure how much info that gives us.
Depends on: 947941
Depends on: 947939
Richard, did you fix this already?
Assignee: nobody → rnewman
No, but see Bug 947939, Bug 947941 for leads.
Blocks: 975024
filter on [mass-p5]
Priority: -- → P5
Priority: P5 → --
Assignee: rnewman → nobody
Crash Signature: [@ android.database.sqlite.SQLiteDatabaseLockedException: database is locked at android.database.sqlite.SQLiteStatement.native_executeSql(Native Method)] → [@ android.database.sqlite.SQLiteDatabaseLockedException: database is locked at android.database.sqlite.SQLiteStatement.native_executeSql(Native Method)] [@ android.database.sqlite.SQLiteDatabaseLockedException: database is locked at android.database.sql…
Closing because no crashes reported for 12 weeks.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Closing because no crashes reported for 12 weeks.
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

Creator:
Created:
Updated:
Size: