Re: How to correctly rebase?

[cyg Simple <cygsimple@gmail.com>]

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