From owner-freebsd-current@FreeBSD.ORG Thu Apr 19 21:47:53 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6272716A400 for ; Thu, 19 Apr 2007 21:47:53 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id 4AAA113C458 for ; Thu, 19 Apr 2007 21:47:53 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from [127.0.0.1] (canonware.com [64.183.146.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTP id 1874C1298E2; Thu, 19 Apr 2007 14:21:34 -0700 (PDT) Message-ID: <4627DD1B.2080806@freebsd.org> Date: Thu, 19 Apr 2007 14:20:27 -0700 From: Jason Evans User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Anton Yuzhaninov References: <313993633.20070419232238@citrin.ru> In-Reply-To: <313993633.20070419232238@citrin.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: clamd memory corruption (may be jemalloc related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 21:47:53 -0000 Anton Yuzhaninov wrote: > I try to test clamav 0.90.2 on current and got strange errors: > > LibClamAV Warning: Multipart/alternative MIME message contains no boundary header > LibClamAV Warning: Multipart/ZZZZZZZZZZZZÇÇÇÇÀå MIME message contains no boundary header > LibClamAV Warning: Multipart/related MIME message contains no boundary header > > And sometimes clamd segfaults. > > This Warnings issued randomly and it looks like race condition. > > This problem occurred only when running two or more clamdscan > processes in parallel. With one process no warnings on same test ^^^^^^^^^ > messages. Processes, not threads? If so, there's really no way malloc can be to blame for a race condition. The only race condition issue for malloc that I know of has to do with rtld not replacing the libc spinlock stubs with threaded implementations. However, I am pretty sure that this problem only shows up when versioned symbols are enabled. malloc's locking methodology is pretty straightforward, which makes me reasonably confident about its correctness. If your debugging efforts point you at malloc, you should try reverting to phkmalloc to see if that makes the problem go away. Jason