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
-~----------~----~----~----~------~----~------~--~---
