Bug 77454

Summary: pthread examples hang while using glibc-2.2.4-*
Product: [Retired] Red Hat Linux Reporter: Robin Holt <redhat-lists>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED WORKSFORME QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2CC: fweimer
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-10-03 10:15:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Robin Holt 2002-11-07 11:21:01 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
While using an ia64 based RedHat 7.2 system, we were noticing pthreaded apps
occassionally stopping.  The best test case was to start a glibc source package
rebuild and then start numerous kernel compiles simultaneously.

We then attempted the same experiment on a 4-way i386 box and got the same
result.  That machine was likewise glibc-2.2.4-30.

An even simpler test program was created.  I will add it at the end of this
description.

We then attempted the test program on an i386 running 8.0.  No sign of the
problem.  Next we tried an i386 running 7.3.  Again no sign.

Next, we took the glibc-2.2.5-40.src.rpm from 7.3 and did a rpm --rebuild on our
7.2 box, installed the resultant packages, and retested.  The problem went away.

My question comes down to how safely an I use the glibc-2.2.5-40 from i386
rebuilt for ia64 on a _PRODUCTION_ ia64 7.2 system?


What follows is the test.  Compile the test as indicated in the comment. 
Usually it immediately returns.  If you then 'ps -ef | grep test', there will be
remaining processes.  If there were none after the first attempt, repeat a
second time and there will be.

--------------------------  test.c  -------------------------------
/*
 * compile with
 *      gcc -g -Wall -o test test.c -lrt
 *
 * execute 
 *      test [<inner_loop_count> [<outer_loop_count>]]
 *
 * Typing:
 *      test
 * with no args usually hangs
 *
 * Test creates timer threads that hang in 
 *      rt_sigsuspend
 *      __sigsuspend
 *      __pthread_wait_for_restart_signal
 *      pthread_cond_wait
 *      thread_func
 *      pthread_start_thread
 *
 */ 

#include <signal.h>
#include <time.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/times.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

int     forks=5;
int     count=5;

void *
slave(void)
{
        timer_t timerid;
        pid_t   pid;
        int     i, status;

        for (i=0; i<forks; i++) {
                if (fork() == 0) {
                        if (timer_create(CLOCK_REALTIME, NULL, &timerid) == -1) 
{
                                perror("timer_create");
                                exit(1);
                        }
                        execlp("/bin/date", "date",  (char *)0);
                }
                pid = wait(&status);
        }

        exit(0);
} 

int
main (int argc, char *argv[])
{
        int i;

        count = argc >= 2 ? atoi(argv[1]) : 5;
        forks = argc >= 3 ? atoi(argv[2]) : 5;

        for (i=0; i<count; i++) {
                if (fork() == 0)
                        slave();
        }

        exit(0);
}


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Run the included test program
2.ps -ef | grep test
3.If there are no remaining processes, repeat a second time
	

Actual Results:  Some processes remain forever.

Expected Results:  No child threads remaining

Additional info:

Comment 1 Ulrich Drepper 2003-04-22 07:34:38 UTC
Do you have a support contract with Red Hat?  If yes, there might be an updated
glibc available.  If not, you cannot get any guarantee for any custom binary. 
Do it at your own responsibility.

Comment 2 Ulrich Drepper 2003-10-03 10:15:48 UTC
No reply in almost 6 months.  Closing as WORKSFORME.