Bug 77454 - pthread examples hang while using glibc-2.2.4-*
pthread examples hang while using glibc-2.2.4-*
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-07 06:21 EST by Robin Holt
Modified: 2016-11-24 09:57 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-03 06:15:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robin Holt 2002-11-07 06:21:01 EST
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 03:34:38 EDT
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 06:15:48 EDT
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.