Hi Takashi, On Jan 16 23:45, Takashi Yano via Cygwin wrote: > On Mon, 16 Jan 2023 11:23:54 +0100 > Corinna Vinschen wrote: > > On Jan 16 18:02, Takashi Yano via Cygwin wrote: > > [...] > > > Errors seem to be three types: (null), cygpid.xxx and shared.5. > > > I'm not sure what is happening and why at all, however, this > > > did not seem to happen before the commit 30add3e6b3e3. > > > > I'll try to reproduce this issue. But the weird thing is certainly > > this: The affected shared mem regions are apparently not the cygheap. > > Rather, they are the "shared" and "cygpid" shared mem regions, which > > should not at all collide with the cygheap. I guess we need more > > debug output in the api_fatal call inside open_shared... > > I am now trying the test case with reverting the commit 60675f1a7eb2 > "Cygwin: decouple shared mem regions from Cygwin DLL", and the issue > does not happen for several hours so far. I guess this most likely > is the direct cause of the problem.
Actually, I' running your testcase on two machines in parallel now for quite some time, which only one hunk of 60675f1a7eb2 reverted, i.e. diff --git a/winsup/cygwin/mm/shared.cc b/winsup/cygwin/mm/shared.cc index 893b20d289b4..6d6d2940b6d4 100644 --- a/winsup/cygwin/mm/shared.cc +++ b/winsup/cygwin/mm/shared.cc @@ -140,7 +140,11 @@ open_shared (const WCHAR *name, int n, HANDLE& shared_h, DWORD size, if (*m == SH_JUSTCREATE || *m == SH_JUSTOPEN) addr = NULL; else - addr = (void *) region_address[*m]; + { + addr = (void *) region_address[*m]; + VirtualFree (addr, 0, MEM_RELEASE); + } + WCHAR map_buf[MAX_PATH]; WCHAR *mapname = NULL; So far (and knocking on wood madly while writing this) the mapping problem didn't show up once. Maybe you'd like to try the same? Btw., I pinged you on IRC already 3 hours ago... 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