Threaded Cygwin Python Import Problem

Jason Tishler Jason.Tishler@dothill.com
Tue Jul 10 09:17:00 GMT 2001


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.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com


More information about the Cygwin-developers mailing list