malloc options

[Doug Hardie]

On Jul 26, 2008, at 18:47, Ivan Voras wrote:

> 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?

I can't say for sure as I have never looked at all the code.  Part is  
in c though.  I would tend to support that theory except that the area  
being modified is still allocated.  It was never freed.  Its value got  
changed to something that is not in any file on the computer.  It is a  
reasonably recoginizable ascii string, but basically meangineless.   
Also, this app has been running for almost 5 years doing the same  
thing on earlier versions of FreeBSD.  I know at least 6.1, 6.2, 5.4  
5.3 and possibly earlier.  I just don't recall which one was in use  
when we setup the workload that is causing the issue now.  It still  
continues to run just fine on 6.3.

>
>
>> 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

I'll give those a try.

>
>
>>> 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.

This is definitely a difficult issue.  The majority of malloc calls  
are actually within strdup.  There are no frees for any of those  
returned values.  They live till the program ends.

>
>