Closed Bug 180829 Opened 22 years ago Closed 8 years ago

cvs personal build PR_Assert'd when it was asked to connect to sourceforge

Categories

(Core :: Security: PSM, defect, P2)

Product:
Core
Component:
Security: PSM
Version:
Other Branch
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: timeless, Unassigned)

References

(
URL
)

Details

(Keywords: crash) 

PR_Assert(const char * 0x065235ec, const char * 0x065235e0, int 2286) line 518
PK11_GetInternalSlot() line 2286 + 29 bytes
PK11_TokenExists(unsigned long 4113) line 2430 + 5 bytes
ssl3_config_match_init(sslSocketStr * 0x04a8a918) line 481 + 46 bytes
ssl2_ConstructCipherSpecs(sslSocketStr * 0x04a8a918) line 202 + 9 bytes
ssl2_BeginClientHandshake(sslSocketStr * 0x04a8a918) line 2962 + 9 bytes
ssl_Do1stHandshake(sslSocketStr * 0x04a8a918) line 145 + 13 bytes
ssl_SecureRecv(sslSocketStr * 0x04a8a918, unsigned char * 0x032428a4, int 4096,
int 0) line 966 + 9 bytes
ssl_SecureRead(sslSocketStr * 0x04a8a918, unsigned char * 0x032428a4, int 4096)
line 985 + 19 bytes
ssl_Read(PRFileDesc * 0x047d7b58, void * 0x032428a4, int 4096) line 1242 + 21 bytes
nsSSLIOLayerRead(PRFileDesc * 0x00fa2048, void * 0x032428a4, int 4096) line 1109
+ 26 bytes
PR_Read(PRFileDesc * 0x00fa2048, void * 0x032428a4, int 4096) line 136 + 20 bytes
nsSocketIS::Read(nsSocketIS * const 0x0349a380, char * 0x032428a4, unsigned int
4096, unsigned int * 0x062efdcc) line 2526 + 21 bytes
nsHttpTransaction::Read(nsHttpTransaction * const 0x03239158, char * 0x032428a4,
unsigned int 4096, unsigned int * 0x062efdcc) line 883 + 38 bytes
nsReadFromInputStream(nsIOutputStream * 0x04d7ff60, void * 0x03239158, char *
0x032428a4, unsigned int 0, unsigned int 4096, unsigned int * 0x062efdcc) line 838
nsPipe::nsPipeOutputStream::WriteSegments(nsPipe::nsPipeOutputStream * const
0x04d7ff60, unsigned int (nsIOutputStream *, void *, char *, unsigned int,
unsigned int, unsigned int *)* 0x10059350 nsReadFromInputStream(nsIOutputStream
*, void *, char *, unsigned int, unsigned int, unsigned int *), void *
0x03239158, unsigned int 16384, unsigned int * 0x062efe60) line 711 + 29 bytes
nsPipe::nsPipeOutputStream::WriteFrom(nsPipe::nsPipeOutputStream * const
0x04d7ff60, nsIInputStream * 0x03239158, unsigned int 16384, unsigned int *
0x062efe60) line 846
nsStreamListenerProxy::OnDataAvailable(nsStreamListenerProxy * const 0x04dc4f80,
nsIRequest * 0x03239154, nsISupports * 0x00000000, nsIInputStream * 0x03239158,
unsigned int 0, unsigned int 16384) line 309 + 38 bytes
nsHttpTransaction::OnDataReadable(nsIInputStream * 0x0349a380) line 272 + 96 bytes
nsHttpConnection::OnDataAvailable(nsHttpConnection * const 0x04ac567c,
nsIRequest * 0x04c59a20, nsISupports * 0x00000000, nsIInputStream * 0x0349a380,
unsigned int 0, unsigned int 8192) line 748 + 21 bytes
nsSocketReadRequest::OnRead() line 2962 + 57 bytes
nsSocketTransport::doReadWrite(short 3) line 1193 + 14 bytes
nsSocketTransport::Process(short 3) line 560 + 13 bytes
nsSocketTransportService::Run(nsSocketTransportService * const 0x01077884) line
532 + 13 bytes
nsThread::Main(void * 0x0322c840) line 123 + 26 bytes
_PR_NativeRunThread(void * 0x04a7f950) line 433 + 13 bytes
MSVCRTD! 1020c323()
KERNEL32! 77e92ca8()

I don't have a profile directory so it's possible some db access failed, but i
didn't see any sign of it.

debug.mozconfig available upon request
Assigned the bug to Bob.

Note that this assertion failure is also reported in
bug 181942.  timeless, were you running the Mozilla
client or TestProtocols?
Assignee: wtc → relyea
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Target Milestone: --- → 3.7
The assertion in question is in pk11wrap/pk11slot.c:

   2281 /* get the internal default slot */
   2282 PK11SlotInfo *
   2283 PK11_GetInternalSlot(void)
   2284 {
   2285     SECMODModule * mod = SECMOD_GetInternalModule();
   2286     PORT_Assert(mod != NULL);
   2287     if (!mod) {
   2288         PORT_SetError( SEC_ERROR_NO_MODULE );
   2289         return NULL;
   2290     }
   2291     return PK11_ReferenceSlot(mod->slots[0]);
   2292 }

