exception breakpoint application error using https url in TestProtocols

RESOLVED INCOMPLETE

Status

()

--
minor
RESOLVED INCOMPLETE
16 years ago
3 years ago

People

(Reporter: depman1, Unassigned)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
Mozilla 1.3a Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021124
build. with psm, crypto-enabled. Didn't happen in the 11/12/02 build, but did in
11/20/02.
1. cd /mozilla/dist/bin
2. Run TestProtocols with https url (ssl encrypted), i.e. url loads in the
browser (e.g. https://www.aol.com, https://www.sun.com, https://www.oracle.com,
https://www.google.com,
https://www.bankofamerica.com/signin/index.cfm?template=security_details.cfm)
Result:
TestProtocols posts "Trying to load https://www.x.com" to console. Then get "The
exception Breakpoint - A breakpoint has been reached" application error. If you
press OK at that point, you get assertion: RgnRectMemoryAllocator not
thread-safe: 'owningThread == NS_CurrentThread()', file
/mozilla/xpcom/glue/nsDebug.cpp line 533.
Note: Using https urls which return "connection refused" when loading in the
browser (netscape, yahoo, intel), TestProtocols posts complete output (channel
info, http request/response headers, loading info) but reads 0 bytes; then
displays XPCOM event receiver msg (exception breakpoint)

Call stack:
NTDLL! 77f7629c()
PK11_GetInternalSlot() line 2286 + 36 bytes
PK11_TokenExists(unsigned long 4113) line 2430 + 5 bytes
ssl3_config_match_init(sslSocketStr * 0x00dae2c0) line 483 + 46 bytes
ssl2_ConstructCipherSpecs(sslSocketStr * 0x00dae2c0) line 202 + 9 bytes
ssl2_BeginClientHandshake(sslSocketStr * 0x00dae2c0) line 2962 + 9 bytes
ssl_Do1stHandshake(sslSocketStr * 0x00dae2c0) line 145 + 13 bytes
ssl_SecureRecv(sslSocketStr * 0x00dae2c0, unsigned char * 0x00faff8c, int 4096,
int 0) line 966 + 9 bytes
ssl_SecureRead(sslSocketStr * 0x00dae2c0, unsigned char * 0x00faff8c, int 4096)
line 985 + 19 bytes
ssl_Read(PRFileDesc * 0x00dafd30, void * 0x00faff8c, int 4096) line 1242 + 21 bytes
nsSSLIOLayerRead(PRFileDesc * 0x00da9060, void * 0x00faff8c, int 4096) line 1109
+ 26 bytes
PR_Read(PRFileDesc * 0x00da9060, void * 0x00faff8c, int 4096) line 136 + 20 bytes
nsSocketIS::Read(nsSocketIS * const 0x00dafc60, char * 0x00faff8c, unsigned int
4096, unsigned int * 0x015efdc8) line 2526 + 21 bytes
nsHttpTransaction::Read(nsHttpTransaction * const 0x00daa2c8, char * 0x00faff8c,
unsigned int 4096, unsigned int * 0x015efdc8) line 883 + 38 bytes
nsReadFromInputStream(nsIOutputStream * 0x00dace70, void * 0x00daa2c8, char *
0x00faff8c, unsigned int 0, unsigned int 4096, unsigned int * 0x015efdc8) line 838
nsPipe::nsPipeOutputStream::WriteSegments(nsPipe::nsPipeOutputStream * const
0x00dace70, unsigned int (nsIOutputStream *, void *, char *, unsigned int,
unsigned int, unsigned int *)* 0x10057360 nsReadFromInputStream(nsIOutputStream
*, void *, char *, unsigned int, unsigned int, unsigned int *), void *
0x00daa2c8, unsigned int 16384, unsigned int * 0x015efe5c) line 711 + 29 bytes
nsPipe::nsPipeOutputStream::WriteFrom(nsPipe::nsPipeOutputStream * const
0x00dace70, nsIInputStream * 0x00daa2c8, unsigned int 16384, unsigned int *
0x015efe5c) line 846
nsStreamListenerProxy::OnDataAvailable(nsStreamListenerProxy * const 0x00dabfc0,
nsIRequest * 0x00daa2c4, nsISupports * 0x00000000, nsIInputStream * 0x00daa2c8,
unsigned int 0, unsigned int 16384) line 309 + 38 bytes
nsHttpTransaction::OnDataReadable(nsIInputStream * 0x00dafc60) line 272 + 96 bytes
nsHttpConnection::OnDataAvailable(nsHttpConnection * const 0x00dad6a4,
nsIRequest * 0x00dab2b0, nsISupports * 0x00000000, nsIInputStream * 0x00dafc60,
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 0x00d4d224) line
532 + 13 bytes
nsThread::Main(void * 0x00d4ebd0) line 120 + 26 bytes
_PR_NativeRunThread(void * 0x00d4e9b0) line 433 + 13 bytes
_threadstartex(void * 0x00d4e800) line 212 + 13 bytes
KE

Call stack for non-secure urls:
NTDLL! 77f7629c()
ShutdownCRLCache() line 1036 + 39 bytes
NSS_Shutdown() line 546
nsNSSComponent::ShutdownNSS() line 1091
nsNSSComponent::~nsNSSComponent() line 255
nsNSSComponent::`scalar deleting destructor'() + 15 bytes
nsNSSComponent::Release(nsNSSComponent * const 0x00da8090) line 1150 + 151 bytes
nsSupportsArray::Clear(nsSupportsArray * const 0x00d4e2c0) line 560 + 54 bytes
nsSupportsArray::DeleteArray() line 305
nsSupportsArray::~nsSupportsArray() line 148
nsSupportsArray::`vector deleting destructor'(unsigned int 1) + 81 bytes
nsSupportsArray::Release(nsSupportsArray * const 0x00d4e2c0) line 239 + 148 bytes
nsCOMPtr<nsISupportsArray>::~nsCOMPtr<nsISupportsArray>() line 491
nsObserverList::~nsObserverList() line 58 + 11 bytes
nsObserverList::`scalar deleting destructor'(unsigned int 1) + 15 bytes
ReleaseObserverList(nsHashKey * 0x00d4e330, void * 0x00d4e460, void *
0x00000000) line 109 + 28 bytes
hashEnumerateRemove(PLDHashTable * 0x00d4dba8, PLDHashEntryHdr * 0x00f426f4,
unsigned int 8, void * 0x0012fdb4) line 315 + 26 bytes
PL_DHashTableEnumerate(PLDHashTable * 0x00d4dba8, int (PLDHashTable *,
PLDHashEntryHdr *, unsigned int, void *)* 0x100203f0
hashEnumerateRemove(PLDHashTable *, PLDHashEntryHdr *, unsigned int, void *),
void * 0x0012fdb4) line 603 + 34 bytes
nsHashtable::Reset(int (nsHashKey *, void *, void *)* 0x1001b060
ReleaseObserverList(nsHashKey *, void *, void *), void * 0x00000000) line 336 +
21 bytes
nsObjectHashtable::Reset() line 875
nsObjectHashtable::~nsObjectHashtable() line 834
nsObjectHashtable::`vector deleting destructor'(unsigned int 1) + 81 bytes
nsObserverService::~nsObserverService() line 84 + 33 bytes
nsObserverService::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsObserverService::Release(nsObserverService * const 0x00d4dc10) line 72 + 142 bytes
nsCOMPtr_base::assign_assuming_AddRef(nsISupports * 0x00000000) line 436
nsCOMPtr_base::assign_with_AddRef(nsISupports * 0x00000000) line 74
nsCOMPtr<nsISupports>::operator=(nsISupports * 0x00000000) line 796
FreeServiceContractIDEntryEnumerate(PLDHashTable * 0x00d46eec, PLDHashEntryHdr *
0x00f7ef0c, unsigned int 794, void * 0x00000000) line 1926
PL_DHashTableEnumerate(PLDHashTable * 0x00d46eec, int (PLDHashTable *,
PLDHashEntryHdr *, unsigned int, void *)* 0x10069370
FreeServiceContractIDEntryEnumerate(PLDHashTable *, PLDHashEntryHdr *, unsigned
int, void *), void * 0x00000000) line 603 + 34 bytes
nsComponentManagerImpl::FreeServices() line 1938 + 19 bytes
NS_ShutdownXPCOM(nsIServiceManager * 0x00000000) line 723
main(int 2, char * * 0x00d44bc0) line 655 + 8 bytes
mainCRTStartup() line 338 + 17 bytes
KER

Comment 1

16 years ago
PSM is probably not getting initialized properly or something.

david: please comment on the severity of this bug.  how important is this to QA?

-> future (for now)
Target Milestone: --- → Future
(Reporter)

Comment 2

16 years ago
QA is investigating whether to use TestProtocols as part of network testing. It
appears to be valuable for that purpose. An input file containing all types of
urls with different schemes would be used for that testing, so TestProtocols
would 'croak' on https urls. I think fixing this would be moderately important
to QA, but I'll downgrade this to minor until QA would decide to use it on a
regular basis.
Severity: normal → minor
1)
==
Darin, if I understand David correctly, I think this is not a PSM problem.


