Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Message-ID: <01a101c10bc9$ed28f160$806410ac@local> From: "Robert Collins" To: "Jason Tishler" , "Greg Smith" Cc: "Cygwin-Developers" References: <20010710121705 DOT J434 AT dothill DOT com> Subject: Re: Threaded Cygwin Python Import Problem Date: Sat, 14 Jul 2001 04:30:42 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 13 Jul 2001 18:17:31.0300 (UTC) FILETIME=[14C67640:01C10BC8] ----- Original Message ----- From: "Jason Tishler" > 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