From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62572 invoked by alias); 16 Oct 2015 15:08:03 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 62555 invoked by uid 89); 16 Oct 2015 15:08:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: limerock02.mail.cornell.edu Received: from limerock02.mail.cornell.edu (HELO limerock02.mail.cornell.edu) (128.84.13.242) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Oct 2015 15:08:01 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock02.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id t9GF7x59020869; Fri, 16 Oct 2015 11:07:59 -0400 Received: from [192.168.1.7] (cpe-67-249-176-138.twcny.res.rr.com [67.249.176.138]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id t9GF7vB6018222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 16 Oct 2015 11:07:58 -0400 Subject: Re: How to correctly rebase? To: cygwin@cygwin.com, Rainer.Woitok@gmail.com References: <22046.25592.311399.765933@woitok.gmail.com> <8925F252-F479-4990-B568-1EC612DF39A5@etr-usa.com> <22047.42793.36600.773496@woitok.gmail.com> <41C9E795-AEEC-4378-8548-44DAF7DB98E7@etr-usa.com> <5620164E.1010508@cornell.edu> <22048.47638.206600.117271@woitok.gmail.com> <5620F460.7020605@cornell.edu> From: Ken Brown Message-ID: <562112CE.4040407@cornell.edu> Date: Fri, 16 Oct 2015 15:08:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5620F460.7020605@cornell.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00226.txt.bz2 On 10/16/2015 8:58 AM, Ken Brown wrote: > On 10/16/2015 4:49 AM, Dr Rainer Woitok wrote: >> Ken, >> >> On Thursday, 2015-10-15 17:10:38 -0400, you wrote: >> >>> ... >>> Another possibility is that those DLLs were in use. Rainer, did you make sure >>> that no Cygwin processes were running other than dash? >> >> Well, at least I tried to. I ran "/bin/ps -ef" and only saw one "ps" >> and one "ash" process. >> >>> ... >>> No, it's because rebase is called with the -s option, which implies the -d >>> option, which means that it starts at 0x70000000 and works down. >> >> Thanks for the explanation. This had escaped me. >> >>> Rainer, you >>> can run 'rebase -is' to see the full list of base addresses. >> >> I did, and I think this list os more or less the same as the output from >> "rebaslst". But I'll compare more thoroughly later. What caught my eye >> though is that both lists seemed sorted more or less with respect to de- >> scending file names, except for >> >> /usr/bin/cygLLVM-3.1.dll base 0x5ca90000 size 0x0128a000 >> /home/Rainer/repo/netcdf/bin/cygnetcdf-7.dll base 0x5dd20000 size 0x032a0000 >> /usr/bin/cygORBitCosNaming-2-0.dll base 0x61580000 size 0x0000c000 >> >> All my other local DLLs appear at the very end of these lists. Is this >> just the way "rebase" works internally or does this indicate a problem? > > I don't know off the top of my head, but I wouldn't worry about this. >> >> Talking about problems: Python still does not work (and perhaps other >> stuff I just haven't yet tried). Should I try re-installing Python? >> >> But I would be more at rest if this all would be sort of explainable. > > As Warren and Achim have both suggested, you may just have too many DLLs for > 32-bit Cygwin. Can you uninstall some unneeded packages? Or switch to 64-bit > Cygwin? > > By the way, I don't think you have yet attached cygcheck output as requested in > http://cygwin.com/problems.html: "Run cygcheck -s -v -r > cygcheck.out and > include that file as an attachment in your report. Please do not compress or > otherwise encode the output. Just attach it as a straight text file so that it > can be easily viewed." Maybe someone will spot something. I have one other suggestion: If you rebase because of a fork failure, reboot before retrying the application that failed. I just had the following experience: I was running emacs on my 32-bit Cygwin installation and got a fork failure involving /usr/bin/cygMagickCore-6.Q16-2.dll. Windows had loaded this DLL at a very low address. I did a full rebase and restarted emacs, but that DLL was still loaded at a low address, even though rebasing had put the base address at a very reasonable 0x6e550000. [You can see where a DLL is loaded in a process's address space by examining the file /proc//maps.] I then rebooted, restarted emacs, and verified that the DLL was now loaded at 0x6e550000, as expected. I've seen this happen many times. I don't know the explanation, but my guess is that Windows does some caching that causes it to try to load a given DLL at the same base address as it used the last time that DLL was loaded. Rebooting clears the cache. Can someone who understands this stuff confirm my guess or provide a better explanation? Ken -- 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