Bug 101767 - perl iThreads app hangs with NPTL
Summary: perl iThreads app hangs with NPTL
Alias: None
Product: Fedora
Classification: Fedora
Component: perl (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
Target Milestone: ---
Assignee: Warren Togami
QA Contact: David Lawrence
Depends On:
Blocks: CambridgeTarget
TreeView+ depends on / blocked
Reported: 2003-08-06 16:30 UTC by Al Tobey
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version: RHEL3U4+
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-23 18:30:34 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Al Tobey 2003-08-06 16:30:49 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703

Description of problem:
I was doing some testing of perl iThreads (use threads;) with the rawhide
glibc/perl 5.8.1rc4 RPMs and couldn't get my test program to behave properly. 
Running it under LD_ASSUME_KERNEL=2.4.19 works, though.  I tried many
combinations of threads and none of them worked without the LD_ASSUME_KERNEL set.

This seems to be Rawhide glibc specific.  I also tested on Taroon (RHAS 3.0
beta1) and RedHat 7.3 with perl 5.8.0 with good results.  Installing
perl-5.8.1-90.rc.4 on Taroon also works.

Version-Release number of selected component (if applicable):
perl-5.8.1-90.rc4.0, glibc-2.3.2-68

How reproducible:

Steps to Reproduce:
1. run script in Additional Information.

Actual Results:  tobeya@linuxws1: >./threads.pl
done creating class threads ...
still waiting for class My, My::Class's thread
still waiting for class My, My::Class's thread
still waiting for class My, My::Class's thread
still waiting for class My, My::Class's thread
still waiting for class My, My::Class's thread
still waiting for class My, My::Class's thread
still waiting for class My, My::Class's thread
still waiting for class My, My::Class's thread
still waiting for class My, My::Class's thread

Expected Results:  tobeya@linuxws1: >LD_ASSUME_KERNEL=2.4.19 ./threads.pl
tid 2 is returning 1
tid 3 is returning 1
done creating class threads ...
still waiting for class My, My::Class's thread
joining thread id 3
joining thread id 2
still waiting for class 's thread
trying to join thread id 1
Joiner thread exiting ...

Additional info:

#!/usr/bin/perl -w
$| = 1;
use strict;

use threads;
use threads::shared;
our %threads : shared;
our $running : shared = 1;

# --------------------------------------------------------------------------- #
# run a thread for joining other threads
async {
    sleep 1;
    while ($running != 0) {
        sleep 1;
        lock( %threads );
        foreach my $class ( keys(%threads) ) {
            next if ( !defined($threads{$class}) );
            print "joining thread id $threads{$class}\n";
    print "Joiner thread exiting ...\n";

# --------------------------------------------------------------------------- #

foreach my $class ( ('My::Class', 'My') ) {
    # let go of the lock as soon as we're done with it by putting it in a block
        lock( %threads );
        $threads{$class} = undef;
    # call startup on each class to in it's own thread
    my $thr = threads->create( sub { $class->startup() } );

print "done creating class threads ...\n";

until ( keys(%threads) == 0 ) {
    sleep 1;
    print "still waiting for class ",join(', ',keys(%threads)),"'s thread\n";
$running = 0;

# join all other threads
foreach my $thr ( threads->list() ) {
    print "trying to join thread id ".$thr->tid()."\n";
exit 0;

# --------------------------------------------------------------------------- #

package My;
sub startup {
    my $type = shift;
    my $self = bless( {}, $type );
    print "tid ".threads->self->tid()." is returning 1\n";
    # store my tid in %threads so it can be joined now that I'm done
        lock( %threads );
        $threads{ref($self)} = threads->self->tid();

package My::Class;
use base qw( My );

Comment 1 Al Tobey 2003-08-06 16:38:15 UTC
Downgraded libc to the Severn's glibc-2.3.2-57 and the problem went away.

Maybe this bug should be moved to glibc (or I should have filed it there in the
first place?)

Comment 2 Jakub Jelinek 2003-08-06 19:14:49 UTC
Reproduced, debugging (well, first trying to convert it into a C testcase).

Comment 3 Jakub Jelinek 2003-08-06 23:36:58 UTC
There is certainly a perl bug here, though whether there is a glibc bug
as well is yet to be proven.
At least following libraries:
were not linked against -lpthread, even though they are using pthread_*
functions provided only by libpthread.
This results in the symbols being non-versioned, and thus
pthread_create@GLIBC_2.0 being called instead of the expected pthread_create@@GLIBC_2.1

Comment 4 Jakub Jelinek 2003-08-07 00:12:36 UTC
Plus there is a NPTL bug, fixed thusly:
2003-08-07  Jakub Jelinek  <jakub@redhat.com>

        * pthread_create.c (__pthread_create_2_0): Clear new_attr.cpuset.

--- libc/nptl/pthread_create.c.jj       2003-08-03 04:15:48.000000000 -0400
+++ libc/nptl/pthread_create.c  2003-08-06 19:46:20.000000000 -0400
@@ -464,6 +464,7 @@ __pthread_create_2_0 (newthread, attr, s
       new_attr.guardsize = ps;
       new_attr.stackaddr = NULL;
       new_attr.stacksize = 0;
+      new_attr.cpuset = NULL;

       /* We will pass this value on to the real implementation.  */
       attr = (pthread_attr_t *) &new_attr;

Comment 5 Jakub Jelinek 2003-08-15 11:47:17 UTC
glibc side fixed in glibc-2.3.2-71.

Comment 6 Chip Turner 2003-08-20 13:20:18 UTC
perl side to explicitly link dlopen'd .so libraries against the same libraries
that link against the main perl isn't likely to go in upstream pre-5.8.1.  will
look into a custom patch on our side and getting upstream buyin for a later release.

Comment 7 Warren Togami 2005-09-07 10:11:45 UTC
Anyone have any clue if this is still an issue?  No idea if Chip followed up
upstream as mentioned here.

Comment 8 Al Tobey 2005-09-07 13:43:54 UTC
Seems to be OK in RHEL3 U4 when I re-run that same script both with RHEL's perl
and mine.   I'm not sure what fixed it, though.   I think the glibc update
following Jakub's note actually fixed it for me.

Comment 9 Al Tobey 2005-09-07 14:06:19 UTC
Here are two patches that I think contain contributions from Chip related to
shared libperl.so and "build issues."   The 18877 patch seems to have the more
interesting changes in it, making changes to the dynamic loader.


Note You need to log in before you can comment on or make changes to this bug.