This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

1.7.9-1: Random failures during exec()


Hi,

The development group that I work in has been experiencing random
failures when starting programs from Cygwin. The problem only occurs
when McAfee's (version 8.7i) on-access scanner McShield is running. We
do not have official control over this, so disabling it is not an
option.

I have tried Cygwin 1.5.25-7 and 1.7.9-1, with the same results: On
average about 1% of calls to exec() causes the program to disappear. No
output, no program code is run, and the exit code of the process is 0
(not killed by a signal or terminated abnormally). To me, this indicates
a race condition.

I added a 5ms delay to winsup/cygwin/init.cc:dll_entry(), as the first
step of the THREAD_ATTACH case, using the Windows Sleep() API call. With
this in place, the error rate drops to around 0.005% (depending on which
machine is running the test). This also indicates a race condition.

I know this occurs during program startup after an exec syscall because
I wrote a test program which:
 1. Installs a handler to count SIGUSR1 receipts
 2. Loop
 3. Reset signal counter
 4. fork()
 5. Parent waits for the child to terminate; child sends SIGUSR1 to
parent, and then calls execl() to a program that sends SIGUSR1 and
terminates.

With the standard Cygwin install, the first signal is always received,
but the second one does not always come before the child terminates. The
child always terminates normally, not due to a signal or abort, and with
an exit code of 0. I have attached the source for this program
(fork.tgz).

When using ptrace, the child always exits after the "sig" thread has
finished running through dll_entry(), and always after receiving an
exception from Windows. The error code (0xC0000005) translates to a
segfault.

I do not know enough about Windows or Cygwin internals to fix this
myself, and would rather not maintain internally a hacked version of
Cygwin.

Output of "cygcheck -s -v -r" attached (cygcheck.out).

Thanks,
Jonathan

Attachment: cygcheck.out
Description: Binary data

Attachment: fork.tgz
Description: GNU Zip compressed data

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]