Closed Bug 586350 Opened 12 years ago Closed 12 years ago

Update to 08/11 nightly produces a build that won't startup

Categories

(Toolkit :: Application Update, defect)

defect
Not set
blocker

Tracking

()

RESOLVED FIXED
mozilla2.0b4
Tracking Status
blocking2.0 --- beta4+

People

(Reporter: mossop, Assigned: benjamin)

References

Details

Attachments

(1 file)

When doing an automatic update from 08/10 to 08/11 nightlies the new build does not start. This is true on all platforms. We've filed bug 586345 to get the builds pulled from the update system but need to figure out exactly where the problem lies.
blocking2.0: --- → ?
Downloading the nightly manually and installing gives you a workable build so there is definitely something wrong with the update system (client, mar or server) here.
Blocking beta 4 at least for investigation (we can re-triage after that).  Need to make sure we don't hit this on beta3 to beta4 updates.
blocking2.0: ? → beta4+
I'd really like somebody to compare the broken update with a fresh install and see if the file lists are the same. If they are, diff the contents, although that might be more complex.
I'm sure others have crash reports, but for the record, here's what I got in my crashes from this: http://crash-stats.mozilla.com/report/index/bp-aa9ab17d-1d89-43e0-9235-e88102100811
For help in track-down I'm running an hourly build built on cset:

http://hg.mozilla.org/mozilla-central/rev/0c581111e40b

The nightly for today is built on cset:

20100811063038 ba956b17d834 

The only chekin was bug https://bugzilla.mozilla.org/show_bug.cgi?id=581576
and a 'nit' chnage in that bug for the nightly build.  Later this bug was backed out due to massive orange.  Is this the reason the nightly's won't start up - bug https://bugzilla.mozilla.org/show_bug.cgi?id=581576
(In reply to comment #5)
> For help in track-down I'm running an hourly build built on cset:
> 
> http://hg.mozilla.org/mozilla-central/rev/0c581111e40b
> 
> The nightly for today is built on cset:
> 
> 20100811063038 ba956b17d834 
> 
> The only chekin was bug https://bugzilla.mozilla.org/show_bug.cgi?id=581576
> and a 'nit' chnage in that bug for the nightly build.  Later this bug was
> backed out due to massive orange.  Is this the reason the nightly's won't start
> up - bug https://bugzilla.mozilla.org/show_bug.cgi?id=581576

I don't think that is useful. We know that if you download the nightly build it works so it is some part of the update process that is broken.
Got nearly dozens of crash reports with the same signature. I have 10+ tabs in previous session and D2D is enabled.

http://crash-stats.mozilla.com/report/index/bp-d7af1e9b-f18c-42b3-ab94-ec0452100811

nsRefPtr<mozilla::net::HttpChannelParentListener>::~nsRefPtr<mozilla::net::HttpChannelParentListener>() | _cairo_d2d_device::~_cairo_d2d_device()
Caused by bug 579178

Differences
.\chrome.manifest only in Minefield.good
.\chrome\browser.manifest only in Minefield.bad
.\chrome\en-us.manifest only in Minefield.bad
.\chrome\pippki.manifest only in Minefield.bad
.\chrome\toolkit.manifest only in Minefield.bad
.\components\browser.manifest only in Minefield.bad
Blocks: 579178
Bah. I purposely waited to update removed-files for no-longer-needed manifests, but I didn't notice that there was a very old rule to remove a root chrome.manifest file.
Assignee: nobody → benjamin
Status: NEW → ASSIGNED
Attachment #464898 - Flags: review?(robert.bugzilla)
Attachment #464898 - Flags: review?(robert.bugzilla) → review+
Duplicate of this bug: 586343
http://hg.mozilla.org/mozilla-central/rev/7d145abc669c
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b4
Duplicate of this bug: 586257
Duplicate of this bug: 586498
You need to log in before you can comment on or make changes to this bug.