RE: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set

[John Carey <aeolus at electric-cloud dot com>]

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.

-- John

--
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