This is the mail archive of the
mailing list for the Cygwin project.
Re: How to correctly rebase?
- From: Ken Brown <kbrown at cornell dot edu>
- To: cygwin at cygwin dot com, Rainer dot Woitok at gmail dot com
- Date: Fri, 16 Oct 2015 11:07:58 -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>
On 10/16/2015 8:58 AM, Ken Brown wrote:
On 10/16/2015 4:49 AM, Dr Rainer Woitok wrote:
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.
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
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
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?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple