>>>>> It seems a race problem, due to the repetitive fork of grep >>>>> for every line of some-file >>>> >>>> So why does it fail? Seems like a bug to me! >>>> >>>> Regards, >>>> Paul >>> >>> As does not fail on my computer, I suspect is a race between your AV and >>> cygwin and sometimes cygwin wins. >>> >>> >>> Regards >>> Marco. >> >> Good for you. I don't have AV SW as I mentioned. And even so, that still >> makes it a bug. > > Your system timing performance as so poor that something > is likely interfering. > Don't assume that is a cygwin bug. > >> Anyhow, a suspicion is speculative. I thought this mailing list was meant to >> report issues, and I think this is an issue. > > Yes, this is the right place. > >> How can I further diagnose this? Is there a known way to further determine >> what's causing this? > > start with > > Problem reports: http://cygwin.com/problems.html > > "Run cygcheck -s -v -r > cygcheck.out and include that file as an > attachment in your report. Please do not compress or otherwise encode > the output. Just attach it as a straight text file so that it can be > easily viewed. " > > so we can look at your system configuration. > >> Regards, >> Paul > > Marco
After observing for a week on the system with the fix applied, I did not see this issue reoccur. I do however still suspect that it is a bug in cygwin, indeed a race condition of some sorts, which probably becomes apparent when starting up a process takes (much) longer than expected. As said, the guard32.dll is probably scanning the new CreateProcess candidate. I suspect that there's an timing assumption in the Cygwin fork code. But as I cannot be sure, I leave it at that. Regards, Paul -- 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
