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: Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes REDUX

Eliot Moss wrote:

I should have asked you in my last email: should I have reloaded cygwin
prior to attempting to use the steps you prescribed in your response?

What does "reloaded" mean?

Reinstalled, in other words. Poor choice of words on my part...

Best procedure is:

- reboot system
- open a cmd window
- start ash
- do rebasing, peflags hacking from ash -- no bash
  subprocesses, etc.

If I run vim under ash to edit the files which contain the .so, .dll, and .exe files (to remove files that rebase and peflags barf upon), won't that fire up various cygwin processes? And thus foul the rebase/peflag process? Do I need to use Windows's notepad editor or something equally lame? :-)

$ /bin/rebase -d -b 0x61000000 -o 0x20000 -v -T dll, > rebase.out
./bin/cyglsa64.dll: fixing bad relocations
FixImage (./bin/cyglsa64.dll) failed with last error = 13

When this happens, rebase *stops*. You need to remove the file from the list
and rebase again.

Yup. That's what I did.

Okay, it makes some sort of intuitive sense that trying to rebase a 64b dll
in a 32b system should be dicey [incidentally, is there a guide somewhere to
these "last error" codes?]. So I removed "./bin/cyglsa64.dll" from the
dll, file and retried:

One might have to go into the rebase source code ...

I'll give that a shot.

$ /bin/rebase -d -b 0x61000000 -o 0x20000 -v -T dll, > rebase.out
ReBaseImage (./bin/cygwin1.dll) failed with last error = 6

You've probably run something that needed cygwin1.dll. Hence the reboot, etc., above, and the care not to run any bash stuff, etc.

I didn't THINK I was running any bash stuff, though I did edit the dll, and dot files with a copy of gvim from a non-cygwin distribution -- which I ran it by double clicking the input files' icons in the Windows explorer window (not from within any cygwin window or shell). But it's conceivable that that I might have munged my PATH or LDPATH variables, and thus directed my non-cygwin gvim to libs from the cygwin distro. If ash doesn't fire up any cygwin libraries (beyond its own executable), then I MUST have done SOMETHING similarly bone-headed.

Alas, still no joy. And this time it's barfing on cygwin1.dll, pretty much
one of the prime dlls I would have thought needed rebasing... Not sure what
error 6 means, ...

In use, I think ...

Yeah, that's the way to bet...

But of course, cygwin1.dll IS in use because it underlies ash.exe.

No, I don't think it does -- ash is special.

You must be correct, or the process would never work for ANYONE.

... And then I ran peflags as follows:

Sure, that's fine ...

$ /bin/peflags -d0 -v -T dll, > peflags-d.out
Warning: file is non-executable but has tsaware set (./bin/cyglsa.dll).

If you look carefully at my instructions, I think that one says exe files only.

Yup. The relevant excerpt from your instructions was:

    /bin/peflags -d0 -v -T <file with list of dll and so files> > peflags-d.out
    /bin/peflags -t0 -v -T <file with list of exe files>        > peflags-t.out

In my case,

    <file with list of dll and so files>  =>  dll,; and
    <file with list of exe files>         =>

Both of which I generated with the find command thus:

    find /cygdrive/c/cygwin -iname "*.dll" -print >> dll,
    find /cygdrive/c/cygwin -iname "*.so" -print >> dll,
    find /cygdrive/c/cygwin -iname "*.exe" -print >>

Don't know whether that warning's important, but with the confidence born of
total ignorance, I press on:

$ /bin/peflags -t0 -v -T > peflags-t.out
Error: could not update pe characteristics (./bin/peflags.exe): Device or resource busy

I didn't get that, I don't think, but hardly matters since you don't run peflags often and if is not the source of the fork problems :-) ...

Okay, now I reboot, re-activate BitDefender's "Advanced Virus Control"...
And I bring up an rxvt-native window. Windows's annoying little rotating
circle cogitates for about 10 seconds before I get a prompt (reproduced
below) and attempt to run an "ls" command. Notice that the prompt does not,
as is ordinary, show the current directory:

$ ls

Yet more blue spinning circle for about the same length of time, followed by


Wierd. Not sure what to say, but the (few) differences between what happens for me and for you may be significant.

I think the key problem was that I must have in some way managed to fire up components of the cygwin1.dll via some ancillary process I had going on at the time. Else, the rebasing process wouldn't have lost its lunch upon attempting to rebase cygwin1.dll. How I did that, I can't say. But I think your admonition to perform a reboot prior to beginning the process is a good one, so I'll give it a go with that.

So at last, the questions:

1) Should I have reloaded cygwin prior to running your command set?

Again, I don't know what "reloaded" means.

Sorry. I meant "reinstall" -- i.e., install new copies of all the cygwin distro files over the top of the old ones. I thought, without much in the way of knowledge to guide me, that perhaps it might in some way un-snarl any egregious errors I'd committed by screwing up the rebase process. I'll be more careful with my terminology in future.

*Rebooting* so that cygwin1.dll is
not around in main memory is probably important.

Makes sense. I used a process manager to manually quiesce any cygwin processes I could see. But that doesn't mean I caught them all.

2) Should I have rebased cygwin1.dll from a cmd shell prior to or after
   running your commands?  As follows, perhaps?

If you rebase it manually, you need to make sure that other thigns won't collide with it, but you could do.

3) OPTIONAL QUESTION: Odd that I didn't notice before, but you used the
   -d flag to rebase, which the rebase.3.0.1.README file tells me
   means "rebase down memory (default: up)."  I'm assuming ...

Going down is important; there's other junk above 0x61000000, which is why we start there and work down.

I understand. Guess I need either better tools or better books if I'm going to find out just WHAT's above that address :-) But I certainly agree with the wisdom of simply doing what works!

Best wishes -- EM

Same here. Have a good weekend, and thanks for all your help!

-- Ed

-- Problem reports: FAQ: Documentation: Unsubscribe info:

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