From owner-freebsd-stable@FreeBSD.ORG Mon Sep 4 00:52:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2237416A4DA for ; Mon, 4 Sep 2006 00:52:09 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A95D943D46 for ; Mon, 4 Sep 2006 00:52:08 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GK2gx-00027w-Bw for freebsd-stable@freebsd.org; Mon, 04 Sep 2006 02:51:59 +0200 Received: from cmung3243.cmu.carnet.hr ([193.198.140.195]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Sep 2006 02:51:59 +0200 Received: from ivoras by cmung3243.cmu.carnet.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Sep 2006 02:51:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 04 Sep 2006 02:51:56 +0200 Lines: 17 Message-ID: References: <1D1B7B79-6BF0-4316-BC96-4287669BF778@lassitu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cmung3243.cmu.carnet.hr User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) In-Reply-To: <1D1B7B79-6BF0-4316-BC96-4287669BF778@lassitu.de> Sender: news Subject: Re: malloc(): warning: recursive call X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2006 00:52:09 -0000 Stefan Bethke wrote: > mail in malloc(): warning: recursive call > Cosmic rays? Anything I could try to find the cause? I know what it is, but you won't going to like it. As far as I understand this happens when a process gets a signal in the middle of using malloc(), and the signal handler also uses malloc(). The solution would be not to use malloc() in a signal handler, but this is tricky since unknown code can use malloc() (e.g. printf()?). This appears to be "undefined" by standards, but GNU libc allows it because it makes sense, while phkmalloc dissallows it, causing (me) considerable problems with certain applications. I hope jemalloc is better in this respect :) I don't know how it happened in mail(1) if mail(1) is the FreeBSD version.