[chromium-dev] Re: Profile Corruption, cause?
Hello, thanks for your reply. I understand about User Agreement between the user and Google, I thought a Stack trace would help a little to figure out what is really going on. People are getting really annoyed (on the forums) since their browser quickly crashes when they open it, after couple seconds, when they click on a tab, etc. All this was resolved by a profile cleanup. Would it be possibly to do an integrity check if the profile is valid? How much cost would that add to the run-time of chrome? If we somehow check if the profile is valid, and as you said, inform the user that it is corrupt, we can even break it down even further, to find out which section of his profile is corrupt. That way, we might have a mechanism to attempt fixing it or wiping it. I believe adding that small performance cost will make browsing more enjoyable due to corruption, it never happened to me, and I always cross my fingers that it does, because I could try and attempt debugging it at my end. Thanks! On Fri, Mar 6, 2009 at 1:20 AM, Mark Larson (Google) m...@chromium.orgwrote: Mohamed, I'm glad to see your interest in tackling this problem. Unfortunately, that data is collected under an agreement between the user and Google, so we cannot share the dumps. It's OK to share the stack traces, which have no personally identifying information, but I'm not sure we can even find a set of reports definitely correlated with profile corruption. This makes me wonder if we should have an integrity check when we detect that the browser crashed in the previous session. It might be useful to offer to reset the user's profile or (ideally) drop the parts that are corrupt. I'd personally rather drop my entire browsing history to keep my saved passwords (and vice versa). The UI would have to be diplomatic. Maybe some developers who have dealt with corruption issues in the past can provide some advice on things we could do to address corruption. Thanks, Mark On Thu, Mar 5, 2009 at 21:09, Mohamed Mansour m0.interact...@gmail.comwrote: Hello, on the Google Help Forums, 80-85% of the crashes reported there are due to profile corruptions. What they have to do is run chrome in a new user directory, chrome.exe --user-data-dir=c:\foo, or deleting the local state file. Anyone have any idea what may of caused this? Users who don't know the answer to this problem, usually give up using the browser. Chrome is a great browser, and its sad to see people not using it because of this. If anyone has any crash logs due to this (from user reporting), and since its internal to Google, can you share the stack trace? I would like to spend one weekend taking a look at it. Thanks! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Profile Corruption, cause?
One thing that would help is if some of the users who are running into this would be willing to share their whole profile with us. While our best guess is that this is sqlite corruption, we don't know for sure. Even if it is sqlite corruption, having the specific db might help us figure out how to more reliably detect it. Erik On Thu, Mar 5, 2009 at 10:39 PM, Finnur Thorarinsson fin...@chromium.org wrote: I suspect this is like crashes due to memory corruption: It won't do much good to stare at the call stack at the time corruption was detected; we need to know the stack at the time corruption occurred (assuming this is Chrome that is corrupting the profile). For memory corruptions we have gflags; I wonder if there is something in SqlLite that can help us here? On Thu, Mar 5, 2009 at 22:20, Mark Larson (Google) m...@chromium.org wrote: Mohamed, I'm glad to see your interest in tackling this problem. Unfortunately, that data is collected under an agreement between the user and Google, so we cannot share the dumps. It's OK to share the stack traces, which have no personally identifying information, but I'm not sure we can even find a set of reports definitely correlated with profile corruption. This makes me wonder if we should have an integrity check when we detect that the browser crashed in the previous session. It might be useful to offer to reset the user's profile or (ideally) drop the parts that are corrupt. I'd personally rather drop my entire browsing history to keep my saved passwords (and vice versa). The UI would have to be diplomatic. Maybe some developers who have dealt with corruption issues in the past can provide some advice on things we could do to address corruption. Thanks, Mark On Thu, Mar 5, 2009 at 21:09, Mohamed Mansour m0.interact...@gmail.com wrote: Hello, on the Google Help Forums, 80-85% of the crashes reported there are due to profile corruptions. What they have to do is run chrome in a new user directory, chrome.exe --user-data-dir=c:\foo, or deleting the local state file. Anyone have any idea what may of caused this? Users who don't know the answer to this problem, usually give up using the browser. Chrome is a great browser, and its sad to see people not using it because of this. If anyone has any crash logs due to this (from user reporting), and since its internal to Google, can you share the stack trace? I would like to spend one weekend taking a look at it. Thanks! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Profile Corruption, cause?
On Fri, Mar 6, 2009 at 9:33 AM, Brett Wilson bre...@google.com wrote: Getting the database has helped in a few cases where it turned out some assumptions were being violated, but if the sqlite data structures are corrupted, getting the DB has never been helpful to diagnose the root cause. It might help us make sqlite not crash for these types of corruption, though. I think we should install an exception handler on the DB threads, and if we get two crashes in a row from sqlite, recreate the DB. Yep. This would be nice. If these crashes are really this frequent, perhaps we should move the db out of the browser process. Or perhaps we could simply have an out of process validator that we could run if we got a single browser crash from sqlite. Erik Brett On Mar 6, 2009 9:19 AM, Erik Kay erik...@chromium.org wrote: One thing that would help is if some of the users who are running into this would be willing to share their whole profile with us. While our best guess is that this is sqlite corruption, we don't know for sure. Even if it is sqlite corruption, having the specific db might help us figure out how to more reliably detect it. Erik On Thu, Mar 5, 2009 at 10:39 PM, Finnur Thorarinsson fin...@chromium.org wrote: I suspect this... --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Profile Corruption, cause?
If SQLite is crashing due to corruption in the database, we should be able to get Dr Hipp to help fix it. But we'd need a repeatable case to send to him. If we had a database which demonstrated this, I could certainly see about crafting a simplified database of example data to replicate the problem. If it's due to the in-memory data structures being corrupted, that's a whole 'nother kettle of fish, I'm not sure what SQLite can really do about that. An idea I've had in the past was so implement a custom memory allocator to keep the SQLite data structures in a distinct zone from regular data structures, so that you at least can't get the case of stale references being used to overwrite data structures, and should help protect against other code's buffer overflows. Random rogue pointers would still be dangerous, though! Some of our databases we preemptively read to warm up the disk cache, so just running PRAGMA integrity_check; might be cheap enough to be useful. Another option we could consider would be adding (or looking for) code to checksum pages. We could also perhaps implement independent page validity checks at the VFS layer, before things go to disk, to protect against in-memory structures being corrupted, which could at least keep things valid at a metadata level. In my experience SQLite is pretty good about throwing SQLITE_CORRUPT when it detects corruption, but due to how data is encoded there are a lot of cases where the corruption is not easy to detect w/in SQLite (you get back garbage, but it's well-formed garbage :-). If SQLite itself is overrunning buffers or something, that's a definite bug which I'm sure Dr Hipp would be interested in helping fix. -scott On Fri, Mar 6, 2009 at 10:02 AM, Erik Kay erik...@chromium.org wrote: On Fri, Mar 6, 2009 at 9:33 AM, Brett Wilson bre...@google.com wrote: Getting the database has helped in a few cases where it turned out some assumptions were being violated, but if the sqlite data structures are corrupted, getting the DB has never been helpful to diagnose the root cause. It might help us make sqlite not crash for these types of corruption, though. I think we should install an exception handler on the DB threads, and if we get two crashes in a row from sqlite, recreate the DB. Yep. This would be nice. If these crashes are really this frequent, perhaps we should move the db out of the browser process. Or perhaps we could simply have an out of process validator that we could run if we got a single browser crash from sqlite. Erik Brett On Mar 6, 2009 9:19 AM, Erik Kay erik...@chromium.org wrote: One thing that would help is if some of the users who are running into this would be willing to share their whole profile with us. While our best guess is that this is sqlite corruption, we don't know for sure. Even if it is sqlite corruption, having the specific db might help us figure out how to more reliably detect it. Erik On Thu, Mar 5, 2009 at 10:39 PM, Finnur Thorarinsson fin...@chromium.org wrote: I suspect this... --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Profile Corruption, cause?
Mohamed, I'm glad to see your interest in tackling this problem. Unfortunately, that data is collected under an agreement between the user and Google, so we cannot share the dumps. It's OK to share the stack traces, which have no personally identifying information, but I'm not sure we can even find a set of reports definitely correlated with profile corruption. This makes me wonder if we should have an integrity check when we detect that the browser crashed in the previous session. It might be useful to offer to reset the user's profile or (ideally) drop the parts that are corrupt. I'd personally rather drop my entire browsing history to keep my saved passwords (and vice versa). The UI would have to be diplomatic. Maybe some developers who have dealt with corruption issues in the past can provide some advice on things we could do to address corruption. Thanks, Mark On Thu, Mar 5, 2009 at 21:09, Mohamed Mansour m0.interact...@gmail.comwrote: Hello, on the Google Help Forums, 80-85% of the crashes reported there are due to profile corruptions. What they have to do is run chrome in a new user directory, chrome.exe --user-data-dir=c:\foo, or deleting the local state file. Anyone have any idea what may of caused this? Users who don't know the answer to this problem, usually give up using the browser. Chrome is a great browser, and its sad to see people not using it because of this. If anyone has any crash logs due to this (from user reporting), and since its internal to Google, can you share the stack trace? I would like to spend one weekend taking a look at it. Thanks! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Profile Corruption, cause?
I suspect this is like crashes due to memory corruption: It won't do much good to stare at the call stack at the time corruption was detected; we need to know the stack at the time corruption occurred (assuming this is Chrome that is corrupting the profile). For memory corruptions we have gflags; I wonder if there is something in SqlLite that can help us here? On Thu, Mar 5, 2009 at 22:20, Mark Larson (Google) m...@chromium.org wrote: Mohamed, I'm glad to see your interest in tackling this problem. Unfortunately, that data is collected under an agreement between the user and Google, so we cannot share the dumps. It's OK to share the stack traces, which have no personally identifying information, but I'm not sure we can even find a set of reports definitely correlated with profile corruption. This makes me wonder if we should have an integrity check when we detect that the browser crashed in the previous session. It might be useful to offer to reset the user's profile or (ideally) drop the parts that are corrupt. I'd personally rather drop my entire browsing history to keep my saved passwords (and vice versa). The UI would have to be diplomatic. Maybe some developers who have dealt with corruption issues in the past can provide some advice on things we could do to address corruption. Thanks, Mark On Thu, Mar 5, 2009 at 21:09, Mohamed Mansour m0.interact...@gmail.comwrote: Hello, on the Google Help Forums, 80-85% of the crashes reported there are due to profile corruptions. What they have to do is run chrome in a new user directory, chrome.exe --user-data-dir=c:\foo, or deleting the local state file. Anyone have any idea what may of caused this? Users who don't know the answer to this problem, usually give up using the browser. Chrome is a great browser, and its sad to see people not using it because of this. If anyone has any crash logs due to this (from user reporting), and since its internal to Google, can you share the stack trace? I would like to spend one weekend taking a look at it. Thanks! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
