Date: Wed, 12 Mar 2008 10:31:33 +0100 From: Anton Berezin <tobez@tobez.org> To: Jeremy Messenger <mezz7@cox.net> Cc: freebsd-perl@freebsd.org Subject: Re: Perl malloc doesn't work in FreeBSD 7.x with xchat anymore. Message-ID: <20080312093133.GA59094@heechee.tobez.org> In-Reply-To: <op.t7uze9hg9aq2h7@mezz.mezzweb.com> References: <op.t7pyrhig9aq2h7@mezz.mezzweb.com> <20080311145555.GK53444@heechee.tobez.org> <op.t7uze9hg9aq2h7@mezz.mezzweb.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 11, 2008 at 10:46:11AM -0500, Jeremy Messenger wrote: > On Tue, 11 Mar 2008 09:55:55 -0500, Anton Berezin <tobez@tobez.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080312093133.GA59094>