From owner-freebsd-questions@FreeBSD.ORG Sun Jul 27 01:47:41 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EF9B1065674 for ; Sun, 27 Jul 2008 01:47:41 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id C63528FC1A for ; Sun, 27 Jul 2008 01:47:40 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KMvMI-0006qy-5H for freebsd-questions@freebsd.org; Sun, 27 Jul 2008 01:47:38 +0000 Received: from 78-0-85-142.adsl.net.t-com.hr ([78.0.85.142]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Jul 2008 01:47:38 +0000 Received: from ivoras by 78-0-85-142.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Jul 2008 01:47:38 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-questions@freebsd.org From: Ivan Voras Date: Sun, 27 Jul 2008 03:47:30 +0200 Lines: 72 Message-ID: References: <488BBCFD.1090309@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6D50A49D044ABD83FF8E8B8B" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-85-142.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: malloc options X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2008 01:47:41 -0000 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--