Bug 77454 - pthread examples hang while using glibc-2.2.4-*
Summary: pthread examples hang while using glibc-2.2.4-*
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 7.2
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-11-07 11:21 UTC by Robin Holt
Modified: 2016-11-24 14:57 UTC (History)
1 user (show)

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: ---


Attachments (Terms of Use)

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.


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