Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Mon, 16 Jul 2001 13:55:58 -0400
From: Jason Tishler <Jason DOT Tishler AT dothill DOT com>
To: Greg Smith <rys AT epaibm DOT rtpnc DOT epa DOT gov>
Cc: Cygwin-Developers <cygwin-developers AT sources DOT redhat DOT com>
Subject: Re: Threaded Cygwin Python Import Problem
Message-ID: <20010716135558.F614@dothill.com>
Mail-Followup-To: Greg Smith <rys AT epaibm DOT rtpnc DOT epa DOT gov>,
	Cygwin-Developers <cygwin-developers AT sources DOT redhat DOT com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="5hNzppoVPzHLtQC2"
Content-Disposition: inline
In-Reply-To: <3B532077.44582445@trex.rtpnc.epa.gov>
User-Agent: Mutt/1.3.18i
Organization: Dot Hill Systems Corp.


--5hNzppoVPzHLtQC2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Greg,

On Mon, Jul 16, 2001 at 01:12:23PM -0400, Greg Smith wrote:
> Jason Tishler wrote:
> > Yes! (I'm relieved that it was not just me!)  If you kill the child,
> > then you should see the following:
> > 
> >     $ ./python ../nothreads/test.py
> >     child execvp-ing
> >     status = 15
> >     parent done
> > 
> Yes, this is exactly what I see.

Good.

> > Instead if you attach to the child, then you should see a stack trace
> > like the one in the following:
> 
> Hmmm, gdb attach to the child process didn't cause a stackdump for me...

You won't get a stackdump, but you can see a stack trace by doing the
following:

    $ # window number 1
    $ ./python ../nothreads/test.py
    child execvp-ing

    $ # window number 2
    $ ps | fgrep python
           90     273      90        236    0 1004 13:32:12 /home/jt/src/Python-2.1/threads/python
          382      90      90        382    0 1004 13:32:13 /home/jt/src/Python-2.1/threads/python
    $ gdb -nw python.exe 
    GNU gdb 5.0 (20010428-1)
    ...
    (gdb) attach 382
    Attaching to program `/home/jt/src/Python-2.1/threads/python.exe', process 382
    [Switching to thread 382.0x19e]
    (gdb) thread 1
    [Switching to thread 1 (thread 382.0x14c)]#0  0x77f6829b in ?? ()
    (gdb) bt
    #0  0x77f6829b in ?? ()
    #1  0x77f04f41 in ?? ()
    #2  0x6105f14a in pthread_mutex::Lock (this=0xa014e10)
        at ../../../../src/winsup/cygwin/thread.cc:644
    ...
    
> but I haven't compiled Python or Cygwin with -g either, also I am using
> the dll built from the 7/4 snapshot.

IIRC, Python is compiled with -g by default.  However, you will have to
build Cygwin yourself to get a non-stripped DLL that corresponds to your
source.

> Anyway, at least I can produce the hang.  I won't be able to do any debugging
> until I get home later, but half the work in solving a problem is recreating
> the problem !!  I'll be back.

Agreed!

BTW, I was able to reproduce the hang under Windows 2000 SP1 if I
invoke python as follows:

    $ ./python ../nothreads/test.py </dev/null

Go figure!

Are wondering how I stumbled across this?  It is because I have a
version of Python built with --with-pydebug that prompts just before
exit to print out the remaining (object) references (I presume for
resource leak, garbage collection, etc. issues):

    $ ./python ../nothreads/test.py
    Adding parser accelerators ...
    Done.
    child execvp-ing
    status = 15
    parent done
    [3397 refs]
    Print left references? [ny] 
    $

I thought that redirecting stdin to /dev/null would prevent the annoying
prompt -- instead it enabled the conditions necessary for the hang.
Maybe you can try this "technique" on your home machine so you can work
on this in the comfort of your own home?  :,)

Anyway, attached is a Windows 2000 SP1 stack trace of the problem.  The
stack trace is essentially the same as the one from NT 4.0 SP5.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: 732.264.8770 x235
Dot Hill Systems Corp.               Fax:   732.264.8798
82 Bethany Road, Suite 7             Email: Jason DOT Tishler AT dothill DOT com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

--5hNzppoVPzHLtQC2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="gdb-2k.out"

(gdb) bt
#0  0x77f82152 in _libkernel32_a_iname ()
#1  0x77e830fe in _libkernel32_a_iname ()
#2  0x77e83126 in _libkernel32_a_iname ()
#3  0x6105f14a in pthread_mutex::Lock (this=0xa014de0)
    at ../../../../src/winsup/cygwin/thread.cc:644
#4  0x61060c06 in __pthread_mutex_lock (mutex=0xa0112a8)
    at ../../../../src/winsup/cygwin/thread.cc:1917
#5  0x6103b1ce in pthread_mutex_lock (mutex=0xa0112a8)
    at ../../../../src/winsup/cygwin/pthread.cc:240
#6  0x61d92467 in PyThread_acquire_lock (lock=0xa0112a0, waitflag=0)
    at ../Python/thread_pthread.h:298
#7  0x61d861e1 in lock_import () at ../Python/import.c:159
..
(gdb) f 3
#3  0x6105f14a in pthread_mutex::Lock (this=0xa014de0)
    at ../../../../src/winsup/cygwin/thread.cc:644
644       return WaitForSingleObject (win32_obj_id, INFINITE);
Current language:  auto; currently c++
(gdb) list
639     }
640     
641     int
642     pthread_mutex::Lock ()
643     {
644       return WaitForSingleObject (win32_obj_id, INFINITE);
645     }
646     
647     int
648     pthread_mutex::TryLock ()
(gdb) p *this
$1 = {<verifyable_object> = {magic = 1886217588}, win32_obj_id = 0x656c6966, 
  condwaits = 0, pshared = 0}

--5hNzppoVPzHLtQC2--