Re: 1.5.9-1: socket() appears NOT to be thread-safe

[Brian Ford <ford@vss.fsi.com>]

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/