Summary: | [BlackBerry] crash in CookieDatabaseBackingStore. | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Jason Liu <jasonliuwebkit> | ||||||||
Component: | WebKit BlackBerry | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | liachen, mifenton, staikos, tonikitoo, webkit.review.bot | ||||||||
Priority: | P2 | ||||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | Other | ||||||||||
OS: | Other | ||||||||||
Attachments: |
|
Description
Jason Liu
2012-06-29 04:13:57 PDT
Created attachment 150135 [details]
Patch
If the db is null, won't it cause massive behavioural failure? (In reply to comment #2) > If the db is null, won't it cause massive behavioural failure? There are not cookies from database. So users may input something again if this happens. Comment on attachment 150135 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=150135&action=review > Source/WebCore/ChangeLog:8 > + It is hard to reproduce it now. And there is not a bad data base to analyse. Why is it hard to reproduce? Is there an internal PR? > Source/WebCore/ChangeLog:9 > + So add a guard for cookies pointer. Add an empty line here. > Source/WebCore/ChangeLog:10 > + No new tests, behavior has not changed. Not strictly true, behavior has changed for when cookies is null. (In reply to comment #4) > (From update of attachment 150135 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=150135&action=review > > > Source/WebCore/ChangeLog:8 > > + It is hard to reproduce it now. And there is not a bad data base to analyse. > > Why is it hard to reproduce? Is there an internal PR? > PR 158159, I didn't reproduce it. And Wei said it is hard, too. > > Source/WebCore/ChangeLog:9 > > + So add a guard for cookies pointer. > > Add an empty line here. > > > Source/WebCore/ChangeLog:10 > > + No new tests, behavior has not changed. > > Not strictly true, behavior has changed for when cookies is null. Because it is hard to reproduce, so I am not sure a test case is needed. Comment on attachment 150135 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=150135&action=review R- for now, please mention internal PR and reword the ChangeLog a bit. >> Source/WebCore/ChangeLog:10 >> + No new tests, behavior has not changed. > > Not strictly true, behavior has changed for when cookies is null. I still think you need to explain better, maybe have somebody in the office help you with the ChangeLog? I think following message is the real issue, somehow the database file is locked and we are unable to create a table. We need to fix this. Jul 04 19:25:28 3 10023 1 Thread 8 (warning!): ERROR: Could not create the table to store the cookies into. No cookie will be stored! /home/lyon/work/rebase/webkit/Source/WebCore/platform/blackberry/CookieDatabaseBackingStore/CookieDatabaseBackingStore.cpp(223) : void WebCore::CookieDatabaseBackingStore::invokeOpen(const WTF::String&) Jul 04 19:25:28 3 10023 1 Thread 8 (warning!): ERROR: SQLite Error Message: database is locked Created attachment 151622 [details]
Patch
Created attachment 151642 [details]
Patch
Comment on attachment 151642 [details]
Patch
Seems ok. Technically you could have put the delete inside the if (cookies) too but it doesn't make any practical difference.
Comment on attachment 151642 [details] Patch Clearing flags on attachment: 151642 Committed r122328: <http://trac.webkit.org/changeset/122328> All reviewed patches have been landed. Closing bug. |