Closed Bug 255135 Opened 20 years ago Closed 12 years ago

PSM loads string bundles on the socket thread [was: nsStandardURL not thread-safe]

Categories

(Core Graveyard :: Security: UI, defect)

Other Branch
x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 350872

People

(Reporter: timeless, Unassigned)

References

()

Details

(Whiteboard: [kerh-cuz])

Attachments

(1 file)

+	aStr	0x011bb6f0 "nsStandardURL not thread-safe"	const char *
+	aExpr	0x011b8ca0 "_mOwningThread.GetThread() == PR_GetCurrentThread()"	const
char *
+	aFile	0x011bb630 "r:/mozilla/netwerk/base/src/nsStandardURL.cpp"	const char *
	aLine	0x0000034b	int

>	xpcom.dll!nsDebug::Assertion(const char * aStr=0x011bb6f0, const char *
aExpr=0x011b8ca0, const char * aFile=0x011bb630, int aLine=0x0000034b)  Line 109	C++
 	necko.dll!nsStandardURL::AddRef()  Line 843 + 0x50	C++
 	necko.dll!nsInterfaceHashtable<nsCStringHashKey,nsIURI>::Get(const nsACString
& aKey={...}, nsIURI * * pInterface=0x0140f0c8)  Line 125	C++
 	necko.dll!nsResProtocolHandler::GetSubstitution(const nsACString & root={...},
nsIURI * * result=0x0140f0c8)  Line 268 + 0x14	C++
 	necko.dll!nsResProtocolHandler::ResolveURI(nsIURI * uri=0x75437465, nsACString
& result={...})  Line 294 + 0x1c	C++
 	necko.dll!nsResURL::GetFile(nsIFile * * result=0x0140f16c)  Line 95	C++
 	chrome.dll!GetBaseURLFile(const nsACString & aBaseURL={...}, nsIFile * *
aFile=0x0140f2c8)  Line 443 + 0x1c	C++
 	chrome.dll!nsChromeRegistry::VerifyCompatibleProvider(nsIRDFResource *
aPackageResource=0x203d3d20, nsIRDFResource * aProviderResource=0x475f5250,
nsIRDFResource * aArc=0x75437465, int * aAcceptable=0x6e657272)  Line 795 + 0x15	C++
 	chrome.dll!nsChromeRegistry::GetBaseURL(const nsACString & aPackage={...},
const nsACString & aProvider={...}, nsACString & aBaseURL={...})  Line 603	C++
 	chrome.dll!nsChromeRegistry::ConvertChromeURL(nsIURI * aChromeURL=0x75437465,
nsACString & aResult={...})  Line 520	C++
 	chrome.dll!nsChromeProtocolHandler::NewChannel(nsIURI * aURI=0x75437465,
nsIChannel * * aResult=0x6e657272)  Line 700	C++
 	necko.dll!nsIOService::NewChannelFromURI(nsIURI * aURI=0x75437465, nsIChannel
* * result=0x6e657272)  Line 483	C++
 	i18n.dll!nsStringBundle::LoadProperties()  Line 127 + 0x3a	C++
 	i18n.dll!nsStringBundle::GetStringFromName(const unsigned short *
aName=0x75437465, unsigned short * * aResult=0x6e657272)  Line 269	C++
 	pipnss.dll!nsHandleSSLError(nsNSSSocketInfo * socketInfo=0x02bb29f8, int
err=0x014e0000)  Line 498 + 0x33	C++
 	pipnss.dll!nsContinueDespiteCertError(nsNSSSocketInfo * infoObject=0x014e0000,
PRFileDesc * sslSocket=0x02bb5a78, int error=0xffffe05b, nsNSSCertificate *
nssCert=0x02b39650)  Line 1341	C++
 	pipnss.dll!nsNSSBadCertHandler(void * arg=0x02bb29f8, PRFileDesc *
sslSocket=0x02bb5a78)  Line 2192 + 0xf	C++
 	ssl3.dll!ssl3_HandleCertificate(sslSocketStr * ss=0x02bb2ad0, unsigned char *
b=0x02be0e0d, unsigned int length=0x00000000)  Line 7421 + 0x19	C
 	ssl3.dll!ssl3_HandleHandshakeMessage(sslSocketStr * ss=0x02bb2ad0, unsigned
char * b=0x02be074c, unsigned int length=0x000006c1)  Line 8048 + 0x11	C
 	ssl3.dll!ssl3_HandleHandshake(sslSocketStr * ss=0x02bb2ad0, sslBufferStr *
origBuf=0x02bb2c78)  Line 8165 + 0x19	C
 	ssl3.dll!ssl3_HandleRecord(sslSocketStr * ss=0x02bb2ad0, SSL3Ciphertext *
cText=0x0140fd48, sslBufferStr * databuf=0x02bb2c78)  Line 8433 + 0xd	C
 	ssl3.dll!ssl3_GatherCompleteHandshake(sslSocketStr * ss=0x02bb2ad0, int
flags=0x00000000)  Line 203 + 0x16	C
 	ssl3.dll!ssl_GatherRecord1stHandshake(sslSocketStr * ss=0x02bb2ad0)  Line
