malloc options

[Ivan Voras]

Doug Hardie wrote:

>> If you did recompile it and it is behaving differently then it is 
>> probably because your program contains bugs in how it manages memory 
>> that happened to be working by accident with the old memory allocator. 
>> e.g. because you were making use of memory after it had been freed, 
>> but before the allocator returned it to some other malloc() call.
> 
> That is certainly possible.  However, the program has worked under 
> considerable load for many years with versions 3.7 to 6.2.  Problems 
> only occur with 7.0.  The program is quite complex and big.  It uses 

The memory allocator was the same between 3.7 and 6.x - it only changed 
in 7.0. Your description looks like a use-after-free bug. Your 
application is in C, not C++, right?

> probably hundreds of mallocs in a typical use.  The problems only occur 
> reasonably randomly and only under quite heavy load.  The developer is 
> looking into it, but the problem only occurs on FreeBSD 7.0, not any 
> other Unix systems.  In the meantime I am losing money because of it.

Some generic things to try:
- add debug flags to malloc.conf, especially "J", maybe "X" and "P" and 
see if anything abnormal comes up. If it does, the bug is in the program.
- run it on an older version of FreeBSD with debugging flags (for the 
old malloc: "J", "X" and "Z"), also look for problems.
- link with an alternative malloc, there are several in ports
- link with a debugging malloc, try to see if there are bugs

>> 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).
> 
> Not surprising but I seem to recall that when it was first introduced 
> into stable that there was some discussion on how to make it look more 
> like the old malloc.  I couldn't find that via a search though.

You can never make it look like the old malloc - that was the point of 
introducing it. There could be a bug in the new malloc, but many complex 
programs are running fine on it so the chances are slim.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20080727/d4dddf17/signature.pgp