2)
==
David, if I understand you correctly, you see the same kind of exception
reported, regardless whether you use https or http.
Only the symptoms in the browser window are different.
Is this correct?
Or do you see different errors reported?


3)
==
I don't know RgnRectMemoryAllocator - is that a new class? Who uses it?


4)
==
On 11/19 a a new version of the crypto library NSS was landed (3.6 beta 1).
I see both your call stacks are in NSS, so what we see might be a regression in NSS.
(Reporter)

Comment 4

16 years ago
kaie: I don't see the errors with http, only with https urls. I just used the
browser as a reference to see if encrypted pages loaded, like
https://www.aol.com. For these urls, I was getting the exception breakpoint as
TestProtocols was trying to load the url. For non-encrypted "https urls" which
return "connection refused" in the browser, like https://www.netscape.com,
TestProtocols completes its tests then posts the exception breakpoint as an
XPCOM event receiver message. This latter case was tried to help debug the
problem, if in fact it's helpful.

Comment 5

16 years ago
David,

You are running a debug build, right?  These "exception
breakpoints" are assertion failures.  Assertions are
compiled away in optimized builds.

The assertion at "PK11_GetInternalSlot() line 2286 + 36 bytes"
is:

 2285      SECMODModule * mod = SECMOD_GetInternalModule();
 2286      PORT_Assert(mod != NULL);

