Mail Archives: cygwin-developers/2001/07/16/13:56:42
--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--
- Raw text -