This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Large-Address awareness on 64 bit systems
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 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.
Ok, I'll have a deeper look if that happens again.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat