crash-reporter should sync the correct version info into reports (and not always pull from /etc) |
||||||||||
Issue descriptionRight now the kernel crash reporter often reports crashes against the wrong version. Specifically, this happens: 1. User is on Version A 2. User downloads version B. 3. User sees that update is pending but doesn't choose to reboot. 4. Kernel crashes while running version A => device reboots 5. Since device is rebooting, we boot with the new version B. 6. Crash reporter runs and reports a crash against the current system version (B) As you can see above: a crash while running version A is reported as being with version B. This problem is especially prevalent when a new version is released to fix a large number of crashes in an old version. --- Perhaps: 1. When kernel collector runs, process crashes using an old lsb-release copied from the last run of the kernel crash collector. 2. After kernel collector runs, copy the current lsb-release somewhere (in /var?) for the next run.
,
Nov 4 2016
Adding a few people who might be interested.
,
Mar 14 2017
djkurtz@/drinkcat@ would either of you have cycles to update this for us? Or have anyone else in mind who could help?
,
Mar 15 2017
i know i've talked to people about this issue before, but i can't find a bug about it. the issue isn't limited to kernel crashes ... version information is collected when we go to upload, so all crashes queued from an older version will now be posted with the new version. what we should do: - whenever we collect a crash, we should load the version info up and save it in the output meta data (which goes into the spool) - when crash_sender runs, it should pull the version info from there and not from lsb-release/os-release (although we'd keep the fallback logic for both migrating existing reports and for sanity sake) - when it comes to collecting kernel crashes, i had talked to the update team about having a way to report the previous info. but thinking back, and about how much info we want to scrape, it's probably better we just take care of it ourselves. we'd need to mirror /etc/lsb-release and /etc/os.release* into /var so that the kernel collector could pull from that instead. it wouldn't be 100% accurate, but it should be more than enough for our needs.
,
Mar 17 2017
Ah, I guess the batching makes it more applicable to everyone (not just kernel). I know the kernel is the biggest hit because the kernel _often_ changes just after a crash whereas Chrome doesn't too often... ...but sure, we should make sure we fix it for evryone.
,
Apr 4 2017
,
Apr 4 2017
Looks like a good starter bug
,
Apr 5 2017
I'll tackle this one.
,
Apr 12 2017
,
Apr 21 2017
,
May 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/011533f1caad1a00234970d920c5f3996ff5f5d0 commit 011533f1caad1a00234970d920c5f3996ff5f5d0 Author: Benjamin Gordon <bmgordon@chromium.org> Date: Wed May 03 05:50:27 2017 crash: Save system version files for crash reporting When crash data is uploaded, version info is pulled from the system. If the system version has changed from when the crash happened (e.g. a reboot into a new system after a kernel crash) then this information will be wrong. To avoid this, cache /etc/lsb-release and /etc/os-release in /var/spool/crash at boot and read version info from there instead. BUG= chromium:590757 TEST=Forced crashes on a link device. Change-Id: I31e889559a20392cdeb23f6a29002d9fdb8fb0f0 Reviewed-on: https://chromium-review.googlesource.com/473608 Commit-Ready: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> [modify] https://crrev.com/011533f1caad1a00234970d920c5f3996ff5f5d0/crash-reporter/crash_reporter.cc [modify] https://crrev.com/011533f1caad1a00234970d920c5f3996ff5f5d0/crash-reporter/unclean_shutdown_collector.cc [modify] https://crrev.com/011533f1caad1a00234970d920c5f3996ff5f5d0/crash-reporter/kernel_warning_collector.cc [modify] https://crrev.com/011533f1caad1a00234970d920c5f3996ff5f5d0/crash-reporter/kernel_collector.cc [modify] https://crrev.com/011533f1caad1a00234970d920c5f3996ff5f5d0/crash-reporter/udev_collector_test.cc [modify] https://crrev.com/011533f1caad1a00234970d920c5f3996ff5f5d0/crash-reporter/unclean_shutdown_collector.h [modify] https://crrev.com/011533f1caad1a00234970d920c5f3996ff5f5d0/crash-reporter/crash_collector_test.cc [modify] https://crrev.com/011533f1caad1a00234970d920c5f3996ff5f5d0/crash-reporter/ec_collector_test.cc [modify] https://crrev.com/011533f1caad1a00234970d920c5f3996ff5f5d0/crash-reporter/kernel_collector_test.cc [modify] https://crrev.com/011533f1caad1a00234970d920c5f3996ff5f5d0/crash-reporter/chrome_collector_test.cc [modify] https://crrev.com/011533f1caad1a00234970d920c5f3996ff5f5d0/crash-reporter/unclean_shutdown_collector_test.cc [modify] https://crrev.com/011533f1caad1a00234970d920c5f3996ff5f5d0/crash-reporter/crash_sender [modify] https://crrev.com/011533f1caad1a00234970d920c5f3996ff5f5d0/crash-reporter/crash_collector.cc [modify] https://crrev.com/011533f1caad1a00234970d920c5f3996ff5f5d0/crash-reporter/crash_collector.h
,
May 3 2017
Fixed! Woohoo! I'm assuming that M-60 is OK for this, but if TPMs are interested in trying to get this back to M-59 we could think about it. Remember that for this fix to work we need it in the _old_ build, so we'll get proper version info on the next crash after they have this fix.
,
May 3 2017
That's great!
,
Jan 22 2018
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 Deleted