Way to determine Chrome version without running the Chrome binary?

[Ian Barkley-Yeung]

Is there a way to determine the Chrome version without invoking chrome (that is, without relying on the --version or --product-version argument)?

This is specifically on ChromeOS, so the Windows .rc stuff won't work.

Right now, during ChromeOS crash reporting, we run chrome just to get a chrome version (https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform2/crash-reporter/arc_util.cc;l=191;drc=a3c61bdb78ad8c2cc6f7790e26971c1844da6e78). This seems less than ideal. Plus, my new pre-crashpad-crash-capture system would like to get the Chrome version, but since the system is specifically designed to capture very early crashes, I don't want to invoke chrome even with --product-version.

If there is no current way, would anyone object to adding a simple text file in the /opt/google/chrome directory with the contents of //chrome/VERSION ?

Thanks,

Ian

[Brian Geffon]

It's not the same values that are in /etc/lsb-release?

CHROMEOS_RELEASE_DESCRIPTION=14836.0.0 (Official Build) dev-channel betty test
CHROMEOS_RELEASE_BRANCH_NUMBER=0
CHROMEOS_RELEASE_BUILD_NUMBER=14836
CHROMEOS_RELEASE_CHROME_MILESTONE=104

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
> ---
> You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/fa7d7224-5a66-4362-a2fb-832a68ea1b71n%40chromium.org.

[Ian Barkley-Yeung]

No, that's the ChromeOS version. I'm looking for the Chrome version, like 102.0.5005.75

> To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[Mike Frysinger]

doesn't seem like for the early crash system the Chrome version matters at all, so if it was skipped/ignored, it shouldn't cause issues.

easiest thing would probably be to have the Chrome build include a supplemental json file that you could load.  while ash chrome & lacros-in-rootfs chrome could have that info stuffed by the CrOS build, lacros-in-dlc wouldn't, so we'd still need the info exported to access easily.  (i know the DLC itself will have metadata, but having a single method for grabbing the ver would simplify things i think.)

-mike

On Thu, Jun 9, 2022 at 2:34 PM Ian Barkley-Yeung <i...@chromium.org> wrote:

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Mike Frysinger]

is Chrome reproducible yet ?  otherwise there's going to be a ton of mappings here.

-mike

On Thu, Jun 9, 2022 at 3:33 PM Joshua Peraza <jpe...@google.com> wrote:

If you had a separate mapping from build-ID to chrome version number, you could do `readelf --notes chrome`.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAAbOScmOESWdbL7YZRqnW3U_Da-KHgkMtk%3D2o5Pvd-Rr-e6MpA%40mail.gmail.com.

[Mike Frysinger]

i almost suggested that, but seemed like a metadata json file would be easier to extend & parse.  having to parse ELF headers & extract specific fields doesn't feel like a good ABI.  i'm comfortable with it generally speaking, but i'm not normal :p.

-mike

On Thu, Jun 9, 2022 at 3:42 PM Joshua Peraza <jpe...@google.com> wrote:

Or directly supplly the chrome version into a note?

[Mike Frysinger]

sure, but I think we already reasonably have to contend with the fact that Chrome is not a single file, and making sure they're all installed together in order for things to work is a requirement.

if Chrome folks wanted to commit to a flexible ABI, then maybe that would change things. like moving relevant data to a compiled in json/protobuf/whatever that used a stable note name and all Chrome internal logic also used that data store directly.

but I'm just back seat designing here and certainly am not volunteering to do the actual work :).

-mike

On Thu, Jun 9, 2022, 15:55 Joshua Peraza <jpe...@google.com> wrote:

I would think the main advantage would be no risk of mismatched/missing metadata file.

[sL1pKn07 SpinFlo]

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAAbOSc%3DRu%3DAV6ePANQwvE1YT_7w3Wu%2BTP47hRLSjwznLv_dewQ%40mail.gmail.com.

└───╼  strings /usr/lib/chromium-dev/chromium-dev |grep -E "^[0-9][0-9][0-9]\.[0-9]\.[0-9][0-9][0-9][0-9]\.[0-9]" | tail -n1
104.0.5083.0

 

[Mike Frysinger]

`strings` is a development-only tool that we don't ship on CrOS, and blindly grepping the binary leads to obvious duplicates & false-positives, nor is order of results guaranteed/stable in any way.  and having to scan O(100MB) of data to find ~10 bytes feels wrong.

you also really want to use `-a` to make sure the entire file is actually scanned.

also that regex doesn't match all valid Chrome versions ;).

things that seem so simple on their face aren't always unfortunately.

-mike

[Joshua Peraza]

Or directly supplly the chrome version into a note?

On Thu, Jun 9, 2022 at 12:36 PM Mike Frysinger <vap...@chromium.org> wrote:

[Joshua Peraza]

I would think the main advantage would be no risk of mismatched/missing metadata file.

[Joshua Peraza]

If you had a separate mapping from build-ID to chrome version number, you could do `readelf --notes chrome`.

On Thu, Jun 9, 2022 at 11:57 AM Mike Frysinger <vap...@chromium.org> wrote:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAAbOScmOESWdbL7YZRqnW3U_Da-KHgkMtk%3D2o5Pvd-Rr-e6MpA%40mail.gmail.com.

[sL1pKn07 SpinFlo]

Hi

before posting the grep syntax, i know what version of the chrome/ium i have installed, and then i crafted the regex syntax for that result. if you see, in the end i posted `tail -n1`, because if not, i get the result twice

└───╼  strings /usr/lib/chromium-dev/chromium-dev |grep -E "^[0-9][0-9][0-9]\.[0-9]\.[0-9][0-9][0-9][0-9]\.[0-9]"

104.0.5083.0
104.0.5083.0

