Large-Address awareness on 64 bit systems

Corinna Vinschen
Tue Jun 28 15:47:00 GMT 2011

On Jun 28 10:54, Ryan Johnson wrote:
> 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  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.

Ok, I'll have a deeper look if that happens again.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list