This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to correctly rebase?

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.

                                                                   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

By the way, I don't think you have yet attached cygcheck output as requested in  "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?


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]