From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66219 invoked by alias); 16 Oct 2015 15:50:12 -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 66179 invoked by uid 89); 16 Oct 2015 15:50:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: Yes, score=5.1 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_THEBAT,LIKELY_SPAM_BODY,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: smtp.ht-systems.ru Received: from smtp.ht-systems.ru (HELO smtp.ht-systems.ru) (78.110.50.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 16 Oct 2015 15:50:10 +0000 Received: from [95.165.144.62] (helo=darkdragon.lan) by smtp.ht-systems.ru with esmtpa (Exim 4.80.1) (envelope-from ) (Authenticated sender: postmaster@rootdir.org) id 1Zn7Ge-0004r8-Kd ; Fri, 16 Oct 2015 18:50:04 +0300 Received: from [192.168.1.10] (HELO daemon2.darkdragon.lan) by daemon2 (Office Mail Server 0.8.12 build 08053101) with SMTP; Fri, 16 Oct 2015 15:41:37 -0000 Date: Fri, 16 Oct 2015 15:50:00 -0000 From: Andrey Repin Reply-To: cygwin@cygwin.com Message-ID: <898337219.20151016184136@yandex.ru> To: Ken Brown , cygwin@cygwin.com Subject: Re: How to correctly rebase? In-Reply-To: <562112CE.4040407@cornell.edu> 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> <562112CE.4040407@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00230.txt.bz2 Greetings, Ken Brown! > 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? prefetch/superfetch ? I normally disable this crap. I can live with boot times 15 seconds longer, and these kinds of services proved to slow down the system over the years at all times, no matter what is claimed in advertising. -- With best regards, Andrey Repin Friday, October 16, 2015 18:40:11 Sorry for my terrible english... -- 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