On Mar 31 15:46, Corinna Vinschen wrote: > On Mar 31 13:06, Corinna Vinschen wrote: > > On Mar 31 17:18, Yuyi Wang wrote: > > > > I tested this scenario, and this problem only occurs with > > > > dlopening cygwin1.dll. > > > > > > Not only cygwin1.dll, but also native dlls, e.g., kernel32.dll or > > > user32.dll. > > > I haven't tested the next release, but do you think it's the same reason > > > for > > > win32 dlls? > > > > No, it's not. Native DLLs are not taken into account because they > > don't call into Cygwin's dll_dllcrt0 on init, so they are not > > added to the DLL list. > > > > Hmm. > > > > I'll have to check if we should add them to the dll list or not. > > We certainly don't need them for atexit and stuff, but the dlopen > > counting might be necessary at fork. > > FTR, even if we keep track of native dlopen'ed DLLs, we can't reproduce > their state after fork. We must not even try, because certain Windows > DLLs choke on reproducing their data and bss segments and misbehave. > > So we can only keep track of the number of dlopen/dlclose calls for them.
I pushed a patch: https://sourceware.org/cgit/newlib-cygwin/commit/?id=9fb7f285d626d Please try the next test release cygwin-3.7.0-0.31.g0bb9d599a2b9. Thanks, Corinna
