Open Bug 1612116 Opened 10 months ago Updated 5 days ago

Crash in [@ mozilla::psm::GetXPCOMFromNSSError]


(NSS :: Libraries, defect)



(firefox72 wontfix, firefox73 wontfix)

Tracking Status
firefox72 --- wontfix
firefox73 --- wontfix


(Reporter: philipp, Unassigned, NeedInfo)


(Keywords: crash, leave-open)

Crash Data


(1 file)

This bug is for crash report bp-c072d82e-9353-44e0-a4f5-f8c410200129.

Top 10 frames of crashing thread:

0 xul.dll mozilla::psm::GetXPCOMFromNSSError security/manager/ssl/NSSErrorsService.cpp:76
1 xul.dll mozilla::net::nsHttpConnection::EnsureNPNComplete netwerk/protocol/http/nsHttpConnection.cpp:572
2 xul.dll mozilla::net::nsHttpConnection::OnSocketWritable netwerk/protocol/http/nsHttpConnection.cpp:2068
3 xul.dll mozilla::net::TLSFilterTransaction::StartTimerCallback netwerk/protocol/http/TunnelUtils.cpp:579
4 xul.dll mozilla::net::TLSFilterTransaction::Notify netwerk/protocol/http/TunnelUtils.cpp:558
5 xul.dll nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:564
6 xul.dll nsTimerEvent::Run xpcom/threads/TimerThread.cpp:259
7 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1241
8 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
9 xul.dll mozilla::net::nsSocketTransportService::Run netwerk/base/nsSocketTransportService2.cpp:1013

this browser process crash signature is spiking up in volume in the past couple of hours and reports generally come with MOZ_CRASH(Function failed without calling PR_GetError). i'm not entirely sure if this bug is better belonging in security:psm or networking.

i can't see any obvious correlation yet of what might explain the sudden spike - some of the more affected locales are id & tr which is something we don't commonly see and NSFW site are quite common among the urls reported for crashing.

Looks like this spiked on/around January 29 and then went back down to the previous "a handful of crashes per day" volume.

The priority flag is not set for this bug.
:keeler, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dkeeler)

It's not immediately obvious what's going on here, but we could start by adding more assertions that TransportSecurityInfo::mErrorCode and mCanceled are consistent. Since the volume went back down I'm not too concerned.

Flags: needinfo?(dkeeler)
Priority: -- → P2
Whiteboard: [psm-backlog]

This spiked up again yesterday with 1300+ crash reports.

(I'm also wondering whether we should move this over to necko instead of PSM?)

I think we'll need to land some diagnostic assertions in PSM and go from there, so let's leave it here for now. We can have a look at this next week.

Assignee: nobody → bugs
Keywords: leave-open
Priority: P2 → P1
Whiteboard: [psm-backlog] → [psm-assigned]
Pushed by
Added diagnostics to ensure mErrorCode and mCanceled are consistent r=keeler

Looks like we're seeing this crash signature pick up in the last few days, on both release and esr.

There's also some crashes on aurora with the diagnostic assert added here, e.g. bp-0b2abc87-602f-42b1-82dd-273170201102

Crash Signature: [@ mozilla::psm::GetXPCOMFromNSSError] → [@ mozilla::psm::GetXPCOMFromNSSError] [@ nsNSSSocketInfo::DriveHandshake]

This assertion is failing:

  SECStatus rv = SSL_ForceHandshake(mFd);

  if (rv != SECSuccess) {
    PRErrorCode errorCode = PR_GetError();
    MOZ_DIAGNOSTIC_ASSERT(errorCode, "handshake failed without error code");

which means that NSS is returning a non-success status while not setting the error code, which probably means there's a bug in NSS.

Assignee: bugs → nobody
Severity: S3 → --
Component: Security: PSM → Libraries
Priority: P1 → --
Product: Core → NSS
QA Contact: jjones
Whiteboard: [psm-assigned]
Version: unspecified → other

The severity field is not set for this bug.
:jcj, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jc)
You need to log in before you can comment on or make changes to this bug.