This is the mail archive of the cygwin-developers@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: 1.3.4?


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);

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