Date: Fri, 20 Apr 2007 19:50:01 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Anton Yuzhaninov <citrin@citrin.ru> Cc: freebsd-current@freebsd.org Subject: Re: clamd memory corruption (may be jemalloc related) Message-ID: <20070420095001.GB5257@turion.vk2pj.dyndns.org> In-Reply-To: <334983330.20070420032226@citrin.ru> References: <313993633.20070419232238@citrin.ru> <4627DD1B.2080806@freebsd.org> <144280354.20070420023353@citrin.ru> <20070419223903.GA87190@xor.obsecurity.org> <334983330.20070420032226@citrin.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
--oC1+HKm2/end4ao3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Apr-20 03:22:26 +0400, Anton Yuzhaninov <citrin@citrin.ru> wrote: >Clamav code quality is low, and probably it has bugs :( >But not obvious how to find this bugs. This smells like memory is being allocated in one thread and then being referenced in another thread before it is initialised. My initial suggestion is to put wrappers around malloc(3) family calls (or the program's own internal wrapper functions) that dump __FILE__, __LINE__ and pthread_self(), together with size and address information. The core dump will let you identify the thread that has detected the problem as well as the offending block of memory. The malloc debug output will let you detect where that block of memory is being allocated. It's then just a simple matter of working out the path from the latter to the former :-). Of course, since this appears to be a race condition between threads, it's quite likely it will be a heisenbug. --=20 Peter Jeremy --oC1+HKm2/end4ao3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGKIzJ/opHv/APuIcRArTLAKC+KL4EFUfudRxVDX+4vxsNxQebZwCgqe2j gALvToMT2h9FdWObrw6Hvj4= =iI2w -----END PGP SIGNATURE----- --oC1+HKm2/end4ao3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070420095001.GB5257>