On 12/19/2010 02:27 AM, Nelson Bolyard wrote:
Yes, Mozilla builds its own CRT, which is a modified version of the MSVC
CRT, whose sources come only with the pay (not free) versions of MSVC.
They do this in order to replace MSVC's normal heap code (malloc) with
their own "JEmalloc".
Mozilla's source repository doesn't include ANY of the MSVC source code,
but only includes a ed script that patches that source without including
any of it. Sadly, this means that people with the free MSVC cannot build
MOZCRT19, because they lack the sources to be patched. IMO, this is a
flaw for an open source project, but ... :(
Can you build it against the compiler's CRT if you want to?
Well, I think the big question is: why does the heap allocation fail?
You need to track down where the first error occurs.
My first wild guess is that Matej's PKCS#11 module is doing something bad
to the heap.
Like if Matej's module were linked to some other CRT and an interface
passed memory that way. Historically, having multiple CRTs in the same
process has been a recipe for disaster on Windows. It's gotten better as
Microsoft has switched to using the default global OS heap for everything.
Microsoft actually has a pretty decent set of heap debugging tools:
http://www.google.com/search?q=pageheap
I think this tool was made by their OS development team rather than
their "Visual dotnet 2000 enterprise team architect edition" team. It's
much better, much closer to valgrind. But the trick to using it is to
get everything using the default OS heap, which means actually using the
Release not the Debug Microsoft CRT. Thus JEmalloc would have to be
redirected for testing as well, but just to the GlobalAlloc.
My second one is that NSS or PSM is trying to free to the
MOZCRT17 heap something that was allocated from another heap.
Or perhaps vice versa, but wouldn't that likely have thrown at the point
of the bad free or delete?
- Marsh
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
