Neil wrote, On 2009-04-02 01:19:
Nelson Bolyard wrote:
If you have public redistributable header files that declare the MSVCRT
memory guards, please send a pointer to them. Thanks.
I can't actually find the documentation I originally read about it; this
is the nearest that I get from
Nelson Bolyard wrote:
Neil, if your code to do this is in a patch or checked in somewhere, a pointer
to that code would be appreciated.
I was going to email you a diff, but it turns out that there's an error
in my methodology and I wasn't catching people misusing PL_strfree :-(
--
Nelson Bolyard wrote:
If you have public redistributable header files that declare the MSVCRT memory
guards, please send a pointer to them. Thanks.
I can't actually find the documentation I originally read about it; this
is the nearest that I get from a search:
Nelson Bolyard wrote:
Benjamin Smedberg wrote, On 2009-03-31 08:35:
In the other cases, we should just fix the bug, which is (I think) why Neil
posted originally.
I wish him Godspeed in fixing (or even filing) those bugs.
I filed bugs 486404/5 yesterday, and have a possible patch
Benjamin Smedberg wrote, On 2009-03-31 08:35:
On 3/30/09 5:34 PM, Nelson B Bolyard wrote:
The problem is mixing DLLs that use standard VCRT with those that use
Mozilla's modified VCRT.
As long as there are bugs in the browser of the sort that Neil has
found, developers of libraries upon
Nelson B Bolyard wrote:
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
Nelson B Bolyard wrote:
The problem is in the way that Mozilla builds JEMalloc for FF on Windows. They
build a replacement for the Microsoft C RunTime Library.
Ah, but I'm hoping that any solution that they manage to implement for
the Mac will be portable to VC Express, since it will only
On Sun, Mar 29, 2009 at 5:01 PM, Neil n...@parkwaycc.co.uk wrote:
Using the above criteria, I found the following allocator mismatches under
security/*
nsNSSCallbacks.cpp: HandshakeCallback calls Adopt(cipherName) instead of
Assign and PORT_Free. In fact, it can leak cipherName
On 3/30/09 5:34 PM, Nelson B Bolyard wrote:
The problem is mixing DLLs that use standard VCRT with those that use
Mozilla's modified VCRT.
As long as there are bugs in the browser of the sort that Neil has found,
developers of libraries upon which the browser depends, who develop with
the
Neil wrote:
Nelson B Bolyard wrote:
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.
I use VC2005Express...
Hmm. Perhaps it is the source code to the debug RTL that is only
Jean-Marc Desperrier wrote:
Nelson B Bolyard wrote:
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
ran all the mochitests (which include
some SSL) and I could only find a few (20) allocator mismatches in
Gecko/Toolkit. By comparison, there are a horrifying number of allocator
mismatches in mailnews (nsDirPrefs.cpp on its own manages to use one
deallocator for a variable allocated by one
mismatches in Gecko/Toolkit. By comparison, there are a
horrifying number of allocator mismatches in mailnews (nsDirPrefs.cpp on its own manages to
use one deallocator for a variable allocated by one of three allocators) and several in
libjar, narrowly relegating you to third in a hypothetical
On 3/30/09 4:00 AM, Nelson B Bolyard wrote:
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
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
currently lumping PR_smprintf_free in
with free, and PORT_Free with whatever it calls.
I instrumented the code and I ran all the mochitests (which include some
SSL) and I could only find a few (20) allocator mismatches in
Gecko/Toolkit. By comparison, there are a horrifying number of allocator
16 matches
Mail list logo
