Date: Sun, 27 Jul 2008 03:47:30 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-questions@freebsd.org Subject: Re: malloc options Message-ID: <g6gk3j$fnq$1@ger.gmane.org> In-Reply-To: <B20991AB-6D2F-4E9E-BC68-2073EFE598AF@lafn.org> References: <EE1CF633-524E-4AE3-8224-685D71652F36@lafn.org> <488BBCFD.1090309@FreeBSD.org> <B20991AB-6D2F-4E9E-BC68-2073EFE598AF@lafn.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIi9OyldnAQVacBcgRApwMAKCl4XZwGsgGVHL1jCqr1sfWWOT1oACgpHcx prCRuPgV2Bp1vhPa+2qyYcg= =o5fV -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?g6gk3j$fnq$1>