this is working in chrome and chromium, but i only tested in linux, probably windows or mac get different results (or CrOS)

adding -a do nothing different (my build is with 'is_component_build=true' so the output taked less than 1sec to get the output)

and yes, versions low that 99M not work

greetings

[Ian Barkley-Yeung]

> doesn't seem like for the early crash system the Chrome version matters at all, so if it was skipped/ignored, it shouldn't cause issues.

While the crash report will still make it to our crash database, many of the tools people use to query that database for Chrome_ChromeOS crashes are based on Chrome version. (For instance, we have a lot of process around "What are the major crashes for the latest dev release?" "What are the major crashes for the latest beta release?") If the version number is the ChromeOS version, those crashes will not appear in the tools.

> easiest thing would probably be to have the Chrome build include a supplemental json file that you could load.  while ash chrome & lacros-in-rootfs chrome could have that info stuffed by the CrOS build, lacros-in-dlc wouldn't, so we'd still need the info exported to access easily.  (i know the DLC itself will have metadata, but having a single method for grabbing the ver would simplify things i think.)

Yes, that's generally what I'm thinking, but I wanted to make sure there wasn't an existing way before I added new code / files / BUILD rules.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[Mike Frysinger]

your new regex is still insufficient for existing versions

my point is that your "simple approach" is not actually that simple or robust, and can't really be made as such.  so it's not worth pursuing beyond minor nerd sniping.

-mike

[Mike Frysinger]

On Thu, Jun 9, 2022 at 5:21 PM Ian Barkley-Yeung <i...@chromium.org> wrote:

> doesn't seem like for the early crash system the Chrome version matters at all, so if it was skipped/ignored, it shouldn't cause issues.

While the crash report will still make it to our crash database, many of the tools people use to query that database for Chrome_ChromeOS crashes are based on Chrome version. (For instance, we have a lot of process around "What are the major crashes for the latest dev release?" "What are the major crashes for the latest beta release?") If the version number is the ChromeOS version, those crashes will not appear in the tools.

why would there ever be a Chrome_ChromeOS early report ?  that is only used for Chrome processes, and by design, there are no Chrome processes in the early boot.

-mike

> easiest thing would probably be to have the Chrome build include a supplemental json file that you could load.  while ash chrome & lacros-in-rootfs chrome could have that info stuffed by the CrOS build, lacros-in-dlc wouldn't, so we'd still need the info exported to access easily.  (i know the DLC itself will have metadata, but having a single method for grabbing the ver would simplify things i think.)

Yes, that's generally what I'm thinking, but I wanted to make sure there wasn't an existing way before I added new code / files / BUILD rules.

On Thursday, June 9, 2022 at 11:58:01 AM UTC-7 Mike Frysinger wrote:

doesn't seem like for the early crash system the Chrome version matters at all, so if it was skipped/ignored, it shouldn't cause issues.

easiest thing would probably be to have the Chrome build include a supplemental json file that you could load.  while ash chrome & lacros-in-rootfs chrome could have that info stuffed by the CrOS build, lacros-in-dlc wouldn't, so we'd still need the info exported to access easily.  (i know the DLC itself will have metadata, but having a single method for grabbing the ver would simplify things i think.)

-mike

On Thu, Jun 9, 2022 at 2:34 PM Ian Barkley-Yeung <i...@chromium.org> wrote:

Is there a way to determine the Chrome version without invoking chrome (that is, without relying on the --version or --product-version argument)?

This is specifically on ChromeOS, so the Windows .rc stuff won't work.

Right now, during ChromeOS crash reporting, we run chrome just to get a chrome version (https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform2/crash-reporter/arc_util.cc;l=191;drc=a3c61bdb78ad8c2cc6f7790e26971c1844da6e78). This seems less than ideal. Plus, my new pre-crashpad-crash-capture system would like to get the Chrome version, but since the system is specifically designed to capture very early crashes, I don't want to invoke chrome even with --product-version.

If there is no current way, would anyone object to adding a simple text file in the /opt/google/chrome directory with the contents of //chrome/VERSION ?

Thanks,

Ian

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Ian Barkley-Yeung]

> why would there ever be a Chrome_ChromeOS early report ?  that is only used for Chrome processes, and by design, there are no Chrome processes in the early boot.

Early in Chrome's startup. Prior to this work, if Chrome browser crashed early in its startup sequence (before crashpad was initialized), the crash would be lost completely. Now, on ChromeOS, it will be captured using UserCollector. But with the wrong version number.

Not early in ChromeOS's boot sequence. 

[Satoru Takabayashi]

/etc/lsb-release already contains the ash-chrome milestone number (ex. 104), so I thought it'd be useful to add the version number as well. Would it be difficult?

If that's difficult, perhaps we could generate a JSON file or something from chromeos-chrome.ebuild using $CHROME_VERSION.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAPHpbpQ%3DwH2YKFiE5ZNr5rpqshjfX25PqGHZ4oC%2BfM47PpQi%2Bw%40mail.gmail.com.

[Ian Barkley-Yeung]

Just to wrap up the thread: Lacros is already producing a metadata.json file:

localhost ~ # cat /run/lacros/metadata.json
{
  "content": {
    "version": "104.0.5106.0"
  },
  "metadata_version": 1
}
localhost ~ #

Plan is to add an identical file for ash-Chrome (Thanks Sven); then I can parse whatever metadata.json file I find next to the Chrome binary.

[Sven Zheng]

The primary cl: crrev.com/c/3703711. Feel free to comment.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAPHpbpQFRACOAuirLY73qkctdqPBD-M7Ncukeg2DufW6THkGww%40mail.gmail.com.

[Mike Frysinger]

that file format is for imageloader.  i'm not sure trying to use it outside imageloader context is a good idea.

-mike