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: Tue, 10 Jul 2001 12:17:05 -0400
From: Jason Tishler <Jason DOT Tishler AT dothill DOT com>
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
Cc: Norman Vine <nhv AT cape DOT com>,
        Cygwin-Developers <cygwin-developers AT sources DOT redhat DOT com>
Subject: Re: Threaded Cygwin Python Import Problem
Message-ID: <20010710121705.J434@dothill.com>
Mail-Followup-To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>,
	Norman Vine <nhv AT cape DOT com>,
	Cygwin-Developers <cygwin-developers AT sources DOT redhat DOT com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="aj+xcdmXXJbbirp7"
Content-Disposition: inline
In-Reply-To: <EA18B9FA0FE4194AA2B4CDB91F73C0EF7A19@itdomain002.itdomain.net.au>
User-Agent: Mutt/1.3.18i
Organization: Dot Hill Systems Corp.


--aj+xcdmXXJbbirp7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Rob,

[Moved from cygwin-patches to cygwin-developers...]

On Tue, Jul 10, 2001 at 01:24:13PM +1000, Robert Collins wrote:
> >     python test.py
> 
> gdb.out: the event handle is clearly wrong. Can you include the output
> of print *this ? and list (so I know what the lines actually are :])>

See attached gdb.out.

> > and the second by:
> > 
> >     ./python test.py
> 
> Ditto for the above... but - the handle looks like it may be valid to
> me. From the bt of both outputs I suspect that it's the access mutex to
> the cond variable that is causing the grief. I'll glance at the code
> tonight.
> 
> Can you give me the following as well?
> for pthread_cond::Signal 
> list
> print *this

See attached gdb2.out.  Unfortunately, "this" is one of those "cannot
access memory at address" addresses.  I can "workaround" this problem
using the following goofy (and mostly likely invalid) procedure:

    (gdb) f 5
    #5  0x6105ed17 in pthread_cond::Signal (this=0xa0151a8) # <*** 1 ***
        at ../../../../src/winsup/cygwin/thread.cc:443
    443       if (pthread_mutex_lock (&cond_access))
    Current language:  auto; currently c++
    (gdb) p this
    $1 = (pthread_cond *) 0x200 # <*** 2 ***
    (gdb) set this=0xa0151a8 # <*** 3 ***
    (gdb) p this
    No symbol "this" in current context.
    (gdb) f 5
    #5  0x6105ed17 in pthread_cond::Signal (this=0xa0151a8)
        at ../../../../src/winsup/cygwin/thread.cc:443
    443       if (pthread_mutex_lock (&cond_access))
    (gdb) p this
    $2 = (pthread_cond *) 0xa0151a8
    (gdb) p *this
    $3 = {<verifyable_object> = {magic = -552734646}, shared = 0, waiting = 0, 
      mutex = 0x0, cond_access = 0xa011108, win32_obj_id = 0x154}

Note that the value for "this" is not the same as displayed in 1 and 2
above until I reset it in 3.  Any idea about what is going on?

> > I find it curious that the hang occurs in different places 
> > dependent on
> > how python is invoked -- via PATH or full pathname.  I'm also 
> > at a lose
> > as to why sometimes I get "Cannot access memory at address 
> > ..." errors.
> > Can anyone explain what is going on?
> 
> If the "cannot access memory at address" error is a windows popup, it's
> an exception unhandled by cygwin for some reason. If it's in gdb, see my
> description above - it _may_ be the normal
> first-access-test-with-random-data for BadWritePointer.

The latter case is what I'm observing.

> > Is the information provided in this email useful in helping you find
> > the problem?  If not, what else can I provide to assist you?
> 
> Just what I've asked for. I'll have a look and see if anything obvious
> appears, otherwise it'll be back to minimising the variables.

Please let me know how I can be of further assistance.

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

--aj+xcdmXXJbbirp7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="gdb.out"

(gdb) bt
#0  0x77f6829b in ?? ()
#1  0x77f04f41 in ?? ()
#2  0x6105f36a in pthread_mutex::Lock (this=0xa010a58)
    at ../../../../src/winsup/cygwin/thread.cc:644
#3  0x61060e26 in __pthread_mutex_lock (mutex=0xa012230)
    at ../../../../src/winsup/cygwin/thread.cc:1917
#4  0x6103b3ae in pthread_mutex_lock (mutex=0xa012230)
    at ../../../../src/winsup/cygwin/pthread.cc:240
#5  0x61d99e37 in PyThread_acquire_lock (lock=0xa012228, waitflag=0)
    at ../Python/thread_pthread.h:298
#6  0x61d8cebd in lock_import () at ../Python/import.c:159
..
(gdb) f 2
#2  0x6105f36a in pthread_mutex::Lock (this=0xa010a58)
    at ../../../../src/winsup/cygwin/thread.cc:644
644       return WaitForSingleObject (win32_obj_id, INFINITE);
Current language:  auto; currently c++
(gdb) p *this
Cannot access memory at address 0x2
(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 ()

--aj+xcdmXXJbbirp7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="gdb2.out"

(gdb) bt
#0  0x77f6829b in ?? ()
#1  0x77f04f41 in ?? ()
#2  0x6105f36a in pthread_mutex::Lock (this=0xa011108)
    at ../../../../src/winsup/cygwin/thread.cc:644
#3  0x61060e26 in __pthread_mutex_lock (mutex=0xa0151b8)
    at ../../../../src/winsup/cygwin/thread.cc:1917
#4  0x6103b3ae in pthread_mutex_lock (mutex=0xa0151b8)
    at ../../../../src/winsup/cygwin/pthread.cc:240
#5  0x6105ed17 in pthread_cond::Signal (this=0xa0151a8)
    at ../../../../src/winsup/cygwin/thread.cc:443
#6  0x61060560 in __pthread_cond_signal (cond=0xa010a5c)
    at ../../../../src/winsup/cygwin/thread.cc:1628
#7  0x6103b58e in pthread_cond_signal (cond=0xa010a5c)
    at ../../../../src/winsup/cygwin/pthread.cc:355
#8  0x61d9a02b in PyThread_release_lock (lock=0xa010a58)
    at ../Python/thread_pthread.h:344
#9  0x61d8cf78 in unlock_import () at ../Python/import.c:179
..
(gdb) f 2
#2  0x6105f36a in pthread_mutex::Lock (this=0xa011108)
    at ../../../../src/winsup/cygwin/thread.cc:644
644       return WaitForSingleObject (win32_obj_id, INFINITE);
Current language:  auto; currently c++
(gdb) p *this
$1 = {<verifyable_object> = {magic = 167912352}, win32_obj_id = 0xa028ac8, 
  condwaits = 1, pshared = 1641717416}
(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) f 5
#5  0x6105ed17 in pthread_cond::Signal (this=0xa0151a8)
    at ../../../../src/winsup/cygwin/thread.cc:443
443       if (pthread_mutex_lock (&cond_access))
(gdb) p *this
Cannot access memory at address 0x200
(gdb) list
438     }
439     
440     void
441     pthread_cond::Signal ()
442     {
443       if (pthread_mutex_lock (&cond_access))
444         system_printf ("Failed to lock condition variable access mutex, this %0p\n", this);
445       if (!verifyable_object_isvalid (mutex, PTHREAD_MUTEX_MAGIC))
446         {
447           if (pthread_mutex_unlock (&cond_access))

--aj+xcdmXXJbbirp7--