I guess this probably results from TestProtocols shutting
down NSS while there is still an open SSL connection, or
trying to do SSL without initializing NSS.

The assertion at "ShutdownCRLCache() line 1036 + 39 bytes"
is:

  1036      PR_ASSERT(crlcache.lock);

This is a known bug in NSS 3.6 (bug 180894).
(Reporter)

Comment 6

16 years ago
1) Yes, this is happening in debug builds (mozilla trunk). 
2) Regarding the "ShutdownCRLCache()" assert, this is still happening in the
cases cited above as of the Mozilla 1.3a Gecko/20021125 trunk build 
3) If this helps narrow it down, I noticed that TestProtocols' StartLoadingURL()
is using nsIIOService->NewURI() and NS_NewChannel(). I tested these with https;
rv succeeds for these calls and nsIURI->GetSpec() returns the correct uri. 

Comment 7

16 years ago
I just found that the assertion failure at
"PK11_GetInternalSlot() line 2286 + 36 bytes"
has also been reported by timeless in bug
180829.

This means the only assertion failure not
reported elsewhere is this one:

assertion: RgnRectMemoryAllocator not
thread-safe: 'owningThread == NS_CurrentThread()', file
/mozilla/xpcom/glue/nsDebug.cpp line 533.

Comment 8

16 years ago
heh, i've reported that elsewhere, the rect thing is a silly threadsafe issue,
what happens is that when nss shoots gecko all static objects are destroyed on
the thread which killed mozilla instead of the thread where they were created.
it's not a big deal, i filed a bug for it...

Comment 9

15 years ago
I'm not sure if I've hit this bug or not but when I sign out of the Bank of
America website, Mozilla crashes.  I'm using Mozilla/5.0 (Windows; U; Windows NT
5.0; en-US; rv:1.7) Gecko/20040514 MultiZilla/1.6.2.1d and I've sent these
Talkback incidents:

TB60895E
TB60894K

Is this the same or similar problem or should I open a new bug report?

Peace...
Tom, this bug is about a debug-only assertion that is hit under some
circumstances by the TestProtocols application that's used to test Mozilla's
networking library.

Whatever you're seeing, it's not this bug.  I'm not quite sure what made you
think the two are related...

Please file a separate bug if you can reproduce your crash in a _current_ (May
24 or later) trunk or branch build.  If so, please cc me.

Comment 11

15 years ago
The reference to signing into Bank of America's site in the first post of this
bug report is how I made the connection since my crash comes when I sign-out.  :)

I'll download a newer version and see what happens. If the crash still happens,
I'll open a bug report and will CC you on it.

Peace...

Comment 12

13 years ago
-> default owner
Assignee: darin → nobody
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking
Target Milestone: Future → ---
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.