This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: Threaded Cygwin Python Import Problem
- To: "Jason Tishler" <Jason dot Tishler at dothill dot com>,"Greg Smith" <gsmith at nc dot rr dot com>
- Subject: Re: Threaded Cygwin Python Import Problem
- From: "Robert Collins" <robert dot collins at itdomain dot com dot au>
- Date: Sat, 14 Jul 2001 04:30:42 +1000
- Cc: "Cygwin-Developers" <cygwin-developers at sources dot redhat dot com>
- References: <20010710121705.J434@dothill.com>
----- 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