Large-Address awareness on 64 bit systems

[Ryan Johnson]

On 28/06/2011 2:41 AM, Corinna Vinschen wrote:
> On Jun 27 21:52, Yaakov (Cygwin/X) wrote:
>> On Sun, 2011-06-19 at 10:09 +0200, Corinna Vinschen wrote:
>>> On Jun 19 02:24, Yaakov (Cygwin/X) wrote:
>>>> But I think I do. :-)  I have rebased and reflagged my system
>>>> accordingly, and so far (running GNOME 3 desktop) so good.  I'll keep
>>>> you posted.
>>> Great, thanks!  As I just wrote in my reply to Ryan, I even rebased the
>>> Cygwin DLL(*) and it runs fine for me.
>> I still have been getting the occasional "fork: Resource temporarily
>> unavailable" error with make, but I haven't seen the "unable to remap
>> dll" error.  I have also been getting SIGABRT from throwing exceptions
>> across C++ DLLs, with GDB pointing to RtlUpdateClonedSRWLock() in ntdll,
>> but I was seeing that sometimes before this as well.  (This is with
>> 1.7.9; recent snapshots haven't been working for me but I haven't had
>> the time to track down why.)
> Oh, please try to track it down.  I'm running the latest from CVS on
> W7 32 bit and 2008 R2 64 bit daily, and I don't have problems.  If the
> new stuff to avoid collisions works as designed, the chance to see the
> fork problem should be much reduced.
>
> Having said that, even without rebasing to large addresses I had a
> strange problem a few days ago.  For some reason perl was suddenly
> broken.  Trying to start perl generated a stackdump from within the
> constructor loop in per_module::run_ctors in dll_init.cc.  Rebasing
> didn't help.  Reinstalling helped.  What could that be?  I'm pretty
> sure it has something to do with rebasing.
Hmm. I noticed a similar problem a while back where a statically-linked 
dll loading at the wrong address caused run_dtors to call addresses 
which are la-la land in the child process (sometimes even the dtor list 
itself was garbage). However, we don't run_ctors inforkee, and code in 
dll_list::alloc verifies that {data,bss}x{start,end} are where they belong.

If you're able to reproduce the problem, can you figure out whether it's 
a bad function address being called or a valid ctor crashing? My gut 
feeling is that communication with some other dll is failing, perhaps 
registering debug/unwind info with libgcc_s, or some perl module phoning 
home to the mothership.

Ryan