1260 + 0xb	C
 	ssl3.dll!ssl_Do1stHandshake(sslSocketStr * ss=0x02bb2ad0)  Line 149 + 0xd	C
 	ssl3.dll!ssl_SecureSend(sslSocketStr * ss=0x02bb2ad0, const unsigned char *
buf=0x02a65b40, int len=0x00000185, int flags=0x00000000)  Line 1033 + 0x9	C
 	ssl3.dll!ssl_SecureWrite(sslSocketStr * ss=0x02bb2ad0, const unsigned char *
buf=0x02a65b40, int len=0x00000185)  Line 1067 + 0x13	C
 	ssl3.dll!ssl_Write(PRFileDesc * fd=0x02bb5a78, const void * buf=0x02a65b40,
int len=0x00000185)  Line 1286 + 0x15	C
 	pipnss.dll!nsSSLIOLayerWrite(PRFileDesc * fd=0x023dff30, const void *
buf=0x02a65b40, int amount=0x00000185)  Line 1145 + 0x11	C++
 	nspr4.dll!PR_Write(PRFileDesc * fd=0x023dff30, const void * buf=0x02a65b40,
int amount=0x00000185)  Line 146 + 0x14	C
 	necko.dll!nsSocketOutputStream::Write(const char * buf=0x02a65b40, unsigned
int count=0x00000185, unsigned int * countWritten=0x0140fed0)  Line 543 + 0xf	C++
 	necko.dll!nsHttpConnection::OnReadSegment(const char * buf=0x02a65b40,
unsigned int count=0x00000185, unsigned int * countRead=0x0140fed0)  Line 510	C++
 	necko.dll!nsHttpTransaction::ReadRequestSegment(nsIInputStream *
stream=0x02a65e70, void * closure=0x02a65978, const char * buf=0x02a65b40,
unsigned int offset=0x00000000, unsigned int count=0x00000185, unsigned int *
countRead=0x0140fed0)  Line 350	C++
 	xpcom.dll!nsStringInputStream::ReadSegments(unsigned int (nsIInputStream *,
void *, const char *, unsigned int, unsigned int, unsigned int *)*
writer=0x0118856a, void * closure=0x02a65978, unsigned int aCount=0x00000185,
unsigned int * result=0x0140fed0)  Line 248	C++
 	necko.dll!nsHttpTransaction::ReadSegments(nsAHttpSegmentReader *
reader=0x02baa250, unsigned int count=0x00001000, unsigned int *
countRead=0x0140fed0)  Line 376	C++
 	necko.dll!nsHttpConnection::OnSocketWritable()  Line 544 + 0xf	C++
 	necko.dll!nsHttpConnection::OnOutputStreamReady(nsIAsyncOutputStream *
out=0x02baa4d8)  Line 755	C++
 	necko.dll!nsSocketOutputStream::OnSocketReady(unsigned int
condition=0x02baa25c)  Line 483	C++
 	necko.dll!nsSocketTransport::OnSocketReady(PRFileDesc * fd=0x023dff30, short
outFlags=0x0002)  Line 1392	C++
 	necko.dll!nsSocketTransportService::Run()  Line 540 + 0x19	C++
 	xpcom.dll!nsThread::Main(void * arg=0x00f61100)  Line 119	C++
 	nspr4.dll!_PR_NativeRunThread(void * arg=0x00f611f8)  Line 436 + 0xd	C
 	nspr4.dll!pr_root(void * arg=0x00f611f8)  Line 116 + 0xd	C
 	msvcr70d.dll!_threadstartex(void * ptd=0x00f62198)  Line 241 + 0xd	C
 	kernel32.dll!RegisterWaitForInputIdle()  + 0x43
oops... why is a string bundle being loaded on the socket transport thread. 
that's the real problem here IMO.  PSM should load all of the string bundles it
will need on background threads when it is first initialized.

btw, this stack shows that the IO service as well as the resource protocol
handler are being used on a background thread.  that's also not allowed.

what are the steps required to reproduce this stack?

-> PSM (i'll try to work on a patch)
Status: NEW → ASSIGNED
Component: Networking → Client Library
Product: Browser → PSM
Summary: nsStandardURL not thread-safe → PSM loads string bundles on the socket thread [was: nsStandardURL not thread-safe]
Version: Trunk → unspecified
"PSM should load all of the string bundles it will need on background threads
when it is first initialized."

let me clarify that statement:

   PSM, when initialized on the main thread, should preload all 
   of the string bundles it may need to access from other threads.
Product: PSM → Core
Whiteboard: [kerh-cuz]
Assignee: darin → kengert
Status: ASSIGNED → NEW
QA Contact: benc
QA Contact: ui
The comments in this bug are very helpful.
It confirms that the approach I attempted/proposed in bug 420187 recently might be indeed correct.
Attached patch Patch v1Splinter Review
Is this a valid approach to force loading of the string bundle, or is there a better one?

Will it correctly cause the string bundle to remain cached for later accesses?

This is a first step towards the fix.
I'm not sure if nsNSSComponent init will always happen on the correct thread.
Ftr, only because "[was: nsStandardURL not thread-safe]" is (still) in summary:
notice bug 708935.
reassign bug owner.
mass-update-kaie-20120918
Assignee: kaie → nobody
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: