This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: How to correctly rebase?
- From: cyg Simple <cygsimple at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 16 Oct 2015 11:15:59 -0400
- Subject: Re: How to correctly rebase?
- Authentication-results: sourceware.org; auth=none
- 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>
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