This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: 1.3.4?
- To: cygwin-developers at cygwin dot com
- Subject: Re: 1.3.4?
- From: Jason Tishler <jason at tishler dot net>
- Date: Sun, 23 Sep 2001 22:15:21 -0400
Chris,
On Sat, Sep 22, 2001 at 01:13:33PM -0400, Christopher Faylor wrote:
> I'd like to release cygwin 1.3.4.
>
> Are there any outstanding problems that I am not aware of?
While trying to release my first threaded Python distribution, I believe
that I have found another pthreads hang. For those interested, see the
attached for a gdb session.
I'm also chasing the following problem that seems to only occurs when
running the full regression test for threaded Python 2.1.1:
test_socket
C:\home\jt\src\python-2.1.1.save\python.exe: *** unable to remap C:\home\jt\src\python-2.1.1.save\build\lib.cygwin-1.3.4-i686-2.1\rotor.dll to same address as parent -- 0x69180000
20830857 [main] python 2252 sync_with_child: child 492(0x214) died before initialization with status code 0x1
20837013 [main] python 2252 sync_with_child: *** child state child loading dlls test test_socket crashed -- exceptions.OSError: [Errno 11] Resource temporarily unavailable
The above does not occur with non-threaded Python 2.1.1 or *threaded*
Python CVS.
Nevertheless, the above problems most likely do not warrant holding up
the release.
Jason
P.S. I was going to wait to post regarding these issues until I had a
better understanding, but inquiring minds wanted to know... In other
words, I was trying to be responsive to your email.
(gdb) info threads
26 thread 2284.0x878 0x77f9eeaa in _libkernel32_a_iname ()
25 thread 2284.0x91c 0x77f82152 in _libkernel32_a_iname ()
24 thread 2284.0x924 0x77f82152 in _libkernel32_a_iname ()
..
3 thread 2284.0x354 0x77f820f0 in _libkernel32_a_iname ()
2 thread 2284.0x8e4 0x77f820f0 in _libkernel32_a_iname ()
* 1 thread 2284.0x83c 0x77f82152 in _libkernel32_a_iname ()
(gdb) bt
#0 0x77f82152 in _libkernel32_a_iname ()
#1 0x77e830fe in _libkernel32_a_iname ()
#2 0x77e83126 in _libkernel32_a_iname ()
#3 0x61061f50 in pthread_cond::TimedWait (this=0xa3a5208,
dwMilliseconds=4294967295)
at /home/jt/src/cygwin/src/winsup/cygwin/thread.cc:512
#4 0x61063c75 in __pthread_cond_wait (cond=0xa33f0f4, mutex=0xa33f0f8)
at /home/jt/src/cygwin/src/winsup/cygwin/thread.cc:1781
#5 0x6103e3de in pthread_cond_wait (cond=0xa33f0f4, mutex=0xa33f0f8)
at /home/jt/src/cygwin/src/winsup/cygwin/pthread.cc:375
#6 0x61d928a5 in PyThread_acquire_lock (lock=0xa33f0f0, waitflag=1)
at Python/thread_pthread.h:313
..
(gdb) f 3
#3 0x61061f50 in pthread_cond::TimedWait (this=0xa3a5208,
dwMilliseconds=4294967295)
at /home/jt/src/cygwin/src/winsup/cygwin/thread.cc:512
512 rv = WaitForSingleObject (win32_obj_id, dwMilliseconds);
(gdb) list thread.cc:498, thread.cc:512
498 int
499 pthread_cond::TimedWait (DWORD dwMilliseconds)
500 {
501 DWORD rv;
502 if (!wincap.has_signal_object_and_wait ())
503 {
504 // FIXME: race condition (potentially drop events
505 // Possible solution (single process only) - place this in a critical section.
506 ReleaseMutex (mutex->win32_obj_id);
507 rv = WaitForSingleObject (win32_obj_id, dwMilliseconds);
508 }
509 else
510 {
511 LeaveCriticalSection (&mutex->criticalsection);
512 rv = WaitForSingleObject (win32_obj_id, dwMilliseconds);