This is the mail archive of the glibc-linux@ricardo.ecn.wfu.edu mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: pthreads problems



I have been tracing this bug into the libpthread. The pthread_create()
blocks on the suspend(); call, namely on the function sigsuspend() (in
linuxthreads/restart.h).

The thread is obviously put to sleep, but is never woken up. Who is
responcible for waking up the thread?

The signal that the thread is woken up on is number 32 i.e. SIGRTMIN.
SIGRTMAX is 63.
Shouldnt the signal that the thread is woken up with be SIGUSR1 (or so I
thought from the documentation of linuxthreads)?

If I pass SIGRTMIN to the process manually (with kill -32 <processid of
main thread>) the thread is woken up and it runs until it goes to sleep
again.

Any ideas?

K.D.




                                                                                                                                 
                    Andreas                                                                                                      
                    Jaeger               To:     kd@flaga.is                                                                     
                    <aj@suse.de>         cc:     glibc-linux@ricardo.ecn.wfu.edu                                                 
                    Sent by:             Subject:     Re: pthreads problems                                                      
                    aj@suse.de                                                                                                   
                                                                                                                                 
                                                                                                                                 
                    12/07/99                                                                                                     
                    12:52 PM                                                                                                     
                                                                                                                                 
                                                                                                                                 




>>>>> kd  writes:

 > Hi,
 > I am having a strange problems with linuxthreads in glibc2.1.2.
 > The setup: Linux 2.2.5 for embedded ppc board (MPC823), library
Glibc2.1.2
 > with cache size patch and soft-float patch applied, glibc2.1.2 compiled
 > with gcc 2.95.2 crosscompiler from i386-linux host.
 > The problem is that programs using threads hang on pthread_create()
call.

 > If I run the same program (compiled against glibc 2.1.2) and run it on
 > older compilation of glibc version 2.1.1 the programs do not hang on
 > pthreads_create but crash instead
 > when the last thread stops running. I have though not been able to
 > reproduce that behaviour in a simple program but it happens always in
the
 > more complex c++ code.

 > The same programs work fine compiled on a Debian 2.1 system with glibc
 > 2.1.2 installed and gcc 2.95.2 or when compiled in vanilla Debian 2.1.

 > I know this is vague description of the problem, but because of memory
 > constraints I am not able to run gdb on my MPC823 board, and hence
unable
 > to give stack traces.

 > I noticed that there have been some updates to the linuxthreads in the
CVS.
Please use the glibc-2-1-branch - don't use the main branch.
 > Is it safe for my to get the lates version of linuxthreads (and the new
 > linuxthreads_db) directories and
 > compile them against the othervise unchanged (sans cache patch) glibc
2.1.2
 > source tree or are there changes pthreads related changes in the rest of
 > the glibc source tree?
I would be suprised if it works.  Just get the whole glibc 2.1.3 CVS
version.

 > Or is it just a pipedream that these lates changes might fix this
problem I
 > am having.
Your report is to vague to say anything.

Andreas
--
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]