We have a continuing problem where the callers of ToNewCString() expect the memory to be allocated using NSPR and call PR_Free to free the memory. I thought we were going to change nsString to use NSPR, but it's still using the new operator. The nsString header file doesn't say, and that makes the problem even worse. [E] FMM: Freeing mismatched memory in free {1 occurrence} Address 0x0420a588 points into a C++ new block in heap 0x03c40000 Location of free attempt free [dbgheap.c:925] PR_Free [prmem.c:66] net_OpenCacheFatDB [mkcache.c:262] NET_SetDiskCacheSize [mkcache.c:1298] NET_SetupPrefs [mkgeturl.c:677] NET_FinishInitNetLib [mkgeturl.c:751] NS_InitNetlib(void) [nsNetThread.cpp:97] nsNetlibThread::NetlibThreadMain(void *) [nsNetThread.cpp:219] PR_NativeRunThread [pruthr.c:381] threadstartex [threadex.c:212] lstrcmpiW [KERNEL32.dll] Allocation location new(UINT) [new.cpp:23] nsString::ToNewCString(void)const [nsString.cpp:467] nsNetFile::GetFilePath(char const*,char * *) [nsNetFile.cpp:180] WH_FileName [nsNetStubs.cpp:946] net_OpenCacheFatDB [mkcache.c:252] NET_SetDiskCacheSize [mkcache.c:1298] NET_SetupPrefs [mkgeturl.c:677] NET_FinishInitNetLib [mkgeturl.c:751] NS_InitNetlib(void) [nsNetThread.cpp:97] nsNetlibThread::NetlibThreadMain(void *) [nsNetThread.cpp:219] PR_NativeRunThread [pruthr.c:381] threadstartex [threadex.c:212] lstrcmpiW [KERNEL32.dll]

The real problem is a policy issue. I've done a better job of documenting the issue.

how would I verify this bug? Would it be more appropriate for rickg, kipp or troy to verify?

Troy provide a test case for verification

marking verified, discussed with engineer

As per Troy email 2/9, " it's a programming problem and there is no test case that you can use to confirm the problem or verify that it's fixed." Set to verified as Rick has done better documentation.