child_info_fork::abort:

[Ryan Johnson]

On 11/06/2012 9:49 AM, Rodrigo Botafogo wrote:
> Ryan,
>
> Thanks also for your reply.  In your reply you say that if the system
> has a very large number of DLL rebase might not work. Just for
> curiosity, what is a large number of DLL?  When do I run a risk of
> having problems with rebaseall?
Short version: you ignore what I said, for all practical purposes -- I 
misread the address from your OP.

To answer your question, though:

There's a fixed amount of address space between 0x7000000 (the top 
boundary where rebaseall normally starts working down from) and 
0x4000000 (the address at which the executable image is always mapped). 
In between there usually go several Windows-related things (heaps, 
thread stacks, etc.), so really 0x50000000 is probably the real lower 
bound. That leaves roughly 512MB of address space to fill with rebased 
dlls; how fast the space gets used up depends on the number and size of 
dlls in your system. Most dlls are quite small (32-64kB), and my rebase 
database contains fewer than 350 of them. The lowest address in use is 
0x62d20000, so I've still got 300MB or so wiggle room (= plenty). I'd 
expect this to be the case for the vast majority of cygwin users.

Going from your claim that you'd rebased everything, if rebaseall had 
actually put a dll at 0x42000000, that would be a *lot* of *big* dlls 
(some thousands, or sized in MB instead of kB, perhaps). However, 
looking closer at your original report, 0x420000 != 0x42000000, and is 
well below the executable image. That dll was almost certainly placed 
there by Windows due to a base address collision, with the latter 
probably due to a dll (or several) that rebaseall missed.

Regards,
Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple