From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12402 invoked by alias); 21 May 2004 22:21:25 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 12366 invoked from network); 21 May 2004 22:21:24 -0000 Received: from unknown (HELO esds.vss.fsi.com) (66.136.174.212) by sourceware.org with SMTP; 21 May 2004 22:21:24 -0000 Received: from fordpc.vss.fsi.com (fordpc [198.51.27.93]) by esds.vss.fsi.com (8.11.6+Sun/8.9.1) with ESMTP id i4LMLJU21220 for ; Fri, 21 May 2004 17:21:20 -0500 (CDT) Date: Sat, 22 May 2004 16:59:00 -0000 From: Brian Ford Reply-To: cygwin@cygwin.com To: cygwin@cygwin.com Subject: Re: 1.5.9-1: socket() appears NOT to be thread-safe In-Reply-To: <20040415174118.GA8644@coe.bosbc.com> Message-ID: References: <20040415174118.GA8644@coe.bosbc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2004-05/txt/msg00758.txt.bz2 I assume this email is hopeless, but I'm desperately searching for a lead... On Thu, 15 Apr 2004, Christopher Faylor wrote: > Corinna showed me that this was a problem in my autoload code rather than > a problem with winsock. That's comforting. I guess I've grown too quick > to judge Windows. > > I've checked in a fix and am regenerating a snapshot. The fix consisted of > deleting a few lines of code so that's always nice... > > Thanks for the test case. It helped a lot in tracking this problem down. I still see the same symptom (ie. socket randomly returns "Operation not permitted" at application startup) with current CVS, but not with the original test case, and only on a dual CPU box :-(. So far, I have been unsuccessful at catching it with strace, even when -b 1000000 is supplied. It is unfortunately a complicated series of events that cause the problem. 1.) X app forks 2.) child execlp's a /bin/sh script 3.) script exec's a program that calls socket About 30% of the time, socket returns the error above. I tried replacing the exec line in the shell script with: exec strace -o tracefile -b 1000000 socket_error.exe but then it doesn't fail. It also doesn't fail if socket_error.exe is launched directly from the bash prompt. I will keep trying to come up with a test case that I can actually study, but I was hoping someone might have an idea about how to catch it better or where to look. Is it possible that the autoload code needs to be made dual CPU safe? Thanks anyway. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/