This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


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

Re: Threaded Cygwin Python Import Problem



I think I've recreated Jason's threaded Python problem after fork(),
see the testcase below.  And this is on my w2k sp2 dual pIII 850
machine, where I have been unsuccessful in recreating Jason's
original Python testcase.

I certainly do not claim Cygwin expertise, nor Windows API expertise,
and not as much *ix as I'd like (ask me about os/390, however, and
I'll give you a different story ;-).

But, it looks like fork_copy() blindly copies everything from the
original process address space to the new address space, including
any pthread_mutex_t structures.  And neither __pthread_mutex_lock
nor WaitForSingleObject() recognize that the mutex is not properly
initialized.  If the comments in the testcase are removed (ie clear
the lock and initialize it), then the testcase runs as expected.

I can sympathize with the solution `Don't DO that'; forking a
multi-threaded process is murky at best anyways.  A humble suggestion
would be to include the pid number with the check to see if the lock
is properly initialized.

Greg

gsmith@SMITHS1006 ~
$ cat ftest.c
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>

int main (int argc, char *argv[])
{
pthread_mutex_t l;
pid_t           p;

   if (pthread_mutex_init(&l, NULL) == -1) {
      perror ("pthread_mutex_init"); abort(1); }

   if (pthread_mutex_lock(&l) == -1) {
      perror ("pthread_mutex_lock"); abort(2); }

   if (pthread_mutex_unlock(&l) == -1) {
      perror ("pthread_mutex_unlock"); abort(3); }

   if (p = fork()) {
      printf("parent waiting for %d\n",p);
      waitpid(p, NULL, 0);
   }
   else {
      sleep(1);

//    memset(&l, 0, sizeof(l));
//    if (pthread_mutex_init(&l, NULL) == -1) {
//       perror ("pthread_mutex_init"); abort(1); }

      printf("child locking\n",p);
      if (pthread_mutex_lock(&l) == -1) {
         perror ("pthread_mutex_unlock"); abort(4); }

      printf("child unlocking\n",p);
      if (pthread_mutex_lock(&l) == -1) {
         perror ("pthread_mutex_unlock"); abort(5); }
   }
}

gsmith@SMITHS1006 ~
$ gcc -o ftest ftest.c

gsmith@SMITHS1006 ~
$ ./ftest
parent waiting for 1224
child locking

gdb `bt' for thread[1] in pid 1224 shows:

(gdb) bt
#0  0x77f827e8 in _libkernel32_a_iname ()
#1  0x77e86a15 in _libkernel32_a_iname ()
#2  0x77e86a3d in _libkernel32_a_iname ()
#3  0x6105f1aa in pthread_mutex::Lock (this=0xa0100c8)
    at /src/winsup/cygwin/thread.cc:644
#4  0x61060c66 in __pthread_mutex_lock (mutex=0x240feb0)
    at /src/winsup/cygwin/thread.cc:1917
#5  0x6103b32e in pthread_mutex_lock (mutex=0x240feb0)
    at /src/winsup/cygwin/pthread.cc:240
#6  0x004011c9 in ?? ()
#7  0x61003b0a in dll_crt0_1 () at /src/winsup/cygwin/dcrt0.cc:859
#8  0x61003cdd in _dll_crt0 () at /src/winsup/cygwin/dcrt0.cc:925
#9  0x61003d1c in dll_crt0 (uptr=0x0) at /src/winsup/cygwin/dcrt0.cc:937
#10 0x00401287 in ?? ()
#11 0x0040103d in ?? ()
#12 0x77e97d08 in _libkernel32_a_iname ()

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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