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>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6D50A49D044ABD83FF8E8B8B Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Doug Hardie wrote: >> If you did recompile it and it is behaving differently then it is=20 >> probably because your program contains bugs in how it manages memory=20 >> that happened to be working by accident with the old memory allocator.= =20 >> e.g. because you were making use of memory after it had been freed,=20 >> but before the allocator returned it to some other malloc() call. >=20 > That is certainly possible. However, the program has worked under=20 > considerable load for many years with versions 3.7 to 6.2. Problems=20 > only occur with 7.0. The program is quite complex and big. It uses=20 The memory allocator was the same between 3.7 and 6.x - it only changed=20 in 7.0. Your description looks like a use-after-free bug. Your=20 application is in C, not C++, right? > probably hundreds of mallocs in a typical use. The problems only occur= =20 > 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=20 > 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=20 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=20 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=20 >> 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=20 >> debug incorrect programs). >=20 > Not surprising but I seem to recall that when it was first introduced=20 > 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=20 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. --------------enig6D50A49D044ABD83FF8E8B8B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----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----- --------------enig6D50A49D044ABD83FF8E8B8B--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?g6gk3j$fnq$1>