> On Sun, Oct 21, 2001 at 02:29:04AM +0200, Ralf Habacker wrote: > >The problem is caused by dll_list:alloc() in the loop "Search for space > >after the DLL". I have found that in one app the exit after > >VirtualQuery() and in other app the exit after if (i == RETRIES) > >occures. After looking around I tried to increase the RETRIES constant > >to 1000. This fix the error. Hmmh, does this really fix this ??? > > If setting the number up fixes the problem, then, yes, it probably is > a real fix. However, read on. > > >Can anyone tell me, whats could be going wrong with this stuff ? > > The loop that you presented (which I snipped) is trying to find space > just after a just-loaded DLL in which to place info on the DLL. > > If it really has to go through 1000 regions of memory to find a place > for this, then it could potentially be pretty slow. This would show > up as slow loading of DLLs. > > You'll also see some slowness from other regions of this file on > loading DLLs since, after a fork, we need to make sure that DLLs in > the forked process are in the same location as the parent. Windows > does not offer a way to do this, so cygwin kludges this behavior > by all available space up to the point where the DLL should load and > then loading the DLL. This is a very slow operation and it may > be why you are seeing slow loading of DLLs. > > Anyway, I checked in the RETRIES increase so it will be in the next > snapshot and, eventually, 1.3.4. > Thank you for your help. I think I have to analyse this a little bit more.
> Btw, are you able to use gdb since yesterday's update? > I have tested gdb (GNU gdb 5.0 (20010428-1))) after I have got your mail and I'm able to debug, but I haven't updated gdb in the last four weeks. The only thing I have updated in the last days is cygwin. Regards Ralf > cgf >
