Re: Threaded Cygwin Python Import Problem

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

----- Original Message -----
From: "Jason Tishler" <Jason.Tishler@dothill.com>


> Rob,
>
> [Moved from cygwin-patches to cygwin-developers...]

Sorry I'm slow getting to this one :[. Time has been against me this last
month.

> 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.

Thanks. Unfortunately it looks like gcc has optimised out the value for
this. So no extra info was gained :[. You can access the correct data via
p *(pthread_mutex *) 0xa010a58

ditto for the second trace...

> > > and the second by:
...
> > 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
...
>
> 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?

Yes. One of two things that I know of - 1) the stack is getting trashed, or
the variable reference for this was optimised into a register, which after
it's last reference was reused for a later variable.

You can access the variable directly by typecasting :].

> > > I find it curious that the hang occurs in different places

I note that Greg has offered to help pinpoint the problem. Greg - if you do
locate the circustances needed to trigger the fault, feel free to mail me
directly, and I'll get right onto a fix. I've a suspicion starting to form
that we are seeing two independent bugs, but I need Jason to redo the two
traces, with the typecasting in the mutex frame (and the ::Signal frame for
the second cast) to start to firm that up.

Rob