All users were logged out of Bugzilla on October 13th, 2018
Created attachment 597856 [details] error message Todays nightly went paranoid on me. Refuses to let me see any ssl site.
The only thing possibly relevant in the error: Timestamp: 2/16/2012 9:16:06 AM Error: [Exception... "null" nsresult: "0x805a1ff3 (<unknown>)" location: "JS frame :: resource:///modules/services-sync/resource.js :: Channel_onStopRequest :: line 578" data: no] Source File: resource:///modules/services-sync/resource.js Line: 578
Looks like something went wrong during app-update. My build consistently fails to do ssl, even with a new profile. Here is my firefox dir: http://dl.dropbox.com/u/5961467/firefox.ssl-screwed.zip It's off the profiling branch, so one can get useful symbols for it easily.
See comment 2. Do bbondy and rs have any ideas here?
Component: Networking: HTTP → Security: PSM
QA Contact: networking.http → psm
I compared the installer for this build, the screwed up install, and the last-update.log and like the partial mar didn't contain all of the new files for this build. This is likely due to a mar generation error so cc'ing a couple of releng people.
$ diff -r firefox-x64-profiling firefox-screwed Only in firefox-screwed: active-update.xml Only in firefox-screwed/uninstall: uninstall.update Only in firefox-screwed: updates Only in firefox-screwed: updates.xml Files firefox-x64-profiling/freebl3.chk and firefox-screwed/freebl3.chk differ Files firefox-x64-profiling/nssdbm3.chk and firefox-screwed/nssdbm3.chk differ Files firefox-x64-profiling/omni.ja and firefox-screwed/omni.ja differ Files firefox-x64-profiling/softokn3.chk and firefox-screwed/softokn3.chk differ So, it seems like there may be some problem with the updater, since I expect that all four of the differing files to be the same. However, I am able to reproduce this particular bug even on a clean Nightly 2012-02-15 Win64 profiling branch build. However, normal mozilla-central Win32 and Win64 builds work fine, as do Win32 profiling branch builds. So, this particular bug might be unrelated to the above-noted updater issue, and instead it might be a problem with the Win64 profiling branch build config.
I can confirm that the updater has nothing to do this this. I accidentally grabbed a 32bit profiling build to compare against. 64bit profiling builds exhibit the issue, all others do not.
Ehsan, do you have any ideas on what might cause the builds to diverge?
bah... I was comparing with an x86 installer. :(
Ehsan, how does one push a build to try to get something similar to the profiling build?
Summary: Nightly rejecting SSL certs for bugzilla/google, etc → Nightly rejecting SSL certs with sec_error_untrusted_issuer only on Win64 profiling branch builds
Issues with the updater (i.e. why those 4 files are different) mentioned above are now part of bug 727982
(In reply to Brian Smith (:bsmith) from comment #11) > Issues with the updater (i.e. why those 4 files are different) mentioned > above are now part of bug 727982 Just to be clear: there's no issue with the _updater_ when files between a ZIP and a MAR differ. ZIPs and MARs are staged differently and due to build system limitations this means that NSS .chk files and omni.ja will differ.
Some observations: - I noticed this problem also happens on elm x64 builds. - I noticed that if you replace xul.dll with an m-c version from the same day for both the Profiling and Elm, it fixes the problem and updates are found. - Changing app.update.log to true and running firefox with -console produces this log: download | new post *** AUS:SVC UpdateManager:_loadXMLFileIntoArray: XML file does not exist *** AUS:SVC getLocale - getting locale from file: resource://app/update.locale, locale: en-US *** AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3 /Firefox/13.0a1/20120222174716/WINNT_x86_64-msvc/en-US/nightly-elm/Windows_NT%20 126.96.36.199%20(x64)/default/default/update.xml?force=1 *** AUS:SVC gCanCheckForUpdates - able to check for updates *** AUS:SVC Checker:checkForUpdates - sending request to: https://aus3.mozilla.o rg/update/3/Firefox/13.0a1/20120222174716/WINNT_x86_64-msvc/en-US/nightly-elm/Wi ndows_NT%188.8.131.52%20(x64)/default/default/update.xml?force=1 *** AUS:SVC Checker:onError - request.status: 2153390067 *** AUS:SVC getStatusTextFromCode - transfer error: Update XML file malformed (2 00), default code: 200
Duplicate of this bug: 739325
Sorry for my lag on this. To get something similar to the profiling branch from the try server, there are two ways: 1. Just add --enable-profiling to the mozconfig. 2. Clone http://hg.mozilla.org/projects/profiling and push to try from there. I highly recommend the first approach.
I don't think there's anything actionable here (that profiling project looks defunct anyway - the last change was in 2013).
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.