Hi Takashi, On Jan 18 18:16, Takashi Yano via Cygwin wrote: > > On Jan 16 22:42, Corinna Vinschen via Cygwin wrote: > > I pushed some patches to fix this issue. Excessive debugging indicated > > that the reason cygcheck fails in this way is: > > > > - It's a non-Cygwin process which > > > > - is built with high-entropy ASLR and > > > > - tries to load the Cygwin DLL dynamically and > > > > - therefore suffers from the fact that recent Cygwin code doesn't > > expect that certain memory regions are used by Windows itself. > > Which they are, due to the high-entropy stuff. > > > > The patches are supposed to make the code less rigid in terms of the > > addresses of certain memory regions, as well as dropping the > > high-entropy VA flag from builds of strace and cygcheck, both of which > > are loading the Cygwin DLL dynamically as part of their job. > > > > The test release 3.5.0-0.116.g8d318bf142f7 contains the patches, for > > everybody to try. > > Thank you very much for working on this problem. It seems that > it was unexpectedly large-scale modification. > > I confirmed that the problem has been fixed with these patches. > The test case has been running for 11 hours but the problem does > not happen so far.
Great. I tested this yesterday with 7 runs on two machines in parallel while building Cygwin continuously in another Window, and cygcheck still with high-entropy-VA enabled. And one of the machines continued to run the cygcheck loops over night and were still in good shape this morning :) I guess we should release 3.4.4 pretty soon now. Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
