Perl malloc doesn't work in FreeBSD 7.x with xchat anymore.
tobez at tobez.org
Wed Mar 12 09:31:36 UTC 2008
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 at 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
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.
We're going for 'working' here. 'clean' is for people with skills...
-- Flemming Jacobsen
More information about the freebsd-perl