Closed Bug 1258375 Opened 9 years ago Closed 9 years ago

Upgrade Firefox 48 to NSS 3.24

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Version:
48 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox48 --- fixed
firefox49 --- fixed

People

(Reporter: KaiE, Assigned: KaiE)

References

(Blocks 1 open bug)

Details

(Whiteboard: [psm-assigned])

Attachments

(5 files, 5 obsolete files)

1258375-symbols-v1.patch
702 bytes, patch
mt
: review+
KaiE
: checkin+
Details | Diff | Splinter Review
add_freebl_priv_2 fix (hopefully) the last of Mikes comments
3.50 KB, patch
glandium
: review+
KaiE
: checkin+
Details | Diff | Splinter Review
update-to-nss-3.24-beta7.txt
44 bytes, text/plain
franziskus
: review+
KaiE
: checkin+
Details
NSS_3_24_RC0.txt
41 bytes, text/plain
KaiE
: review+
lizzard
: approval-mozilla-aurora+
KaiE
: checkin+
Details
1258375-configure.patch
796 bytes, patch
mt
: review+
dveditz
: approval-mozilla-beta+
Details | Diff | Splinter Review
Firefox 48 should use NSS 3.24, which is currently being worked on.
Previous try didn't work, new exported symbols required. Here's the next try build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=51a88fc9bfa2
Assignee: nobody → kaie
Attachment #8732959 - Flags: review?(martin.thomson)
Depends on: 1181814
Comment on attachment 8732959 [details] [diff] [review] 1258375-symbols-v1.patch Review of attachment 8732959 [details] [diff] [review]: ----------------------------------------------------------------- r+, including the rest of NSS as well.
Attachment #8732959 - Flags: review?(martin.thomson) → review+
Kai, you might want to just land the 4th patch on bug 1253160, which does the same thing.
Bob, we really need to get this fixed so that we can start testing the latest TLS 1.3 in Firefox. Can we set a target of end of day Tuesday for either having this fixed or backed out?
Flags: needinfo?(rrelyea)
ekr, I'm not sure what 'this' is in your statement. I presume you don't mean bug 1258375 but some other bug? (I'm working from home today and off tomorrow, so we're talking monday).
Flags: needinfo?(rrelyea)
Yes, my understanding is that this is blocked on https://bugzilla.mozilla.org/show_bug.cgi?id=1181814
Thanks eric, that's what I needed to know. bob
Attached patch add_freebl_priv.patch (obsolete) — — Splinter Review
I've verified that adding the link to freeblpriv fixed the package issues. Here's a patch that should cause the link to be created automatically, but I'm still testing. bob
Attachment #8735664 - Flags: review?(martin.thomson)
Attached patch add_freebl_priv.patch (obsolete) — — Splinter Review
Oops previous patch didn't included all the changed files. still haven't finished testing (builds are still running). bob
Attachment #8735664 - Attachment is obsolete: true
Attachment #8735664 - Flags: review?(martin.thomson)
Attachment #8735665 - Flags: review?(martin.thomson)
Comment on attachment 8735665 [details] [diff] [review] add_freebl_priv.patch This still doesn't fix the link creation (sigh). I'll look again tomorrow. bob
Attachment #8735665 - Flags: review?(martin.thomson)
Bob, If you need someone to look at this, I recommend Mike Hommey (mh+mozilla@glandium.org), who knows the build integration for NSS much better than I could.
Thanks martin. I'm still trying to find out where the links are created. Mike, do you know what part of the build system creates the links between libraries in obj-*/dist/lib to obj-*/dist/bin in the package step?
Flags: needinfo?(mh+mozilla)
Never mind, I figured it out. I'll have a patch to review shortly.
Flags: needinfo?(mh+mozilla)
This will allow NSS to be picked up. bob
Attachment #8735665 - Attachment is obsolete: true
Attachment #8735921 - Flags: review?(mh+mozilla)
Attachment #8735921 - Flags: review?(martin.thomson)
Comment on attachment 8735921 [details] [diff] [review] Add freeblpriv for Linux. On Linux mozilla only needs freeblpriv, not freebl. New try build that includes this patch: https://treeherder.mozilla.org/#/jobs?repo=try&revision=0325e517215a
Note the PREVIOUS, earlier try build had an additional failure, see red X on OSX. > https://treeherder.mozilla.org/#/jobs?repo=try&revision=51a88fc9bfa2 Eric offered to have a look.
Hmm, when I click on the X it only shows a test case failure that was an intermittent failure. I see the same failure on windows, but the X isn't red. I must be reading it wrong.
Both Windows and OSX showed an error code SSL_ERROR_ILLEGAL_PARAMETER_ALERT Red failures usually mean a build bustage, while orange means a test failure. I don't know why that OSX one is red. Maybe all we have are regular intermittent failures, combined with an infrastructure failure on OSX?
It looks to me like we may have changed the error code we return. Investigating.
Comment on attachment 8735921 [details] [diff] [review] Add freeblpriv for Linux. On Linux mozilla only needs freeblpriv, not freebl. Review of attachment 8735921 [details] [diff] [review]: ----------------------------------------------------------------- I'm not really qualified to test the premise here (that only freeblpriv is needed on linux), but if we assume that's true, then this appears to be correct.
Attachment #8735921 - Flags: review?(martin.thomson) → review+
Bob's patch worked. But we have several tests that are failing at the PSM level.
Re: failures, this is the offending line: https://dxr.mozilla.org/mozilla-central/rev/d5d53a3b4e50b94cdf85d20690526e5a00d5b63e/security/manager/ssl/tests/unit/test_weak_crypto.js#150-152 I really wish that people would put one assertion per line.
Those dev tools tests look suspect also. I don't think that we can rule out any of the orange or red on that run, sadly.
Comment on attachment 8735921 [details] [diff] [review] Add freeblpriv for Linux. On Linux mozilla only needs freeblpriv, not freebl. Review of attachment 8735921 [details] [diff] [review]: ----------------------------------------------------------------- ::: b2g/installer/package-manifest.in @@ +821,5 @@ > @BINPATH@/@DLL_PREFIX@smime3@DLL_SUFFIX@ > @BINPATH@/@DLL_PREFIX@ssl3@DLL_SUFFIX@ > #endif > @BINPATH@/@DLL_PREFIX@softokn3@DLL_SUFFIX@ > +#if defined(XP_LINUX) XP_LINUX is defined on Android and gonk. IOW, this will break device images for b2g, since they won't have built freeblpriv3 per the rules in config/external/nss, where the test is OS_TARGET == Linux, which does *not* match Android and gonk (where it's Android). It it something that needs to be done for GNU/Linux only or for unices, more broadly? ::: config/external/nss/Makefile.in @@ +68,5 @@ > endif > endif > > +ifeq ($(OS_TARGET),Linux) > +HAVE_FREEBL_LIBS = 0 ifdef HAVE_FREEBL_LIBS will still hit if you set a value.
Attachment #8735921 - Flags: review?(mh+mozilla) → review-
> It it something that needs to be done for GNU/Linux only or for unices, more broadly? So it seems the test in nss is about FREEBL_LOWHASH. And we're setting FREEBL_LOWHASH=1 in a OS_TARGET=Linux block. The HAVE_FREEBL_LIBS and HAVE_FREEBL_LIBS_PRIV variables should be grouped with that.
Bob, would you be able to update the bug according to Mike's suggestions?
Flags: needinfo?(rrelyea)
Bob, could you please provide an updated patch, that gets r+ from Mike by Wednesday? If not, we need to back out bug 1181814.
Mike, FYI: Bob had explained the purpose of libfreebl3 in bug 1181814 comment 41. Only platforms where glibc uses softokn need the new freebl3priv handling. Should an updated patch check for "is linux and is not android and is not b2g/gonk" ?
The one question is does mozilla set FREEBL_LOWHASH on android and gonk? I think the answer is yes since this patch actually built just fine for android in our tests, so Mike should we turn that off for Android/gonk (it's not needed on those platforms) or leave it as is. I think If I don't try to do both I'll actually break Android/gonk. > So it seems the test in nss is about FREEBL_LOWHASH. And we're setting FREEBL_LOWHASH=1 in a OS_TARGET=Linux > block. The HAVE_FREEBL_LIBS and HAVE_FREEBL_LIBS_PRIV variables should be grouped with that. I can update the patch with this fix.
Flags: needinfo?(rrelyea)
Just to be clear, before I submit a new patch I'd like mike to weigh in on whether or not we should turn FREEBL_LOWHASH off as part of this patch for android and gonk, or if we should keep the 'naked' XP_LINUX in the package sections. bob
Flags: needinfo?(mh+mozilla)
Bob, if the alternative approaches are simple, and because Mike is in a different timezone: Would you consider to attach both patch variants, so Mike could pick the one he prefers? That would allow us to proceed faster.
Flags: needinfo?(rrelyea)
I was thinking of doing that anyway... yes.
Flags: needinfo?(rrelyea)
Attached patch add_freebl_priv_1.patch (obsolete) — — Splinter Review
This patch fixes HAVE_FREEBL_LIBS variable (was set to 0 should have been set empty) and the move FREEBL_LOWHASH flag to the common ifeq Linux block so that they are set together (since they go together). This still has the b2g patch (we can drop it and not affect the browser, but I think b2g needs it as long as we aren't checking specifically for android). I'll attach a separate option with explicitly turns these off for android and drops the b2g patch.
Attachment #8735921 - Attachment is obsolete: true
Attachment #8738003 - Flags: review?(mh+mozilla)
Attached patch add_freebl_priv.patch (obsolete) — — Splinter Review
This version attempts to include all of Mike's comments by preventing FREEBL_HASH on android to begin with. BTW note that in both patches, I had to use slight of hand to set the FREEBL_LOWHASH value because the DEFAULT_GMAKE_FLAGS get cleared later in the file so I couldn't just move the FREEBL_LOWHASH setting up. Instead I set an environment variable then have the environment variable get picked up when we are actually setting DEFAULT_GMAKE_FLAGS. I've tested both paths (Linux taken, Linux not taken) and saw that we successfully created libfreeblpriv or not depending. I have not tested the Android path.
Attachment #8738005 - Flags: review?(mh+mozilla)
Comment on attachment 8738003 [details] [diff] [review] add_freebl_priv_1.patch Try build (no tests) for this patch started here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=2d3487b29afe
Comment on attachment 8738005 [details] [diff] [review] add_freebl_priv.patch Try build (no tests) for this patch started here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=9c3b36e0ac82
Bob, thanks a lot for showing us our options in detail. Since Mike apparently doesn't have time right now, I'd like to say: - I believe you have addressed Mike's request for change, and I'm willing to give r=kaie on the patch - I personally have a preference to disable the FREEBL_LOWHASH on Android, since we don't need it. My suggestion is: - I'll mark the second patch r+ - I'll tag a newer BETA2, because our BETA1 is already two weeks old - I'll do a full try run of BETA2 with the second patch that disables Android - if the try run succeeds, and if Mike hasn't responded by tomorrow, I'll land that combination into m-c (inbound)
(In reply to Martin Thomson [:mt:] from comment #5) > Kai, you might want to just land the 4th patch on bug 1253160, which does > the same thing. No, that patch uses different names for the symbols. That patch uses the name "StackArena", but the actual code checked in to NSS uses the name "CheapArena".
(In reply to Kai Engert (:kaie) from comment #39) > > - I'll tag a newer BETA2, because our BETA1 is already two weeks old > > - I'll do a full try run of BETA2 with the second patch that disables Android Running here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=eee8da9278fe
(In reply to Kai Engert (:kaie) from comment #41) > Running here: > https://treeherder.mozilla.org/#/jobs?repo=try&revision=eee8da9278fe That was based on mozilla-inbound, which turned out to be a bad idea, because there's too much experimental code. I've restarted a try run based on mozilla-central, which should give us a cleaner result: https://treeherder.mozilla.org/#/jobs?repo=try&revision=9dc035f4e695
Comment on attachment 8738003 [details] [diff] [review] add_freebl_priv_1.patch Review of attachment 8738003 [details] [diff] [review]: ----------------------------------------------------------------- ::: b2g/installer/package-manifest.in @@ +830,3 @@ > #ifndef CROSS_COMPILE > +#if defined(XP_LINUX) > +@BINPATH@/@DLL_PREFIX@freeblpriv3.chk Note the .chk files could be entirely removed from this file. They don't matter in package-manifest.
Attachment #8738003 - Flags: review?(mh+mozilla) → review+
Comment on attachment 8738005 [details] [diff] [review] add_freebl_priv.patch Review of attachment 8738005 [details] [diff] [review]: ----------------------------------------------------------------- ::: config/external/nss/Makefile.in @@ +68,5 @@ > endif > endif > > +ifneq ($(OS_TARGET), Android) > +ifeq ($(OS_TARGET),Linux) if OS_TARGET is Linux, it's not Android, you don't need 2 conditionals here.
Attachment #8738005 - Flags: review?(mh+mozilla)
Comment on attachment 8738003 [details] [diff] [review] add_freebl_priv_1.patch Review of attachment 8738003 [details] [diff] [review]: ----------------------------------------------------------------- ::: b2g/installer/package-manifest.in @@ +821,5 @@ > @BINPATH@/@DLL_PREFIX@smime3@DLL_SUFFIX@ > @BINPATH@/@DLL_PREFIX@ssl3@DLL_SUFFIX@ > #endif > @BINPATH@/@DLL_PREFIX@softokn3@DLL_SUFFIX@ > +#if defined(XP_LINUX) Err, this still has the same problem: you make the build system create the lib on non-Android Linux and make it packaged on all-Linux-including-Android-and-B2G.
Attachment #8738003 - Flags: review+
Comment on attachment 8738005 [details] [diff] [review] add_freebl_priv.patch Review of attachment 8738005 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/installer/package-manifest.in @@ +765,5 @@ > ; meaning their .chk files are created there directly. > ; > #ifndef MOZ_SYSTEM_NSS > +#if defined(XP_LINUX) && !defined(ANDROID) > +@BINPATH@/@DLL_PREFIX@freeblpriv3@DLL_SUFFIX@ You're missing something like this in b2g/installer (there are desktop B2G builds)
Flags: needinfo?(mh+mozilla)
> if OS_TARGET is Linux, it's not Android, you don't need 2 conditionals here. Hmm I'm wondering why the previous try builds worked then, since Android does set XP_LINUX. > You're missing something like this in b2g/installer (there are desktop B2G builds) Are they builds that target the desktop? The only documentation I could find on B2G builds was that they were android, and they involved pulling some github repository. Is there a ./mach option to build b2g? bob
(In reply to Robert Relyea from comment #47) > > if OS_TARGET is Linux, it's not Android, you don't need 2 conditionals here. > > Hmm I'm wondering why the previous try builds worked then, since Android > does set XP_LINUX. Because none of your patches is touching mobile/android/installer/package-manifest.in? As for b2g, it's probably ignoring missing files in package-manifest.in, so the build would finish green, but the resulting archive would be useless because both freebl and freeblpriv are missing. > > You're missing something like this in b2g/installer (there are desktop B2G builds) > > Are they builds that target the desktop? The only documentation I could find > on B2G builds was that they were android, and they involved pulling some > github repository. Is there a ./mach option to build b2g? ac_add_options --enable-application=b2g should be enough.
> Err, this still has the same problem: you make the build system create the lib on non-Android Linux and make it > packaged on all-Linux-including-Android-and-B2G. Right, there were 2 patches: 1) don't build android with FREEBL_LOWHASH and then drop the package changes for android and B2G. 2) continue to build android with FREEBL_LOWHASH and don't drop the package changes. > Because none of your patches is touching mobile/android/installer/package-manifest.in? As for b2g, > it's probably ignoring missing files in package-manifest.in, so the build would finish green, but the > resulting archive would be useless because both freebl and freeblpriv are missing. I know the linux build fails when it tries to sign. I'm also pretty sure that the try builds actually runs tests on the binary. Maybe I'm wrong there. So to be clear, the change you are looking for is simply adding !(ANDROID) to browser and b2g package-manifests.in files with the XP_LINUX. bob
Attachment #8738003 - Attachment is obsolete: true
Attachment #8738005 - Attachment is obsolete: true
Attachment #8738298 - Flags: review?(mh+mozilla)
Attachment #8738298 - Flags: review?(mh+mozilla) → review+
Keywords: leave-open
Depends on: 1262768
(In reply to Wes Kocher (:KWierso) from comment #52) > I had to back this out for xperf failures like > https://treeherder.mozilla.org/logviewer.html#?job_id=25300309&repo=mozilla- > inbound This issue has been addressed in bug 1262768 by disabling the new tests by default. I'll land a new BETA5 which picks up that change.
Flags: needinfo?(kaie)
Try build https://treeherder.mozilla.org/#/jobs?repo=try&revision=6ce78628790c based on https://hg.mozilla.org/projects/nss/rev/4084aa2e0c3e and I really really hope it works this time. If it does, I'll tag that revision as beta6 and land into inbound. It not, I'll walk up the wall.
Try build looks good do me. Tagged and landed NSS_3_24_BETA6. https://hg.mozilla.org/integration/mozilla-inbound/rev/6c2df11a71b1
Blocks: 1250568
Attachment #8732959 - Flags: checkin+
Attachment #8738298 - Flags: checkin+
Attachment #8745285 - Flags: review?(franziskuskiefer)
Attachment #8745285 - Flags: review?(franziskuskiefer) → review+
Backed out for crashes on Android 4.3 API15 debug, e.g. dom/base/test/test_bug704320_http_http.html | application crashed [@ HandshakeCallback] Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/dfde7acefddc Push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=178243415be60cfd4bed7adae993736ab0238f12 Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=26647011&repo=mozilla-inbound 08:15:19 INFO - 39 INFO TEST-START | dom/base/test/test_bug704320_http_http.html 08:16:14 INFO - INFO | automation.py | Application ran for: 0:07:07.200151 08:16:14 INFO - INFO | zombiecheck | Reading PID log: /tmp/tmptaQq03pidlog 08:16:14 INFO - /data/tombstones does not exist; tombstone check skipped 08:16:15 INFO - mozcrash Copy/paste: /builds/slave/test/build/linux64-minidump_stackwalk /tmp/tmpee4XDw/3567f1d0-96ef-39bc-2d0656b0-2a9b8672.dmp /builds/slave/test/build/symbols 08:16:22 INFO - mozcrash Saved minidump as /builds/slave/test/build/blobber_upload_dir/3567f1d0-96ef-39bc-2d0656b0-2a9b8672.dmp 08:16:22 INFO - mozcrash Saved app info as /builds/slave/test/build/blobber_upload_dir/3567f1d0-96ef-39bc-2d0656b0-2a9b8672.extra 08:16:22 WARNING - PROCESS-CRASH | dom/base/test/test_bug704320_http_http.html | application crashed [@ HandshakeCallback] 08:16:22 INFO - Crash dump filename: /tmp/tmpee4XDw/3567f1d0-96ef-39bc-2d0656b0-2a9b8672.dmp 08:16:22 INFO - Operating system: Android 08:16:22 INFO - 0.0.0 Linux 2.6.29-gea477bb #1 Wed Sep 26 11:04:45 PDT 2012 armv7l 08:16:22 INFO - CPU: arm 08:16:22 INFO - ARMv7 ARM Cortex-A8 features: swp,half,thumb,fastmult,vfpv2,edsp,neon,vfpv3 08:16:22 INFO - 1 CPU 08:16:22 INFO - Crash reason: SIGSEGV 08:16:22 INFO - Crash address: 0x0 08:16:22 INFO - Process uptime: not available 08:16:22 INFO - Thread 16 (crashed) 08:16:22 INFO - 0 libxul.so!HandshakeCallback [nsNSSCallbacks.cpp:178243415be6 : 1135 + 0x2] 08:16:22 INFO - r0 = 0x5b18daf0 r1 = 0x0b3a70b8 r2 = 0x0b3a70b8 r3 = 0x00000000 08:16:22 INFO - r4 = 0x633869e0 r5 = 0x5e8ffa64 r6 = 0x5e8ffb44 r7 = 0x5e8ffc7c 08:16:22 INFO - r8 = 0x5e8ffc98 r9 = 0x62678460 r10 = 0x6265bb3c r12 = 0x00000003 08:16:22 INFO - fp = 0x00000303 sp = 0x5e8ffa28 lr = 0x5a087c93 pc = 0x5a087c94 08:16:22 INFO - Found by: given as instruction pointer in context 08:16:22 INFO - 1 libnss3.so!ssl3_FinishHandshake [ssl3con.c:178243415be6 : 12121 + 0x3] 08:16:22 INFO - r4 = 0x60351000 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x5e8ffc7c 08:16:22 INFO - r8 = 0x5e8ffc98 r9 = 0x5e8ffcdf r10 = 0x00000000 fp = 0x5e8ffc88 08:16:22 INFO - sp = 0x5e8ffc00 pc = 0x552d9a6d 08:16:22 INFO - Found by: call frame info 08:16:22 INFO - 2 libnss3.so!ssl3_AuthCertificateComplete [ssl3con.c:178243415be6 : 11471 + 0x3] 08:16:22 INFO - r3 = 0x00000000 r4 = 0x60351000 r5 = 0x552d9971 r6 = 0x00000000 08:16:22 INFO - r7 = 0x5e8ffc7c r8 = 0x5e8ffc98 r9 = 0x5e8ffcdf r10 = 0x00000000 08:16:22 INFO - fp = 0x5e8ffc88 sp = 0x5e8ffc10 pc = 0x552df6b3 08:16:22 INFO - Found by: call frame info 08:16:22 INFO - 3 libnss3.so!SSL_AuthCertificateComplete [sslsecur.c:178243415be6 : 1437 + 0x7] 08:16:22 INFO - r4 = 0x60351000 r5 = 0x00000000 r6 = 0x5e781360 r7 = 0x5e8ffc7c 08:16:22 INFO - r8 = 0x5e8ffc98 r9 = 0x5e8ffcdf r10 = 0x00000000 fp = 0x5e8ffc88 08:16:22 INFO - sp = 0x5e8ffc20 pc = 0x552eb965 08:16:22 INFO - Found by: call frame info 08:16:22 INFO - 4 libxul.so!nsNSSSocketInfo::SetCertVerificationResult [nsNSSIOLayer.cpp:178243415be6 : 529 + 0x5] 08:16:22 INFO - r4 = 0x00000000 r5 = 0x633869e0 r6 = 0x00000002 r7 = 0x5e8ffc7c 08:16:22 INFO - r8 = 0x5e8ffc98 r9 = 0x5e8ffcdf r10 = 0x00000000 fp = 0x5e8ffc88 08:16:22 INFO - sp = 0x5e8ffc30 pc = 0x5a08c42d 08:16:22 INFO - Found by: call frame info 08:16:22 INFO - 5 libxul.so!mozilla::psm::::SSLServerCertVerificationResult::Run [SSLServerCertVerification.cpp:178243415be6 : 1729 + 0x9] 08:16:22 INFO - r4 = 0x626e36a0 r5 = 0x00000000 r6 = 0x00000001 r7 = 0x5e8ffc7c 08:16:22 INFO - r8 = 0x5e8ffc98 r9 = 0x5e8ffcdf r10 = 0x00000000 fp = 0x5e8ffc88 08:16:22 INFO - sp = 0x5e8ffc48 pc = 0x5a06df83 08:16:22 INFO - Found by: call frame info 08:16:22 INFO - 6 libxul.so!nsThread::ProcessNextEvent [nsThread.cpp:178243415be6 : 989 + 0x3] 08:16:22 INFO - r4 = 0x52929a20 r5 = 0x00000000 r6 = 0x00000001 r7 = 0x5e8ffc7c 08:16:22 INFO - r8 = 0x5e8ffc98 r9 = 0x5e8ffcdf r10 = 0x00000000 fp = 0x5e8ffc88 08:16:22 INFO - sp = 0x5e8ffc50 pc = 0x58a8a0f1 08:16:22 INFO - Found by: call frame info 08:16:22 INFO - 7 libxul.so!NS_ProcessNextEvent [nsThreadUtils.cpp:178243415be6 : 290 + 0xd] 08:16:22 INFO - r4 = 0x52929a20 r5 = 0x00000001 r6 = 0x0000008e r7 = 0x00000000 08:16:22 INFO - r8 = 0x00000000 r9 = 0x529b0468 r10 = 0x6273a7a0 fp = 0x00000000 08:16:22 INFO - sp = 0x5e8ffcd0 pc = 0x58aa3229 08:16:22 INFO - Found by: call frame info 08:16:22 INFO - 8 libxul.so!nsSocketTransportService::Run [nsSocketTransportService2.cpp:178243415be6 : 943 + 0x7] 08:16:22 INFO - r4 = 0x529b0440 r5 = 0xcafb10f5 r6 = 0x0000008e r7 = 0x00000000 08:16:22 INFO - r8 = 0x00000000 r9 = 0x529b0468 r10 = 0x6273a7a0 fp = 0x00000000 08:16:22 INFO - sp = 0x5e8ffcf0 pc = 0x58b1228f 08:16:22 INFO - Found by: call frame info 08:16:22 INFO - 9 libxul.so!nsThread::ProcessNextEvent [nsThread.cpp:178243415be6 : 989 + 0x3] 08:16:22 INFO - r4 = 0x52929a20 r5 = 0x00000000 r6 = 0x00000001 r7 = 0x5e8ffdc4 08:16:22 INFO - r8 = 0x5e8ffde0 r9 = 0x5e8ffe27 r10 = 0x00000000 fp = 0x5e8ffdd0 08:16:22 INFO - sp = 0x5e8ffd98 pc = 0x58a8a0f1 08:16:22 INFO - Found by: call frame info 08:16:22 INFO - 10 libxul.so!NS_ProcessNextEvent [nsThreadUtils.cpp:178243415be6 : 290 + 0xd] 08:16:22 INFO - r4 = 0x52929a20 r5 = 0x00000001 r6 = 0x529b0520 r7 = 0x5e73ce90 08:16:22 INFO - r8 = 0x52929a20 r9 = 0x52929a30 r10 = 0xffffffff fp = 0x2a2641d8 08:16:22 INFO - sp = 0x5e8ffe18 pc = 0x58aa3229 08:16:22 INFO - Found by: call frame info 08:16:22 INFO - 11 libxul.so!mozilla::ipc::MessagePumpForNonMainThreads::Run [MessagePump.cpp:178243415be6 : 369 + 0x7] 08:16:22 INFO - r4 = 0x5e73ce80 r5 = 0x00000000 r6 = 0x529b0520 r7 = 0x5e73ce90 08:16:22 INFO - r8 = 0x52929a20 r9 = 0x52929a30 r10 = 0xffffffff fp = 0x2a2641d8 08:16:22 INFO - sp = 0x5e8ffe38 pc = 0x58c8e715 08:16:22 INFO - Found by: call frame info 08:16:22 INFO - 12 libxul.so!MessageLoop::RunInternal [message_loop.cc:178243415be6 : 230 + 0x5] 08:16:22 INFO - r4 = 0x529b0520 r5 = 0x5e8ffe98 r6 = 0x5e8ffea0 r7 = 0x5e8ffe9c 08:16:22 INFO - r8 = 0x529b0520 r9 = 0x52929a30 r10 = 0xffffffff fp = 0x2a2641d8 08:16:22 INFO - sp = 0x5e8ffe60 pc = 0x58c7314d 08:16:22 INFO - Found by: call frame info 08:16:22 INFO - 13 libxul.so!MessageLoop::Run [message_loop.cc:178243415be6 : 223 + 0x5] 08:16:22 INFO - r4 = 0x529b0520 r5 = 0x5e8ffe98 r6 = 0x5e8ffea0 r7 = 0x5e8ffe9c 08:16:22 INFO - r8 = 0x529b0520 r9 = 0x52929a30 r10 = 0xffffffff fp = 0x2a2641d8 08:16:22 INFO - sp = 0x5e8ffe78 pc = 0x58c73261 08:16:22 INFO - Found by: call frame info 08:16:22 INFO - 14 libxul.so!nsThread::ThreadFunc [nsThread.cpp:178243415be6 : 391 + 0x3] 08:16:22 INFO - r4 = 0x52929a20 r5 = 0x5e8ffe98 r6 = 0x5e8ffea0 r7 = 0x5e8ffe9c 08:16:22 INFO - r8 = 0x529b0520 r9 = 0x52929a30 r10 = 0xffffffff fp = 0x2a2641d8 08:16:22 INFO - sp = 0x5e8ffe90 pc = 0x58a893d1 08:16:22 INFO - Found by: call frame info 08:16:22 INFO - 15 libnss3.so!_pt_root [ptthread.c:178243415be6 : 216 + 0x5] 08:16:22 INFO - r4 = 0x5294e900 r5 = 0x00000000 r6 = 0x5540f134 r7 = 0x2a2641d8 08:16:22 INFO - r8 = 0x00000000 r9 = 0x5e800000 r10 = 0x5e8fff00 fp = 0x2a2641d8 08:16:22 INFO - sp = 0x5e8ffec8 pc = 0x5539dd7d 08:16:22 INFO - Found by: call frame info 08:16:22 INFO - 16 libc.so!__thread_entry [pthread_create.cpp : 92 + 0x6] 08:16:22 INFO - r4 = 0x5e8fff00 r5 = 0x2a2641d8 r6 = 0x5539dc99 r7 = 0x5294e900 08:16:22 INFO - r8 = 0x52afe674 r9 = 0x5e800000 r10 = 0x5e8fff00 fp = 0x2a2641d8 08:16:22 INFO - sp = 0x5e8ffee8 pc = 0x40033a5c 08:16:22 INFO - Found by: call frame info 08:16:22 INFO - 17 libc.so!pthread_create [pthread_create.cpp : 201 + 0x16] 08:16:22 INFO - r3 = 0x5294e900 r4 = 0x00000002 r5 = 0x00100000 r6 = 0x5294e900 08:16:22 INFO - r7 = 0x00000078 r8 = 0x52afe674 r9 = 0x5e800000 r10 = 0x5e8fff00 08:16:22 INFO - fp = 0x2a2641d8 sp = 0x5e8fff00 pc = 0x40033bd8 08:16:22 INFO - Found by: call frame info
Flags: needinfo?(kaie)
We're hitting: Assertion failure: rv == SECSuccess, at /builds/slave/m-in-and-api-15-d-000000000000/build/src/security/manager/ssl/nsNSSCallbacks.cpp:1123 Which means that the SSL_GetCipherSuiteInfo() call is failing: 1120 SSLCipherSuiteInfo cipherInfo; 1121 rv = SSL_GetCipherSuiteInfo(channelInfo.cipherSuite, &cipherInfo, 1122 sizeof cipherInfo); 1123 MOZ_ASSERT(rv == SECSuccess); https://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsNSSCallbacks.cpp#1123
We pushed it to try twice and it always comes out green. We unfortunately did not manage to even try reproducing it locally because the Firefox for Android builds were always crashing, using a physical device and using the emulator. Or only theory at the moment is that the inbound test runs might have maybe used a bad code snapshot. So let's just try landing it again and see how that works out?
Second landing attempt of beta7: https://hg.mozilla.org/integration/mozilla-inbound/rev/d19089f75144
Flags: needinfo?(kaie)
Attached file NSS_3_24_RC0.txt —
Requesting approval to uplift NSS 3.24 final release to the aurora 48 branch, because we never ship NSS beta versions with Firefox releases.
Attachment #8747108 - Flags: review+
Attachment #8747108 - Flags: approval-mozilla-aurora?
Comment on attachment 8747108 [details] NSS_3_24_RC0.txt (In reply to Pulsebot from comment #73) > https://hg.mozilla.org/integration/mozilla-inbound/rev/aa2694111316
Attachment #8747108 - Flags: checkin+
Depends on: 1237514
Comment on attachment 8747108 [details] NSS_3_24_RC0.txt NSS update for 48, please uplift to aurora. Looks ok on m-c.
Attachment #8747108 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
kaie, i guess you want to do this :)
Flags: needinfo?(kaie)
(In reply to Carsten Book [:Tomcat] from comment #77) > kaie, i guess you want to do this :) Yes thanks. https://hg.mozilla.org/releases/mozilla-aurora/rev/8bbd6c53b1ab Note that I'll keep the bug open/unfixed. There will be one more commit, next week, that changes the version tag from RC0 to RTM. If all goes well, no more code changes will happen. I'll take care of that mid next week.
Flags: needinfo?(kaie)
Whiteboard: [psm-assigned]
(In reply to Pulsebot from comment #79) > https://hg.mozilla.org/integration/mozilla-inbound/rev/8212c1b33d3a Finalized to NSS_3_24_RTM m-i
(In reply to Wes Kocher (:KWierso) from comment #81) > https://hg.mozilla.org/mozilla-central/rev/8212c1b33d3a
Status: NEW → RESOLVED
Closed: 9 years ago
Keywords: leave-open
Resolution: --- → FIXED
FYI, I'm ready to uplift the final version number change to aurora, and mark aurora as fixed, as soon as the aurora tree reopens. (It has been closed for more than 36 hours, it seems.)
(In reply to Kai Engert (:kaie) from comment #82) > (In reply to Wes Kocher (:KWierso) from comment #81) > > https://hg.mozilla.org/mozilla-central/rev/8212c1b33d3a AM_PATH_NSS still checks for 3.23 in old-configure.in[1], is it intentional? [1]: https://dxr.mozilla.org/mozilla-central/rev/8212c1b33d3a/old-configure.in#2461
(In reply to Hector Zhao [:hectorz] from comment #86) > (In reply to Kai Engert (:kaie) from comment #82) > > (In reply to Wes Kocher (:KWierso) from comment #81) > > > https://hg.mozilla.org/mozilla-central/rev/8212c1b33d3a > > AM_PATH_NSS still checks for 3.23 in old-configure.in[1], is it intentional? > > [1]: > https://dxr.mozilla.org/mozilla-central/rev/8212c1b33d3a/old-configure. > in#2461 No, that's an oversight, thanks for noticing.
Approval Request Comment This is a build environment fix. We must ensure that Firefox 48 is built against the required minimum NSS version, on systems (e.g. Linux) that install NSS separately. (This isn't a code change.)
Attachment #8762543 - Flags: review?(martin.thomson)
Attachment #8762543 - Flags: approval-mozilla-beta?
Comment on attachment 8762543 [details] [diff] [review] 1258375-configure.patch a=dveditz for beta 48 (after it's reviewed)
Attachment #8762543 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #8762543 - Flags: review?(martin.thomson) → review+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: