A little bit of more data, while patching that "Local State" file worked for me for a little while, it seems the problematic state seems to reoccur while I'm using the browser.  Once I'm in this state, if I click on a link in an external program, the link wouldn't open, because the browser launch would crash.

To remedy this, I've changed my chrome start script to strip out these lines before launching every time.

jsonlint -f "/home/scott/.config/google-chrome-unstable/Local State" | grep -v "\"variations_" > /tmp/local_state_temp
cp /tmp/local_state_temp "/home/scott/.config/google-chrome-unstable/Local State"
google-chrome --user-data-dir=/home/scott/.config/google-chrome-unstable/ --ignore-certificate-errors --test-type --enable-benchmarking --password-store=basic $@ &

sglajch@ Could you please let us know is there any sample crash ID's available under chrome://crashes for this issue.

Thanks!

It looks like those were provided:

"crash IDs for these are "da8b145580000000" and "1077e45580000000"."

0x00007fea04fff796	(chrome -./out/Release/gen/components/variations/proto/study.pb.h:1907 )	variations::VariationsSeedProcessor::CreateTrialFromStudy(variations::ProcessedStudy const&, base::Callback<void (unsigned int, std::basic_string<unsigned short, base::string16_char_traits, std::allocator<unsigned short> > const&), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&, base::FieldTrial::EntropyProvider const*, base::FeatureList*)
0x00007fea04fff1ba	(chrome -./out/Release/../../components/variations/variations_seed_processor.cc:194 )	variations::VariationsSeedProcessor::CreateTrialsFromSeed(variations::VariationsSeed const&, std::string const&, base::Time const&, base::Version const&, variations::Study_Channel, variations::Study_FormFactor, std::string const&, std::string const&, std::string const&, base::Callback<void (unsigned int, std::basic_string<unsigned short, base::string16_char_traits, std::allocator<unsigned short> > const&), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&, base::FieldTrial::EntropyProvider const*, base::FeatureList*)
0x00007fea030eda05	(chrome -./out/Release/../../components/variations/service/variations_service.cc:346 )	variations::VariationsService::CreateTrialsFromSeed(base::FeatureList*)
0x00007fea01daf620	(chrome -./out/Release/../../chrome/browser/chrome_browser_main.cc:739 )	ChromeBrowserMainParts::SetupFieldTrials()


There's a crash annotation "20 crashes are from same client idby kavvaru@ -- 1 year ago"

I'm not sure what lengths we can go to in order to help users recover from corrupt user data directories (but poking around that question is how I got here, via Issue 696952 [Mac])

We actually validate the seed bytes using a sha1 signature. If the data is corrupted, we will not try to create trials from it.

A crash with that trace shouldn't happen when data coming from the file is corrupt. It would signal something more like memory corruption while Chrome is running.

Here's the relevant code where we verify the seed:

https://cs.chromium.org/chromium/src/components/variations/variations_seed_store.cc?rcl=76a2fa3cf40ee87f63d123c131b5ef5f15cdd7a6&l=176

sglajch: Have you tried running a memory test on your machine? The crash sounds like it could be caused by bad RAM.

Good question!  I will do a memory test (probably a memtest from a linux live boot USB drive) tonight on the machine.  If we are thinking corrupt memory here, I can also try and copy the profile dir to a different machine with the same chrome version and run it there.  This is actually my work laptop which is getting close to 5 years old now.

Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

sglajch@ : Gentle ping..!Please update your findings to help further progress in it.

Sorry for the delay.  The machine in question is now my old work machine as my new machine came right about the time you asked for memory test.  Also the old machine didn't work with the memtest I tried, I think because it's a macbook and uses EFI, which requires a different version of memtest.

For a while it was booting but as of today and I can't boot past the grub bootloader, so for a while I was assuming it was bad hardware, BUT....

My new machine, which I setup using the same launch script, was working for that first month, but as of yesterday, it started segfaulting as well upon launch.

After some more investigation, it looks like omitting the "-enable-benchmarking" flag made my browser successfully again.  While I remembered the reason for all the other flags I was using on startup, I don't know why I had this one flag set in the first place.  It's worth noting that my hack of removing the "variations_" fields in the Local State file like I did for the old machine above also "fixed" it in that I was able to launch chrome (even with the --enable-benchmarking flag) by removing those fields first.

So given that this has happened on 2 machines (assuming it's the same issue), it may be some weird bug or oddity of using the --enable-benchmarking flag?

I can try and see if I can run memtest on the new machine, but given that it's brand new I think hardware is doubtful to be the cause.

Thank you for providing more feedback. Adding requester "durga.behera@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

FWIW, the --enable-benchmarking flag is not intended for use by regular Chrome users; it's only intended to be used for automated testing.  I would not be particularly surprised to learn that having this flag enabled during regular usage destabilizes the Chrome app.  I'm inclined to close this bug if you're only seeing issues while that flag is enabled.

Closing the bug sounds fine to me.  I do write automated UI tests with Selenium, so probably at one point I was playing around with flags for something and just forgot to turn that one off.  Thanks for the help!