X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=HM0tE7ltfUsYZqZe
	z8YeZNaEyiJf+qruYREMjZ8MuEjDH5VxMmIvFrUaPppy4w0NLG69k6RUdzPaH/+t
	ck+rghtStsyzkombruRm2ogdZikBJuaJMF+nUgpXwGauTUuXQte/+F06V9NQUUQI
	Ez8E+uLj8XimRVLxG0jNQbNPlpY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=gQr/fzU9Gg95aEfbDyZXVy
	WPtcM=; b=VpbfF5S8h3AwBkMMa81tMlH+7VnGGXr+V2sjvPcuI7lTLc4L6q20A6
	ht1Tr6uh7px1QJoqBGy6ydlwjl/WPB8kH4EN9KMioxx1INO0wMoMBlhHI5Cx4cbQ
	G2r2Nw1/4gssSqDnU8h107oVQgUatmITrkBUF4Ax299pVx7KRasqA=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-yk0-f173.google.com
X-Received: by 10.129.72.147 with SMTP id v141mr10542881ywa.70.1445008577760;        Fri, 16 Oct 2015 08:16:17 -0700 (PDT)
Subject: Re: How to correctly rebase?
To: cygwin AT cygwin DOT com
References: <22046 DOT 25592 DOT 311399 DOT 765933 AT woitok DOT gmail DOT com> <8925F252-F479-4990-B568-1EC612DF39A5 AT etr-usa DOT com> <22047 DOT 42793 DOT 36600 DOT 773496 AT woitok DOT gmail DOT com> <41C9E795-AEEC-4378-8548-44DAF7DB98E7 AT etr-usa DOT com> <5620164E DOT 1010508 AT cornell DOT edu> <22048 DOT 47638 DOT 206600 DOT 117271 AT woitok DOT gmail DOT com> <5620F460 DOT 7020605 AT cornell DOT edu> <562112CE DOT 4040407 AT cornell DOT edu>
From: cyg Simple <cygsimple AT gmail DOT com>
X-Enigmail-Draft-Status: N1110
Message-ID: <562114AF.7040704@gmail.com>
Date: Fri, 16 Oct 2015 11:15:59 -0400
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: <562112CE.4040407@cornell.edu>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-IsSubscribed: yes

On 10/16/2015 11:07 AM, Ken Brown wrote:
> 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/<PID>/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?

Could it be something similar to
http://windowsitpro.com/systems-management/how-can-i-stop-windows-caching-dll-file-after-i-close-program-was-accessing-it?

-- 
cyg Simple

--
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