borisv, can you see if there is anything actionable here?

mehmet@, can you run the ksdiagnostics command and attach the generated .zip file or send it to borisv@chromium.org and norberg@chromium.org?

~/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/ksdiagnostics

If the file is not there, try removing the tilde and run it again.

Error 77 in com.google.UpdateEngine.CommonErrorDomain is kKSCommonPropertyListSerializationDeserializeError, which suggests that we tried to read a .plist file and found an unexpected 'Ä' character in the file. Investigating. I suspect we have ticket management logic somewhere that is not locale-robust, but this is just an early guess, I'm tracking down exactly where we may emit that error.

The ksdiagnostics call will help my investigation, so please run it if at all practical. I've developed a vague suspicion but diagnostics will help narrow it down. The error message doesn't contain as much context information as it needs (that's on my radar longer-term).

Today I received the same error message:

Fehler bei der Aktualisierung (Fehler: 12)

Fehlerdetails:
2017-06-29 16:56:47.110 GoogleSoftwareUpdateAgent[495/0x700002fc1000] [lvl=3] +[NSPropertyListSerialization(KSPropertyListSerializationErrorAdditions) containerFromData:format:error:] Unexpected character Ä at line 1 [com.google.UpdateEngine.CommonErrorDomain:77 - 'NSPropertyListSerialization+Error.m:79']
Version 61.0.3143.0 (Offizieller Build) canary (64-Bit)

I will run ksdiagnostics and will send it to borisv@ and norberg@.

Just for your Info: We had a similar error some years ago:  issue 225352 .

As far as I can tell from the diagnostics, your updater has a valid ticket, a user-scope install of Keystone (no system-scope Keystone), and has been successfully checking for updates and correctly processing no-update responses, which Chrome status is erroneously interpreting as an error, and therefore displaying the first thing it can find on stderr in Keystone's output.

Meanwhile, Keystone is unable to load one or more of its metrics stores. This does not prevent it from getting updates, but does interfere with the correct functioning of Keystone. (These metrics stores are not captured in KSDiagnostics.) OS-level plist parsing is failing, and we can only speculate how the plist became unparseable, since we know only that it contains an unexpected 'Ä', not how it got there. The load/store logic is using a relatively opaque OSX library, so Keystone doesn't have insight into what isn't translating correctly. However, it could use the presence of an error as a reason to reset the metrics store, which would bring it back to a usable state.

I intend to:
* Use the supported functions for plist load/store instead of the deprecated ones - parsing may quietly succeed if some change in the correct function was not back-ported to the deprecated one
* Respond to a failure to load a metrics store by resetting the metrics store (because whatever it has doesn't work anyway, so a fresh one can't be worse)

Interim workaround:
Ignore the message; it is spurious.

Related issues:
"Error 12" in general is non-diagnostic and represents a wide variety of errors and non-errors. This is a consequence of Keystone doing a less-than-stellar job of reporting errors in a machine-readable format. I am in the middle of a large project to, among other things, fix this. Since this is a "updates worked okay, there just weren't any" kind of error 12, it will go away as part of this work.

norberg@ Thank you very much for your feedback. Okay, I'll follow your interim workaround.

Mehmet, would you be able to attach the contents of this file: ~/Library/Google/GoogleSoftwareUpdate/CountingMetrics.plist

I am curious why we failed to read it - the updater uses plists in many places, so we should understand issues with processing such files.

borisv@: Please find attached the CountingMetrics.plist

Deleted: CountingMetrics.plist 1.4 KB

CountingMetrics.plist 1.4 KB View Download