Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3B56201A.8137A41E@nc.rr.com>
Date: Wed, 18 Jul 2001 19:47:38 -0400
From: Greg Smith <gsmith AT nc DOT rr DOT com>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
CC: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>,
        Jason Tishler <Jason DOT Tishler AT dothill DOT com>
Subject: Re: Threaded Cygwin Python Import Problem
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


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 AT 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 AT SMITHS1006 ~
$ gcc -o ftest ftest.c

gsmith AT 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/