* Bug in pthread glibc 7.0 & 7.1
@ 2001-10-01 23:52 TWEDE,ROGER (HP-Boise,ex1)
2001-10-02 0:10 ` H . J . Lu
0 siblings, 1 reply; 4+ messages in thread
From: TWEDE,ROGER (HP-Boise,ex1) @ 2001-10-01 23:52 UTC (permalink / raw)
To: 'linux-mips@oss.sgi.com'
The following code reveals a bug in the MIPS Gnu C Libraries available via
ftp on oss.sgi.com (ftp.linux.sgi.com).
The bug is posix thread related and occurs when using the libc and
libpthread versions available at:
/pub/linux/mips/redhat/7.1/RPMS/mipsel/glibc*
The bug also appears to exist in:
/pub/linux/mips/mipsel-linux/RedHat-7.0/RPMS/mipsel/glibc*
The bug does not exist in earlier versions of the pthread library, or on the
non-MIPS (non-SGI) distributions. (ie. RedHat 7.0 for ix86 does not exhibit
a failure with this code, but RedHat 7.0/7.1 on mips does)
Upon failure the following code sequence will core dump (SEGV) instead of
exiting normally.
Thanks,
Roger Twede
Engineer/Scientist
Hewlett Packard Company
// CODE STARTS BELOW
#include <assert.h>
#include <pthread.h>
#include <sched.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
struct ThreadStartInfo {
pthread_mutex_t InitCompleteMutex;
pthread_cond_t InitCompleteCond;
void * (*Func)(void *);
void * Arg;
int Priority;
char * ThreadName;
unsigned char InitCompleteCount;
};
static void * StartFunction(void * Arg)
{
struct ThreadStartInfo * StartInfo = (struct ThreadStartInfo *) Arg;
int result;
void * retVal = 0;
assert(Arg != NULL);
result = pthread_mutex_lock(&(StartInfo->InitCompleteMutex));
assert(result == 0);
printf("pid=%d thread mutex locked at x%x\n", getpid(),
&(StartInfo->InitCompleteMutex));
StartInfo->InitCompleteCount = 1;
result = pthread_cond_signal(&(StartInfo->InitCompleteCond));
assert(result == 0);
printf("pid=%d thread cond signal sent, unlocking at 0x%x\n", getpid(),
&(StartInfo->InitCompleteMutex));
result = pthread_mutex_unlock(&(StartInfo->InitCompleteMutex));
assert(result == 0);
printf("pid=%d thread unlocked\n", getpid());
sched_yield();
printf("pid=%d yielded and back again\n", getpid());
return(retVal);
}
int main(void)
{
pthread_t ThreadObject;
struct ThreadStartInfo StartInfo;
pthread_mutexattr_t mutexAttr;
pthread_attr_t threadAttr;
pthread_condattr_t condAttr;
int result = 0;
StartInfo.ThreadName = "mythread";
result = pthread_mutexattr_init(&mutexAttr);
assert(result == 0);
printf("pid=%d Init mutex\n", getpid());
result = pthread_mutex_init(&(StartInfo.InitCompleteMutex), &mutexAttr);
assert(result == 0);
result = pthread_condattr_init(&condAttr);
assert(result == 0);
result = pthread_cond_init(&(StartInfo.InitCompleteCond), &condAttr);
assert(result == 0);
StartInfo.InitCompleteCount = 0;
pthread_mutex_lock(&(StartInfo.InitCompleteMutex));
printf("pid=%d About to create thread: %s\n", getpid(),
StartInfo.ThreadName);
result = pthread_attr_init(&threadAttr);
assert(result == 0);
result = pthread_create(&ThreadObject,
&threadAttr,
&StartFunction,
(void *)&StartInfo);
assert(result == 0);
while ((result == 0) && (StartInfo.InitCompleteCount == 0))
{
do
{
printf("pid=%d about to cond_wait for %s init 1.\n", getpid(),
StartInfo.ThreadName);
result = pthread_cond_wait(&(StartInfo.InitCompleteCond),
&(StartInfo.InitCompleteMutex));
printf("pid=%d back from cond_wait for %s init 1. result=%d\n",
getpid(), StartInfo.ThreadName, result);
} while (result == EINTR);
}
result = pthread_mutex_unlock(&(StartInfo.InitCompleteMutex));
assert(result == 0);
getchar();
return 0;
}
// CODE ABOVE
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bug in pthread glibc 7.0 & 7.1
2001-10-01 23:52 Bug in pthread glibc 7.0 & 7.1 TWEDE,ROGER (HP-Boise,ex1)
@ 2001-10-02 0:10 ` H . J . Lu
2001-10-02 12:09 ` Robin Humble
0 siblings, 1 reply; 4+ messages in thread
From: H . J . Lu @ 2001-10-02 0:10 UTC (permalink / raw)
To: TWEDE,ROGER (HP-Boise,ex1); +Cc: 'linux-mips@oss.sgi.com'
On Mon, Oct 01, 2001 at 07:52:15PM -0400, TWEDE,ROGER (HP-Boise,ex1) wrote:
>
>
> The following code reveals a bug in the MIPS Gnu C Libraries available via
> ftp on oss.sgi.com (ftp.linux.sgi.com).
>
> The bug is posix thread related and occurs when using the libc and
> libpthread versions available at:
> /pub/linux/mips/redhat/7.1/RPMS/mipsel/glibc*
>
> The bug also appears to exist in:
> /pub/linux/mips/mipsel-linux/RedHat-7.0/RPMS/mipsel/glibc*
>
> The bug does not exist in earlier versions of the pthread library, or on the
> non-MIPS (non-SGI) distributions. (ie. RedHat 7.0 for ix86 does not exhibit
> a failure with this code, but RedHat 7.0/7.1 on mips does)
>
> Upon failure the following code sequence will core dump (SEGV) instead of
> exiting normally.
>
>
On RedHat 7.1/mips:
# gcc pthread.c -o mips -lpthread -Wall
pthread.c: In function `StartFunction':
pthread.c:64: warning: unsigned int format, pointer arg (arg 3)
pthread.c:69: warning: unsigned int format, pointer arg (arg 3)
# ./mips
pid=21905 Init mutex
pid=21905 About to create thread: mythread
pid=21905 about to cond_wait for mythread init 1.
pid=21907 thread mutex locked at x7fff79c8
pid=21907 thread cond signal sent, unlocking at 0x7fff79c8
pid=21907 thread unlocked
pid=21905 back from cond_wait for mythread init 1. result=0
pid=21907 yielded and back again
# rpm -q glibc
glibc-2.2.4-11.2
H.J.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bug in pthread glibc 7.0 & 7.1
2001-10-02 0:10 ` H . J . Lu
@ 2001-10-02 12:09 ` Robin Humble
2001-10-02 16:14 ` H . J . Lu
0 siblings, 1 reply; 4+ messages in thread
From: Robin Humble @ 2001-10-02 12:09 UTC (permalink / raw)
To: linux-mips; +Cc: roger_twede
H.J. wrote:
>On Mon, Oct 01, 2001 at 07:52:15PM -0400, TWEDE,ROGER (HP-Boise,ex1) wrote:
>> The following code reveals a bug in the MIPS Gnu C Libraries available via
>> ftp on oss.sgi.com (ftp.linux.sgi.com).
>> ...
>On RedHat 7.1/mips:
>
># gcc pthread.c -o mips -lpthread -Wall
>pthread.c: In function `StartFunction':
>pthread.c:64: warning: unsigned int format, pointer arg (arg 3)
>pthread.c:69: warning: unsigned int format, pointer arg (arg 3)
># ./mips
>pid=21905 Init mutex
>pid=21905 About to create thread: mythread
>pid=21905 about to cond_wait for mythread init 1.
>pid=21907 thread mutex locked at x7fff79c8
>pid=21907 thread cond signal sent, unlocking at 0x7fff79c8
>pid=21907 thread unlocked
>pid=21905 back from cond_wait for mythread init 1. result=0
>pid=21907 yielded and back again
># rpm -q glibc
>glibc-2.2.4-11.2
On my R4600SC Indy running 7.1 (mips) I get:
% gcc blah.c -o blah -lpthread -Wall
blah.c: In function `StartFunction':
blah.c:37: warning: unsigned int format, pointer arg (arg 3)
blah.c:42: warning: unsigned int format, pointer arg (arg 3)
% ./blah
[blah:5286] Illegal instruction 0100017c at 2ad1a910 ra=2ab78ed0
Illegal instruction (core dumped)
% uname -a
Linux elan 2.4.3 #1 Sun Apr 22 23:46:19 PDT 2001 mips unknown
% rpm -q glibc gcc
glibc-2.2.4-11.2
gcc-2.96-97.2
%
This happens whether it's a native build of glibc or the one from
oss.sgi.com. The kernel is from the simple dir on oss.
With a 3rd Sept CVS 2.4.8 kernel under no load the pthreads program
runs ok, but under load (a big rm -rf over NFS for instance), it
fails like above, or fails like:
% ./blah
pid=681 Init mutex
pid=681 About to create thread: mythread
pid=681 about to cond_wait for mythread init 1.
Segmentation fault (core dumped)
%
Also I found I could only build X natively on the Indy by disabling the
pthreads parts; and maybe it's a similar 'Illegal Instruction' error in
the 'conftest' program that seems to be stopping mozilla from building??
(at least under kernel 2.4.3 which otherwise seems more stable than 2.4.8)
cheers,
robin
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bug in pthread glibc 7.0 & 7.1
2001-10-02 12:09 ` Robin Humble
@ 2001-10-02 16:14 ` H . J . Lu
0 siblings, 0 replies; 4+ messages in thread
From: H . J . Lu @ 2001-10-02 16:14 UTC (permalink / raw)
To: Robin Humble; +Cc: linux-mips, roger_twede
On Tue, Oct 02, 2001 at 10:09:25PM +1000, Robin Humble wrote:
> Also I found I could only build X natively on the Indy by disabling the
> pthreads parts; and maybe it's a similar 'Illegal Instruction' error in
> the 'conftest' program that seems to be stopping mozilla from building??
> (at least under kernel 2.4.3 which otherwise seems more stable than 2.4.8)
>
My impression is 2.4.3 is more stable than 2.4.5. I haven't tried
2.4.8 yet.
H.J.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-10-02 16:14 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-10-01 23:52 Bug in pthread glibc 7.0 & 7.1 TWEDE,ROGER (HP-Boise,ex1)
2001-10-02 0:10 ` H . J . Lu
2001-10-02 12:09 ` Robin Humble
2001-10-02 16:14 ` H . J . Lu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox