Neil wrote, On 2009-03-30 02:10: > Nelson B Bolyard wrote: > >> Neil wrote, On 2009-03-29 17:01: >> >> >>> Firefox may want to switch to using the jemalloc allocator on the >>> Mac. >>> >>> >> Well, I hope it won't mean for the Mac what it has meant on Windows. >> >> On Windows, the JEMalloc code can ONLY be built with the non-free >> "professional" version of Microsoft Visual Studio, and CANNOT be built >> with the free version. Consequently, developers who use the free >> version must build EVERYTHING themselves, and cannot mix and match >> libraries they build with libraries they download from Mozilla's site. >> >> This has greatly increased the perception, among many developers who >> develop for Windows, that Firefox has effectively reverted to being >> MoCo's corporate product, and not quite the truly open product that it >> once was, and still claims to be. It's open, but its components cannot >> be mixed and matched with builds from other builders, even for the same >> platform. >> >> > I'm sure a similar system could be used to enable people to build using > VC++ Express, using the jemalloc allocator only for NS_Alloc/Free etc.
The problem is in the way that Mozilla builds JEMalloc for FF on Windows. They build a replacement for the Microsoft C RunTime Library. This replacement is a hybrid, built in part from JEMalloc source code, and in part from Microsoft's source code for MSVCRT, which source code is ONLY available with the professional edition of the MSVC compiler. There is an "ed" script that modifies the MSVC source, so that not even a single line of the MSVC source code is found in Mozilla's respository that builds the replacement VCRT. So, you cannot build the replacement VCRT without the professional edition compiler, which isn't cheap. Now, you might think that this would not be a problem if the replacements DLL and its companion .lib file (with which one links to use the CRT) were distributed to developers, but, as I understand it, based on the explanation I received from someone at Mozilla, Microsoft's license prohibits any redistribution of that .lib file. >> Which libjar? There are two. NSS has one used in NSS utility >> programs, and Firefox has one. Firefox doesn't use NSS's and NSS >> utilities don't use Firefox's. See >> http://mxr.mozilla.org/mozilla/find?string=jar%2F&tree=mozilla >> > Thanks for the clarification. You're welcome. But please tell us, which libjar has the horrifying number of mismatches? If it's NSS's, we'd like to know about them. >>> pk12util.c: uses PR_Free for a string allocated with malloc, >>> and PORT_ZFree for a string allocated with PL_strdup. >> PORT_ZFree is a wrapper for PR_Free. The question is: is it correct to >> allocate with PL_strdup (part of NSPR) and free with PL_Free (also part >> of NSPR, but part of a separate NSPR shared library) ? I meant PR_Free. There is no PL_Free, AFAIK. >> Today, the answer is almost certainly "No, it's not correct". I wonder >> if we could change that, so that NSPR effectively has just one >> allocator (that is, on heap) used by both PL_ and PR_ functions, or if >> that would break the world as we know it. >> > Well, as I recall, PL_ functions go straight to malloc/free, but the PR_ > functions could be compiled to have their own allocator. There is the > additional issue that those functions live in different libraries, so > that if they were compiled statically then they would still be > mismatcched. Yes, That's precisely the issue to which I was referring. I'd like to have PL_ use PR's allocator, but I don't want to create circular dependencies. I think we'd have to change PR to use an allocator in PL, to keep the dependencies acyclic, and that would be a BIG undertaking. :( > I didn't find any bugs in NSPR. Under which component should I file those > bugs in pk12util? If the bug is in a source file under security/nss/cmd then component "tools". If it's under security/nss/lib then component "libraries". >> By the way, what tool do you use to find these mismatches of allocators >> and deallocators? I think those issues haven't gotten as much >> attention as they deserve simply because we're not aware of tools that >> make it easy. >> >> > I don't have a tool that makes it easy. All I did was piggy-back on a > feature of the MSVC debug heap, Another feature of the professional package only, sadly. > and I deliberately overwrite the MSVC > memory guard areas (which are normally set to 0xFDFDFDFD); for example, > NS_Alloc might write 0x0303FDFD, and NS_Free would check for that value > and overwrite the correct value (thus faking out free), but when there's > a mismatch either NS_Free or free will complain as appropriate. We should do something similar for PR_'s allocator functions. > I actually wanted to audit mailnews, but I had to get the rest of Gecko > working first! Actually, I guess I should be doing more important things > first, such as adding a key for Paste as Quotation... :-) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
