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.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
