Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Jul 2010 09:23:18 +0000 (UTC)
From:      Janne Snabb <snabb@epipe.com>
To:        Rainer Hurling <rhurlin@gwdg.de>
Cc:        skv@freebsd.org, freebsd-ports@freebsd.org, Mario Sergio Fujikawa Ferreira <lioux@freebsd.org>
Subject:   Re: lang/perl5.12 segfault (amd64 - 8-STABLE)
Message-ID:  <alpine.BSF.2.00.1007170911460.9805@tiktik.epipe.com>
In-Reply-To: <alpine.BSF.2.00.1007170744070.9805@tiktik.epipe.com>
References:  <20100717041919.70411.qmail@exxodus.fedaykin.here> <4C414AB5.1060305@gwdg.de> <alpine.BSF.2.00.1007170744070.9805@tiktik.epipe.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 17 Jul 2010, Janne Snabb wrote:

> It is somehow related to the "Perl_debug_log" which is the first
> argument of PerlIO_printf. But I can not figure out why, too many
> layers of #defines and calls within calls.

The problem seems to go away when threads are disabled.

The problematic line 311 in util.c expands to quite a horrible mess
(found this out by doing make util.i):

(void)( { if ((PL_curinterp)) { PerlInterpreter* my_perl __attribute__((unused)) = ((PerlInterpreter *)pthread_getspecific(PL_thr_key)); if (((my_perl->Idebug) & 0x00000080)) {(my_perl->Idebug)&=~0x00000080; PerlIO_printf(Perl_PerlIO_stderr(my_perl), "0x%""lx"": (%05ld) calloc %ld x %ld bytes\n",(UV)(ptr),(long)(my_perl->Ian)++,(long)count,(long)total_size); (my_perl->Idebug)|=0x00000080;} } } );

The problem is that my_perl here is NULL pointer. PL_thr_key which
is given to pthread_getspecific() to get my_perl is zero.

(gdb) p my_perl
$1 = (PerlInterpreter *) 0x0
(gdb) p PL_thr_key
$2 = 0
(gdb)

Someone who understands the perl threading internals needs to figure
this out.

--
Janne Snabb / EPIPE Communications
snabb@epipe.com - http://epipe.com/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1007170911460.9805>