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