Closed
Bug 705509
Opened 13 years ago
Closed 13 years ago
Crash in mozilla::places::Database::GetAsyncStatement close to startup
Categories
(Toolkit :: Places, defect)
Tracking
()
RESOLVED
FIXED
mozilla11
Tracking | Status | |
---|---|---|
firefox10 | --- | fixed |
People
(Reporter: scoobidiver, Assigned: mak)
Details
(Keywords: crash, regression, Whiteboard: [qa-])
Crash Data
Attachments
(1 file)
36.27 KB,
patch
|
dietrich
:
review+
asa
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
It's a startup crash that first appeared in 10.0a1/20111029. Signature mozilla::places::Database::GetAsyncStatement(nsACString_internal const&) UUID 94325132-1d93-4c56-94bc-26a4b2111126 Date Processed 2011-11-26 09:53:08.210077 Uptime 3 Last Crash 21 seconds before submission Install Age 2.8 hours since version was first installed. Install Time 2011-11-26 15:04:54 Product Firefox Version 11.0a1 Build ID 20111126031027 Release Channel nightly OS Windows NT OS Version 6.1.7601 Service Pack 1 Build Architecture x86 Build Architecture Info GenuineIntel family 6 model 23 stepping 10 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x8a App Notes AdapterVendorID: 1002, AdapterDeviceID: 954f, AdapterSubsysID: 00000000, AdapterDriverVersion: 8.911.0.0 Processor Notes WARNING: JSON file missing Add-ons EMCheckCompatibility False Frame Module Signature [Expand] Source 0 xul.dll mozilla::places::Database::GetAsyncStatement toolkit/components/places/Database.h:234 1 xul.dll nsNavHistory::invalidateFrecencies toolkit/components/places/nsNavHistory.cpp:1265 2 xul.dll mozilla::places::Database::MigrateV7Up toolkit/components/places/Database.cpp:981 3 xul.dll mozilla::places::Database::InitSchema More reports at: https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Aplaces%3A%3ADatabase%3A%3AGetAsyncStatement%28nsACString_internal%20const%26%29
Assignee | ||
Comment 1•13 years ago
|
||
looking at the stack, sounds like an upgrade from Firefox 3.0.x, may be reproduceable that way.
Assignee | ||
Comment 3•13 years ago
|
||
I can't reproduce the bug upgrading from 3.0, but I think I nailed i down and it may be due to an upgrade from a 3.0 alpha version, before frecency was added to the schema, since we hit this code path: nsCOMPtr<mozIStorageStatement> hasFrecencyStatement; rv = mMainConn->CreateStatement(NS_LITERAL_CSTRING( "SELECT frecency FROM moz_places"), getter_AddRefs(hasFrecencyStatement)); if (NS_FAILED(rv)) { ... nsNavHistory* history = nsNavHistory::GetHistoryService(); And that causes a re-entrancy. I'm looking around if I can figure out which alpha and find a still valid download link.
Assignee | ||
Updated•13 years ago
|
Flags: in-testsuite+
OS: Windows 7 → All
Hardware: x86 → All
Assignee | ||
Comment 4•13 years ago
|
||
I would like to see this in Aurora, since even if it may affect just a few users, debugging their problems in future may be hellish. For that reason I added some tests: - Check that upgrading a db with schema < 6 replaces the database - Check that upgrading a db with a largely incomplete schema 6 replaces the database (at least the unique index on moz_places.url should exist) - Check that upgrading a db with a schema 6 missing frecency does not crash (the actual crash in this bug) Note that we may have some users out there coming from Firefox 3 alpha nightlies with broken indices, this is a long standing issue and at this point I'm not sure we can do much about that, they'll be fixed when we'll completely replace the database schema. This is mostly due to lack of testing in the past, just to underline how important is that we test things.
Attachment #577416 -
Flags: review?(dietrich)
Comment 5•13 years ago
|
||
Comment on attachment 577416 [details] [diff] [review] patch v1.0 Review of attachment 577416 [details] [diff] [review]: ----------------------------------------------------------------- r=me, thanks!
Attachment #577416 -
Flags: review?(dietrich) → review+
Assignee | ||
Comment 6•13 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/360687ba014a
Target Milestone: --- → mozilla11
Assignee | ||
Comment 7•13 years ago
|
||
Comment on attachment 577416 [details] [diff] [review] patch v1.0 I would like to take this on Aurora since users are hitting the crash, and looks like a couple regressions were introduced with recent migration code move (that is part of Firefox 10). We should help users updating from ancient versions (like 3.0) rather than crashing while they are trying to do so. Comes with 3 tests for various migration environments.
Attachment #577416 -
Flags: approval-mozilla-aurora?
Comment 8•13 years ago
|
||
Not sure high volume but it's a regression introduced in 10. It would be nice to take if the fix isn't risky.
Updated•13 years ago
|
Attachment #577416 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Comment 9•13 years ago
|
||
Thank you. The risk is low since this touches migration of really old profiles (<3.5) and has tests for each change. https://hg.mozilla.org/releases/mozilla-aurora/rev/53b1db0a0d4b
status-firefox10:
--- → fixed
Assignee | ||
Comment 10•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/360687ba014a
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 11•12 years ago
|
||
Assuming this is reproducible with a 3.0a* build, is there some way QA can create a profile which will reproduce this bug, and ultimately verify the fix?
Whiteboard: [qa?]
Assignee | ||
Comment 12•12 years ago
|
||
I think the test are enough to verify this, though they include a couple places.sqlite databases you can copy to a profile and then try to launch the app. Off-hand I don't remember which alpha version was, should be something around alpha7, the problem is that schema migrations at that time were coalesced into existing functions, thus creating nice bugs.
You need to log in
before you can comment on or make changes to this bug.
Description
•