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: Always 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"; threads->object($threads{$class})->join(); delete($threads{$class}); } } 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"; $thr->join(); } 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 );
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?)
Reproduced, debugging (well, first trying to convert it into a C testcase).
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: /usr/lib/perl5/5.8.0/i386-linux-thread-multi/auto/threads/threads.so /usr/lib/perl5/5.8.0/i386-linux-thread-multi/auto/threads/shared/shared.so 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 being called instead of the expected pthread_create@@GLIBC_2.1
Plus there is a NPTL bug, fixed thusly: 2003-08-07 Jakub Jelinek <jakub> * 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;
glibc side fixed in glibc-2.3.2-71.
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.
Anyone have any clue if this is still an issue? No idea if Chip followed up upstream as mentioned here.
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.
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. ftp://ftp.linux.activestate.com/pub/staff/gsar/APC/perl-5.8.x-diffs/19061.gz ftp://ftp.linux.activestate.com/pub/staff/gsar/APC/perl-5.8.x-diffs/18877.gz