From owner-freebsd-perl@FreeBSD.ORG Wed Mar 12 09:31:35 2008 Return-Path: Delivered-To: freebsd-perl@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCA9C1065670 for ; Wed, 12 Mar 2008 09:31:35 +0000 (UTC) (envelope-from tobez@tobez.org) Received: from heechee.tobez.org (heechee.tobez.org [194.255.56.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9B5198FC1F for ; Wed, 12 Mar 2008 09:31:35 +0000 (UTC) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id A3E716D413; Wed, 12 Mar 2008 10:31:33 +0100 (CET) Date: Wed, 12 Mar 2008 10:31:33 +0100 From: Anton Berezin To: Jeremy Messenger Message-ID: <20080312093133.GA59094@heechee.tobez.org> References: <20080311145555.GK53444@heechee.tobez.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Powered-By: FreeBSD http://www.freebsd.org/ User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-perl@freebsd.org Subject: Re: Perl malloc doesn't work in FreeBSD 7.x with xchat anymore. X-BeenThere: freebsd-perl@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: maintainer of a number of perl-related ports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 09:31:36 -0000 On Tue, Mar 11, 2008 at 10:46:11AM -0500, Jeremy Messenger wrote: > On Tue, 11 Mar 2008 09:55:55 -0500, Anton Berezin wrote: > >> On Sat, Mar 08, 2008 at 04:43:55PM -0600, Jeremy Messenger wrote: >>> See here: http://www.freebsd.org/cgi/query-pr.cgi?pr=121472 >>> Backtraces: http://people.freebsd.org/~mezz/gdb/gdb-xchat.txt >>> It works ok in FreeBSD 6.x, but not FreeBSD 7.x. If I reinstall perl5.8 >>> with WITHOUT_PERL_MALLOC and it solves the problem of xchat with perl >>> plugins crash in FreeBSD 7.x. I have no idea where I am supposed to look >>> at. Do anyone know if this issue will be fixed in Perl 5.10? >> I do not believe it is a Perl issue at all. It is indicated by the >> backtrace that Perl malloc's service areas are corrupted. > marcus thinks that it's possible that Perl malloc VS jemalloc issue. Why > blame on xchat if it works perfect with Perl built with > WITHOUT_PERL_MALLOC? Maybe it's me that I don't understand. ;-) Alright, moving the discussion away from a somewhat metaphysical plane... I did a little bit of debugging yesterday. No conclusive results yet, but here are some datapoints: The trace observed (an apparently endless loop of Perl_malloc()/PerlIO_allocate()/PerlIO_stdstreams()/Perl_PerlIO_stderr()) is because of a minor bug in perl when perl malloc is in use. When perl interpreter instance is being constructed (during perl_alloc() call), some memory is allocated. If this fails, perl's malloc implementation tries to print some diagnostic messages to standard error. However, since perl is compiled with its own stdio replacement, this action requires some memory being allocated (at least until an instance of perl interpreter is constructed). I can see some protections in perl's malloc.c against just such a case, with a fall-back to unix IO using write(2), but for some reason in this particular instance this protection fails. Hence the loop. In my tests I modified perl to use "normal" stdio within malloc.c, and this reveals the actual problem: During perl_alloc() the very first call to sbrk() fails with ENOMEM. This reinforces my suspicions about the differences between jemalloc and phkmalloc, possibly in a threaded program, being the culprit. However a naive test program that simply allocates some memory with jemalloc before constructing perl interpreter does not fail. More debugging is necessary. Cheers, \Anton. -- We're going for 'working' here. 'clean' is for people with skills... -- Flemming Jacobsen