How to correctly rebase?

[Ken Brown]

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?

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