Rich Pizzaro wrote: "I'm not sure who to ask about this, but I had a problem when I added the new prefs calls to my libmime work. The problem turned out that libmime is being called in by core netlib which is on a different thread than apprunner. As a result, we crashed trying to access any prefs because prefs are not thread safe."

M5,P1. Rich, can you provide any more details of the particular way in which the problem occurred? Is netlib on its own thread, or did this happen on the IMAP thread. What prefapi call caused the problem? (was it just reading a pref value?) David B, can you offer me some advice?

M5,P1. Rich, can you provide any more details of the particular way in which the problem occurred? Is netlib on its own thread, or did this happen on the IMAP thread. What prefapi call caused the problem? (was it just reading a pref value?) David B, can you offer me some advice?

I wish IMAP was far along enough that this could be an IMAP problem, but I can state with certainty that this was not an IMAP stream. But core netlib is running on a different thread, as Rich says, though I thought the proxied stream stuff returned us to the mozilla thread in the stream consumption.

I am being called in as a stream converter from core netlib and that is where the crashing occurs (any time I access a pref). I will try to put get a stack trace of the problem after I get my tree built. - rhp

I was curious about what we would immediately crash when reading a pref. Seems unlikely that we're racing on something, and getting a pref shouldn't fire any callbacks. I thought we should understand why this crashed before proposing any specific fix, like monitors around the libpref API.

Why are my comments showing up as double-spaced, when everybody else's are single-spaced? Is it because I'm using a Macintosh? This only started to happen a couple of days ago.

Ok, here is the stack trace when we crash when accessing threads off of the main UI thread. - rhp NTDLL! 77f76274() js_Lock(JSThinLock * 0x00bcccdc, long 12395008) line 616 + 39 bytes js_AtomizeString(JSContext * 0x00be26d0, JSString * 0x0198f680, unsigned int 2) line 462 + 24 bytes js_AtomizeChars(JSContext * 0x00be26d0, const unsigned short * 0x00bcf9d0, unsigned int 9, unsigned int 0) line 542 + 20 bytes js_GetToken(JSContext * 0x00be26d0, JSTokenStream * 0x00bcf748) line 721 + 36 bytes js_Parse(JSContext * 0x00be26d0, JSObject * 0x00e41e48, JSTokenStream * 0x00bcf748, JSCodeGenerator * 0x0198f81c) line 218 + 13 bytes CompileTokenStream(JSContext * 0x00be26d0, JSObject * 0x00e41e48, JSTokenStream * 0x00bcf748, void * 0x00bcf748) line 1958 + 21 bytes JS_CompileUCScriptForPrincipals(JSContext * 0x00be26d0, JSObject * 0x00e41e48, JSPrincipals * 0x00000000, const unsigned short * 0x00e95970, unsigned int 829, const char * 0x00cd65b4, unsigned int 0) line 2034 + 21 bytes JS_EvaluateUCScriptForPrincipals(JSContext * 0x00be26d0, JSObject * 0x00e41e48, JSPrincipals * 0x00000000, const unsigned short * 0x00e95970, unsigned int 829, const char * 0x00cd65b4, unsigned int 0, long * 0x0198f954) line 2319 + 33 bytes JS_EvaluateUCScript(JSContext * 0x00be26d0, JSObject * 0x00e41e48, const unsigned short * 0x00e95970, unsigned int 829, const char * 0x00cd65b4, unsigned int 0, long * 0x0198f954) line 2304 + 35 bytes JS_EvaluateScript(JSContext * 0x00be26d0, JSObject * 0x00e41e48, const char * 0x03735c9e, unsigned int 829, const char * 0x00cd65b4, unsigned int 0, long * 0x0198f954) line 2271 + 33 bytes PREF_EvaluateConfigScript(const char * 0x03735c9e, unsigned int 829, const char * 0x00cd65b4, int 0, int 0, int 1) line 581 + 35 bytes pref_OpenFile(const char * 0x00cd65b4, int 1, int 0, int 0, int 1) line 267 + 27 bytes PREF_Init(const char * 0x00cd65b4) line 443 + 17 bytes nsPref::Startup(nsPref * const 0x00be00a0, const char * 0x00cd65b4) line 269 + 9 bytes nsMimeEmitter::nsMimeEmitter() line 95 NS_NewMimeEmitter(nsIMimeEmitter * * 0x0198fa1c) line 44 + 27 bytes nsMsgFactory::CreateInstance(nsMsgFactory * const 0x03733ea0, nsISupports * 0x00000000, const nsID & {...}, void * * 0x036fb198) line 132 + 9 bytes nsComponentManagerImpl::CreateInstance(nsComponentManagerImpl * const 0x00bd4450, const nsID & {...}, nsISupports * 0x00000000, const nsID & {...}, void * * 0x036fb198) line 1112 + 24 bytes nsComponentManager::CreateInstance(const nsID & {...}, nsISupports * 0x00000000, const nsID & {...}, void * * 0x036fb198) line 68 MimePluginInstance::Initialize(MimePluginInstance * const 0x036fb180, nsINetOStream * 0x03733ef0, const char * 0x036fd450) line 221 + 26 bytes NET_PluginStream(int 38, void * 0x00000000, URL_Struct_ * 0x036fd570, MWContext_ * 0x036fd2e0) line 234 NET_StreamBuilder(int 38, URL_Struct_ * 0x036fd570, MWContext_ * 0x036fd2e0) line 238 + 24 bytes net_setup_file_stream(_ActiveEntry * 0x036fd220) line 783 + 25 bytes net_ProcessFile(_ActiveEntry * 0x036fd220) line 1319 + 9 bytes NET_ProcessNet(PRFileDesc * 0x00000000, int 1) line 3355 + 13 bytes nsNetlibThread::NetlibMainLoop() line 303 + 9 bytes nsNetlibThread::NetlibThreadMain(void * 0x00c04870) line 259 _PR_NativeRunThread(void * 0x00c04680) line 379 + 13 bytes _threadstartex(void * 0x00c044d0) line 212 + 13 bytes KERN

First thing that occurs to me here is to ask why the constructor of nsMimeEmitter is calling nsPref::Startup(). Once is enough, and prefs are initialized in main(). Moreover, this call to Startup() is almost surely using a different file path from the "real" prefs file. Try removing that call...

The more I think about it, the more I'm sure this is a big part of the problem. Opening and rearsing the prefs file every time you want to talk to prefs is a very bad idea, and pretty much guaranteed not to be threadsafe.

You're a wizard! That did it...and I'm reading prefs just fine now from libmime!! - rhp

The double-spacing problem John mentions is covered by bug 4928. Any further discussion about that Bugzilla problem should be done there.

marking verified as this was fixed by the reporter

Moving all libPref component bugs to new Preferences: Backend component. libPref component will be deleted.