I think this means 1) NSS has not been initialized; 2) NSS
initialization failed; or 3) NSS has been shut down.
Is there any evidence of an NSS bug here?

IINM, There is an issue in mozilla/PSM where it doesn't shut down all 
SSL connections before shutting down NSS.  I believe Kai has been working
on a solution for that.  This looks like what I'd expect under those 
circumstances.  
mozilla, not testprotocols but my mozilla client has no profile directory
provider just like testprotocols :). a long time ago i knew that testprotocols
didn't handle https, but i didn't remember that when i was running through this
round of testing.

fwiw it's 2 nss init failed.

it doesn't matter to me as a consumer whether the bug is in nss or psm, all i
want is for https to work. or at least not kill my gecko. you're a module and
have no business killing the app, play nice with the other little children,
silently log your error and let everyone else continue.

if possible i'd prefer for nss to be changed so that it has fewer physical
storage requirements since that should solve the problem. iow nss should be able
to init without a local database. There's really nothing wrong with having a
readonly session and using whatever defaults you have when you're built.

we can resolve this as a duplicate of the testprotocols bug if you like, but
whatever is done i want the root cause fixed :).

Is there any reason not to simply remove the PR_Assert? it seems like the code
handles the case.  Perhaps PR_Assert in NSS should be conditionally defined not
based on ifdef DEBUG but based on ifdef NSS_HACKER where something is
responsible for that definition.
The issue is that your program apparently called NSS_Init and ignored the
failure, and went ahead and did things that it should not have done 
unless and until NSS was initialized.  

The assertion is that your program has done something illegal, trying to use
NSS when it's not initialized.  If the program pays attention to the value
returned by NSS_Init, all should be well.

So, is this a PSM bug?  or a bug in testprotocols?  (which I haven't heard 
of before this.)
Timeless, please provide a testcase where PSM/NSS fail with the standard
environment and standard sources. (If the failure should only happen with your
special own modifications, I think this bug is invalid.)
Standard environment and standard sources: a home directory out in NFS that is 
temporarily unreachable due to a network outage.  If I understand the problem 
description correctly, that would lead to the same failure....  If not, the 
problem description needs some clarification...
nelson: the issue is simple, your module should not kill the whole app. it can
be as noisy as it likes as long as only your team hears the noise and I can at
least not have my app killed because of it.

Please commit a fix which prevents NSS from KILLing consumers when its
assertions fail.

Beyond that the root problem is that psm makes some stupid demands and then
behaves poorly when they fail.

as i said earlier i was using mozilla *not* testprotocols. however both things
use PSM which is the thing which isn't playing nicely with NSS.

At the very least could you explain what the assertion expects and how one could
resolve it without having any storage?

kaie: bug 181942.
timeless: we can remove this assertion.

Can you try removing this assertion and see if Mozilla
fails gracefully (i.e., without hitting another assertion
failure or crashing)?
This is clearly a PSM bug. NSS should never be called if it never gets
initialized. The Assertion should not be removed because it detects this
situation early. This is not the only place that NSS may get in trouble, but
it's a good place to detect the trouble early. NSS is asserting here to prevent
a possible undecipherable crash later.

bob
Bob, I suggest you change this bug to be a PSM bug.
I agree with nelson, moving to PSM
Assignee: relyea → kaie
Component: Libraries → Client Library
Product: NSS → PSM
Target Milestone: 3.7 → ---
I believe that removing this assertion will only lead to other 
crashes whose cause is less apparent than the assertion failure.  

The assertion was put in precisely to make it easier to identify the
cause of those crashes.  It has done this admirably.

Using libSSL when NSS is not initialized is analogous to passing NULL to 
libc's strlen, or passing NULL as the destination address for strcpy.  
The results are undefined, a euphemism for crashing.  Just as strlen
and strcpy require that they not be passed invalid pointers, so NSS 
requires that libraries not be used when NSS is not initialized.
When a crash occurs because the caller violated the requirements of the 
called function, it is an error on the part of the caller, not an error 
on the part of the library routine.  A developer of an application that 
violates the requirement should no more expect libSSL to not crash than 
to expect strlen and strcpy to not crash.

Here is a crucial distinction between PSM and NSS.  
NSS is not solely a mozilla browser component, and its API's semantics 
are not dictated by the browser.  NSS is used by many different applications.
PSM is solely a mozilla browser component. PSM is the glue that connects 
NSS to mozilla.  If there is any component of mozilla that needs to change 
to avoid this assertion failure, it is PSM.  That is why this has become a 
PSM bug.
Product: PSM → Core
Whiteboard: [kerh-coz]
QA Contact: bishakhabanerjee → ui
Is this one still relevant? If yes, we should get it hooked up with STR and at least a crash signature we can watch. If no, we should mark the bug resolved.
reassign bug owner.
mass-update-kaie-20120918
Assignee: kaie → nobody
Component: Security: UI → Security: PSM
Whiteboard: [kerh-coz]
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.