retitle 486069 perl: embedding perl hangs on hppa without PERL_SYS_INIT3() 
since 5.10.0
severity 486069 normal
thanks

On Fri, Jun 13, 2008 at 09:04:09AM +0300, Niko Tyni wrote:

> > The bug is in libperl-dev: the attached autoconf test program from
> > src/modules/Perl/configure.in exits with a timeout after 10 seconds on
> > hppa. I'll clone this against perl and block accordingly.

> The problem was introduced with perl 5.10.0, as pike7.6 7.6.112-1 built
> fine but 7.6.112-1+b1 didn't. However, libperl embedding isn't totally
> broken because the pperl test suite works on 5.10.0.
> 
> I have access to an hppa host where the bug is reproducible, so I'll
> look into it more when I have the time.

It turns out the bug is in the test program, which doesn't use the
PERL_SYS_INIT3 macro. The program is blocking in pthread_mutex_lock()
inside perl_parse():

 #0  0x409b60b4 in nanosleep () from /lib/libpthread.so.0
 #1  0x409b3860 in __pthread_acquire () from /lib/libpthread.so.0
 #2  0x409b3b7c in __pthread_alt_lock () from /lib/libpthread.so.0
 #3  0x409b051c in pthread_mutex_lock () from /lib/libpthread.so.0
 #4  0x405b911c in PerlIOUnix_refcnt_inc (fd=0) at perlio.c:2337
 #5  0x405b9d24 in PerlIOUnix_open (my_perl=0x12050, self=0x405ecc60, 
layers=0x29b58, n=0, 
     mode=0x405dfa99 "r", fd=0, imode=0, perm=0, f=0x29c14, narg=0, args=0x0) 
at perlio.c:2548
 #6  0x405b7990 in PerlIOBuf_open (my_perl=0x12050, self=0x405ecd40, 
layers=0x29b58, n=1, 
     mode=0x405dfa98 "Ir", fd=0, imode=0, perm=0, f=0x0, narg=0, args=0x0) at 
perlio.c:3684
 #7  0x405b88cc in PerlIO_openn (my_perl=0x12050, layers=0x405df9e4 "(Null)", 
mode=0x405dfa98 "Ir", fd=0, 
     imode=0, perm=0, f=0x0, narg=0, args=0x0) at perlio.c:1596
 #8  0x405b8b6c in PerlIO_fdopen (fd=0, mode=0x405dfa98 "Ir") at perlio.c:4988
 #9  0x405b8c94 in PerlIO_stdstreams (my_perl=<value optimized out>) at 
perlio.c:1204
 #10 0x405b8f98 in PerlIO_resolve_layers (my_perl=0x12050, layers=0x0, 
mode=0x405cf094 "r", narg=1, 
     args=0xfb0eda48) at perlio.c:1486
 #11 0x405b8830 in PerlIO_openn (my_perl=0x12050, layers=0x0, mode=0x405cf094 
"r", fd=-1, imode=0, 
     perm=0, f=0x0, narg=1, args=0xfb0eda48) at perlio.c:1568
 #12 0x405b8af4 in PerlIO_open (path=0x405d8968 "/dev/null", mode=0x405cf094 
"r") at perlio.c:4997
 #13 0x40535fb4 in S_parse_body (my_perl=0x12050, env=0x0, xsinit=0) at 
perl.c:3711
 #14 0x40536a20 in perl_parse (my_perl=0x12050, xsinit=0, argc=2, 
argv=0xfb0ed708, env=0x0) at perl.c:1657
 #15 0x0001095c in main (argc=1, argv=0xfb0ed53c, env=0xfb0ed544) at embed.c:27
 
The PERL_SYS_INIT3 macro expands (among other things) to
"MUTEX_INIT(&PL_perlio_mutex)", which is enough to fix the problem.
The need for PERL_SYS_INIT3() has been documented in perlembed.pod since
5.8.1 (upstream change 19147), so this is arguably not a bug in perl at
all.

I assume the difference between hppa and the other architectures is
because hppa still uses linuxthreads instead of NPTL.  There's an ongoing
discussion on the debian-release and debian-hppa lists about switching
to NPTL for hppa too, so the pressing problem just might resolve itself
with time.

I'm leaving this open for now as a place to discuss the implications
of this behaviour change. Somebody (TM) should probably go through all
packages embedding perl and check if they use PERL_SYS_INIT3() and/or
if they hang on hppa.

Downgrading and retitling. I'll file patches for the two known affected
packages.
-- 
Niko Tyni   [EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to