Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes REDUX

[Ed Gaines]

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,so.in > 
>> 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,so.in 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,so.in > 
>> 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,so.in
and dot exe.in 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,so.in > 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,so.in; and
     <file with list of exe files>         =>  dotexe.in

Both of which I generated with the find command thus:

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

>> Don't know whether that warning's important, but with the confidence 
>> born of
>> total ignorance, I press on:
> 
>>     $ /bin/peflags -t0 -v -T dotexe.in > 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:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple