malloc options

[Kris Kennaway]

Doug Hardie wrote:
> 
> On Jul 26, 2008, at 19:03, Giorgos Keramidas wrote:
> 
>> While that's understandable, the current malloc() has undergone quite
>> extensive testing by Jason Evans and a lot of people who use it in
>> FreeBSD 7.X or later.  Its ability to expose bugs in this way was deemed
>> important enough that it is now used by other projects too.
> 
> while in general I like the new approach, this problem has been a 
> killer.  I did find a number of errors in my own code where I was not 
> allocating enough space for some things.  Those showed up instantly with 
> 7.0 and were easy to fix.

I am not sure you are getting the point.  The bugs are exposed by 
accident, not by design, because the programs were only working by 
accident, not by design.  There will probably be a new subset of buggy 
programs that sometimes fail to crash under the new allocator.

>> What Kris wrote in:
>>
>>    Finally, there is no way to revert to the "old approach"
>>    because the new allocator is completely new; it allocates
>>    memory based on its own strategy.  None of the malloc options
>>    affect the behaviour of correct programs (but some of them
>>    can help to improve performance, or to debug incorrect
>>    programs).
>>
>> is a bit important.  Even if you tweak enough options the new malloc()
>> may *not* work similarly enough for the program to keep working.  If you
>> are lsing money _right_ _now_ because of problems in the program, it may
>> be worth going back to 6-STABLE and the old malloc() until the bugs of
>> the program have been fixed by the developers.
> 
> Unfortunately that is not possible.  We upgraded the hardware and some 
> of the components were not supported very well under 6.x.  Despite 
> several weeks of testing of the new hardware and 7.0, the problem did 
> not arise till several weeks after going into production.  It takes 
> about a week of real time before the problem tends to become visible.  
> By compressing the workload I have been able to setup a test machine 
> such that it takes 2-4 days before it occurs.

Your choices are:

1) Debug the application

2) Build a 6.x binary and use that forever under compatibility

3) Compile your own private copy of phkmalloc and link your application 
to it, and hope the bugs never return.

Kris