1389502 - Outdated startup components from startupCache are used after clobber+build

Status: NEW

(Firefox Build System :: General, enhancement)

Description

[Julian Descottes [:jdescottes]]

(sorry about using Core/Untriaged, not sure where to create the Bug)

With specific STRs it's possible to make Firefox use outdated startup components even after a clobber + build.

STRs:

- ./mach clobber && ./mach build && ./mach run -P
- create a profile
- quit Firefox 
- modify devtools/shim/devtools-startup.js (which is registered as a commandline handler component)
  For instance add a `Services.prompt.alert(null, "test", "");` anywhere
- ./mach clobber && ./mach build && ./mach run -P
- select the profile created previously
- the new code added to devtools/shim/devtools-startup.js is not executed

Workarounds:
- on OSX, deleting ~/Library/Caches/Firefox/Profiles/*.$PROF/startupCache and restarting Firefox fixes the issue.
- doing a regular build without a clobber first also fixes the issue.

Comment 1

[Vlad Bacia-Mociran [:VladB]]

I don't have a vast experience with this but a possible related component may be Core :: Build Config. Perhaps there's someone with extensive knowledge on this area that might be able to help here.

Comment 2

[Nathan Froyd [:froydnj]]

This is similar to bug 1368699, but not quite the same.  I'm a little surprised that we're getting identical build ids for the two builds, and therefore considering the startup caches to be valid, since we're building them at different times.  Is that what you're seeing?

Comment 3

[Julian Descottes [:jdescottes]]

I assume we are talking about Services.appinfo.appBuildID. On two successive builds using the steps mentioned in the summary, I get the same result: 20170817231714

I should mention that I am using artifact builds, maybe that has something to do with this issue?

Comment 4

[Nathan Froyd [:froydnj]]

(In reply to Julian Descottes [:jdescottes] from comment #3)
> I assume we are talking about Services.appinfo.appBuildID. On two successive
> builds using the steps mentioned in the summary, I get the same result:
> 20170817231714

This is a correct assumption--my apologies for not being clearer!

> I should mention that I am using artifact builds, maybe that has something
> to do with this issue?

Ah!  That's an important piece of information, yes.  We base the need to purge the startup cache on the compiled code, but for artifact builds, the compiled code looks like it never changes, so we'd always think the startup cache is good.

I'm starting to think we should just set MOZ_PURGE_CACHES:

http://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#4168

or pass -purgecaches all the time from ./mach run, and have a special option to turn *off* purging the cache.  Or maybe just always purge the caches for artifact builds, since we won't have the buildid changing in scenarios like comment 0.  gps, WDYT?

Comment 5

[Gregory Szorc [:gps]]

Other people have been asking for `mach run` to purge caches by default as well.

Honestly, I'm not sure what exactly the caches are for. If they are meant to speed up startup for end-user installs and don't make much sense for developers (unless you are testing startup perf or something), then it sounds to me like the caches should be disabled by default for `mach run` and we should offer a command argument to re-enable them.

The main concern with disabling the caches is then local processes diverge from end-user a bit and we lose some developer coverage over the startup caches.