1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
Mon Sep 13 20:35:00 GMT 2010
On Sep 13 12:47, John Carey wrote:
> On Sep 11 03:30, Corinna Vinschen:
> > Can't we find Cwd by scanning the .data segment of ntdll.h for the
> > address we inferred from the Params.CurrentDirectoryName.Buffer value?
> Nice; that might work. But there would need to be some kind of rule
> to pick a winner among multiple matching words, in case by coincidence
> some other non-pointer word just happens to have the same bit pattern.
> I can see two alternatives for the multiple-match case:
> 1. Code scanning, as suggested earlier. There would need to be a
> unit test of the code scanner itself so that incompatible changes to
> ntdll.dll could be detected deterministically, instead of only after
> a multiple-match coincidence.
> 2. Call SetCurrentDirectory() and recheck the previously-matching
> addresses to see which one matches the new value. Place some limit
> (like 4) on the number of such retries, in case some new version of
> ntdll.dll intentionally duplicates the pointer every time.
> (Not sure what to do in that case; fall back to code scanning?)
Sorry, I just realized that while Cygwin might do all this to find &Cwd,
it will not work for &CwdCS. There must be plenty of critical sections
floating around. Still, reducing the number of addresses that must
be discovered by code scanning might still help future-proof things.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin