Segfault if /proc/PID/maps is opened in parallel threads [CAUSE: RtlQueryProcessDebugInformation]

Wed Jul 2 16:28:19 GMT 2025

On Jul 2 16:18, Christian Franke via Cygwin wrote:
> On 2025年5月27日 17:44:10 +0200 Christian Franke wrote:
> > On 2025年5月25日 16:46:49 +0200, Christian Franke wrote:
> > > On 2025年5月24日 15:19:10 +0200, Christian Franke wrote:
> > > > If /proc/PID/maps is opened in parallel threads, the process PID
> > > > may segfault.
> > > > 
> > > > Testcase:
> > > > 
> > > > ...
> > > > 
> > > > Problem is not reproducible with any of the other /proc/PID/* files.
> > > > 
> > > 
> > > A closer look shows that the problem is unrelated to thread safety.
> > > The segfault also occurs when the following command is run
> > > simultaneously in two terminals:
> > > 
> > > $ while cat /proc/1234/maps > /dev/null; do printf .; done
> > > .............cat: /proc/1234/maps: No such file or directory
> > > 
> > 
> > The root of the problem is the call of RtlQueryProcessDebugInformation()
> > here:
> > https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler/process.cc;h=8fae9be5#l630
> > 
> > 
> > If this part is removed, the segfault does no longer occur. Then
> > /proc/PID/maps still work but the "[win heap ...]" information is
> > missing. No patch provided because I don't know whether this could
> > possibly be fixed without removing this functionality.
> > 
> > A test with a separate test program shows that the problem is unrelated
> > to Cygwin: Parallel calls to RtlQueryProcessDebugInformation() with the
> > same PID could be used to crash this process. It also "worked" with
> > Notepad.exe.
> > 
> > Possible Windows (Version 10.0.22631.5039) bug?

Looks very much like a Windows bug to me. But the function is supposed
to be run under a debugger, so there's a chance multiple parallel calls
were never part of the picture. And given the function is undocumented,
I guess we have to keep the broken pieces...
> Testcase (attached):
> [...]
> Conclusion: Possible Windows bug in RtlQueryProcessDebugInformation().
> Cygwin should not use this function to provide "nice to have" types of
> information like "[win heap...]" if this may crash the target process.

RtlQueryProcessDebugInformation isn't only called to emulate maps,
it is also called from within dlsym().
A valid patch might be to move the RtlQueryProcessDebugInformation
into its own function which adds a global lock. But obviouly the 
function can be called in a non-Cygwin process in parallel, so there's
no 100% safe way to do it.
Any other idea?
Thanks,
Corinna