https://bugs.chromium.org/p/chromium/issues/detail?id=761579#c14
points at code/conditions that might lead to kernel crashes not getting reported because the ramoops file wasn't created.
The goal is, if crash reporting is enabled by the user, we should _always_ report _something_ if we can detect any semi-valid contents in the dmesg buffer.
I think the only area we can NOT report crashes is if something causes power to fail - since the reboot will look exactly like a cold start. E.g. EC shutdowns will likely not get reported ever.
1) kernel should either create a different file OR be more lenient in creating the ramoops file should some part of the kmsg header be corrupted. See ~/trunk/src/third_party/kernel/v4.4/fs/pstore/ram.c :
262 header_length = ramoops_read_kmsg_hdr(persistent_ram_old(prz),
263 &record->time,
264 &record->compressed);
265 /* Clear and skip this DMESG record if it has no valid header */
266 if (!header_length) {
267 persistent_ram_free_old(prz);
268 persistent_ram_zap(prz);
269 prz = NULL;
270 }
2) kernel_collector.cc needs to look for and possibly handle these potentially corrupted kernel crash dumps carefully.
153 bool KernelCollector::LoadParameters() {
154 // Discover how many ramoops records are being exported by the driver.
155 size_t count;
156
157 for (count = 0; count < kMaxDumpRecords; ++count) {
158 FilePath record_path = GetDumpRecordPath(kDumpRecordDmesgName,
159 kDumpDriverRamoopsName, count);
160
161 if (!base::PathExists(record_path))
162 break;
163 }
164
165 records_ = count;
166 return (records_ > 0);
167 }
or if the stripped message buffer has no contents, then we don't report it either:
609 StripSensitiveData(&kernel_dump);
610 if (kernel_dump.empty()) {
611 return false;
612 }
We should report something in both cases.
Comment 1 by oka@chromium.org
, Nov 14 2017