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/
