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

Thu Jul 3 11:03:00 GMT 2025

On Jul 2 18:28, Corinna Vinschen via Cygwin wrote:
> 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?

I just added two patches, one of them dropping RtlQueryProcessDebugInformation
in favor of EnumProcessModules in dlsym(), the other by adding a global
mutex to format_process_maps while accessing the debug buffer. I could
reproduce the crash even if RtlQueryProcessDebugInformation was serialized.
I could only avoid the crash by serializing the entire code from
RtlCreateQueryDebugBuffer up to and including RtlDestroyQueryDebugBuffer.
This ignores native processes which have a hard time to access
/proc anyway.
HTH,
Corinna