On Jun 6 10:49, Corinna Vinschen wrote: > On Jun 6 01:15, Dave Korn wrote: > > Corinna Vinschen wrote: > > > > > Not good. I'm puzzled where this allocated 68K region is exactly coming > > > from, but it really looks like something which occurs in or near dlopen. > > > > > > I'm going to debug this further tomorrow. I guess that goes without > > > saying, but I'd be glad for any help. > > > > I'll just suggest that these problems can often be debugged more easily in > > windbg than gdb, what with gflags/appverifier heap tracking, !vad, !heap, > > and > > related commands. The gflags FLG_HEAP_ENABLE_TAG_BY_DLL might come in > > handy here. > > Right. You might have noticed in my mail that I refer to WinDbg > already. It has a couple of invaluable helpers. !vprot is one of my > favorites, as well as the many available display formats in the memory > window. > > This morning I woke up and suddenly knew what's going on. It's the size > of a structure, which had a size of 320 bytes before. Now it has a size > of 65596 bytes since the filename stored in it is now a potentially 32K > long wide character string. The structure must be shrinked again. I > guess I have a patch by tonight.
Done. The per-DLL structure is used to keep track of certain aspects of each DLL linked at the executable or loaded at runtime. In the latter case, the post-fork procedure re-loads the DLL into the child. The structure is allocated right after the space occupied by the DLL itself, using VirtualAlloc. I changed the struct layout so that the size depends on the length of the pathname to the DLL. In most, if not all cases this will fit into a single 4K page. The one problem with VirtualAlloc is the fact that it only allocates memory on a 64K boundary. So the DLL struct will be allocated exactly in the next DLL slot in memory, wasting one place where a DLL can be loaded. However, in most cases the DLL itself will not occupy the entire 64K slot, but one or more 4K pages are left free, which will never be used while the application is running. So I applied another patch this morning, which allocates a section object (file mapping in Win32 speak) instead. The NT kernel specifc AT_ROUND_TO_PAGE flag allows to allocate section objects on 4K page boundaries, rather than only on 64K allocation boundaries. This allows to allocate the DLL struct right after the DLL, in a memory slot which will never collide with any further allocation or DLL. The only downside is that the AT_ROUND_TO_PAGE flag is not supported by WOW64, so the DLL struct will still be allocated on 64K boundaries on 64 bit Windows. I tested this change on XP 32 bit, 2K8 32 bit, W7 32 bit, and W7 64 bit, by running `cygport automake1.11 compile' and a subsequent `make check', which uses perl (and thus run-time loaded DLLs) a lot. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
