This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Large-Address awareness on 64 bit systems


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]