Re: Rebase 1.5-1: Causes invalid page fault

Re: Rebase 1.5-1: Causes invalid page fault

[Nicholas Wourms]

Jason,

Forgetting about apache, I want to focus on why rebase isn't working on
WindowsME.  First a question:  In the archives you were never clear about
which dll's should *NEVER* be included in the list to be rebased?  Also,
since these types of questions are coming up every now and then, I'm
willing to write a faq the list on how to use rebase, if you want....

As to my particular issue, I went and recompiled rebase without stripping
it and included debugging symbols.  I thought I'd give you the output of
DrMingw when I run rebase in the following way (provided by Chuck in an
earlier e-mail):
rebase -d -b 0x68000000 -o 0x10000 cygXpm-X4.dll cygXpm-noX4.dll \
     cygbz21.0.dll cygbz2-1.dll cygform5.dll cygform6.dll \
     cyggdbm.dll cyghistory4.dll cyghistory5.dll cygintl.dll \
     cygitcl30.dll cygitk30.dll cygjbig1.dll cygjpeg6b.dll cygmenu5.dll \
     cygmenu6.dll cygncurses++5.dll cygncurses++6.dll cygncurses5.dll \
     cygncurses6.dll cygpanel5.dll cygpanel6.dll cygpcre.dll \
     cygpcreposix.dll cygpng2.dll cygpng10.dll cygreadline4.dll \
     cygreadline5.dll cygregex.dll cygssl.dll cygtcl80.dll \
     cygtclreg80.dll cygtiff3.dll cygtk80.dll cygz.dll \
     /usr/lib/python2.2/lib-dynload/*.dll \
     /usr/lib/python2.2/site-packages/*.dll

Here's what Dr. Mingw says:
REBASE.EXE caused an Illegal Instruction at location 00000002.

Registers:
eax=aeebeeab ebx=0000000c ecx=0077fbac edx=84636178 esi=84636080
edi=0077fbe8
eip=00000002 esp=0077f948 ebp=0077f974 iopl=0         nv up ei ng nz na pe
nc
cs=0187  ss=018f  ds=018f  es=018f  fs=4aef  gs=0000            
efl=00010282

Call stack:
00000002
7B967382  IMAGEHLP.DLL:7B967382  ReBaseImage64
7B96711B  IMAGEHLP.DLL:7B96711B  ReBaseImage
0040154C  REBASE.EXE:0040154C  main  rebase.c:71
int main(
	int argc = 86,
	char * * argv = &0x007909d9
)
004010EC  REBASE.EXE:004010EC
00401203  REBASE.EXE:00401203
BFF7B9E4  KERNEL32.DLL:BFF7B9E4  IsDBCSLeadByte
BFF7B896  KERNEL32.DLL:BFF7B896  IsDBCSLeadByte
BFF7A24F  KERNEL32.DLL:BFF7A24F  MakeCriticalSectionGlobal

Ok next, I ran gdb on it and here are the results with a backtrace:
Program received signal SIGILL, Illegal instruction.

0x00000002 in ?? ()
(gdb) bt
#0  0x00000002 in ?? ()
#1  0x7b967382 in _libkernel32_a_iname ()
#2  0x7b96711b in _libkernel32_a_iname ()
#3  0x0040154c in main (argc=43, argv=0x8a0a20) at rebase.c:58

I hope that this might provide some better information for you.  Is there
any other source of information that can help resolve this problem?

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Rebase 1.5-1: Causes invalid page fault

[Jason Tishler]

Nicholas,

On Tue, Jun 18, 2002 at 04:51:16AM -0700, Nicholas Wourms wrote:
> First a question:  In the archives you were never clear about which
> dll's should *NEVER* be included in the list to be rebased?

I recommend skipping the DLLs that get corrupted by rebasing.  Back in
February, I determined that the following DLLs should be skipped:

    cygcurl-2.dll
    libW11.dll

Since there have been many new packages added since then, one needs to
determine if more DLLs need to be skipped too.

Additionally, it was recommended on cygwin-apps to avoid rebasing
cygwin1.dll.  Note, however that I have determined empirically that
rebasing cygwin1.dll does not corrupt it.

Unfortunately, the above is just a workaround.  We really need to figure
out why some DLLs get corrupted by rebasing.  I have evidence that it
may have something to due to with stripping.  I arrived at this
hypothesis because the PostgreSQL DLLs get corrupted if I rebase them
when they are stripped but do not when unstripped.  On the other hand,
may other DLLs (e.g., all of the Python ones) can be rebased after
stripping.

> Also, since these types of questions are coming up every now and then,
> I'm willing to write a faq the list on how to use rebase, if you
> want....

Yes, please.  I'm willing to review your drafts.

> As to my particular issue, I went and recompiled rebase without stripping
> it and included debugging symbols.
> [snip]
> Ok next, I ran gdb on it and here are the results with a backtrace:
> Program received signal SIGILL, Illegal instruction.
> 
> 0x00000002 in ?? ()
> (gdb) bt
> #0  0x00000002 in ?? ()
> #1  0x7b967382 in _libkernel32_a_iname ()
> #2  0x7b96711b in _libkernel32_a_iname ()
> #3  0x0040154c in main (argc=43, argv=0x8a0a20) at rebase.c:58
> 
> I hope that this might provide some better information for you.  Is there
> any other source of information that can help resolve this problem?

OK, the above indicates that rebase.exe is blowing up in the call to
ReBaseImage().  So, either these is a problem with ReBaseImage() (under
Me) or bad arguments are being passed.  Can you get the values of the
arguments?

Thanks,
Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Rebase 1.5-1: Causes invalid page fault

[Nicholas Wourms]

Jason,

--- Jason Tishler <jason@tishler.net> wrote:
> Nicholas,
> 
> I recommend skipping the DLLs that get corrupted by rebasing.  Back in
> February, I determined that the following DLLs should be skipped:
> 
>     cygcurl-2.dll
>     libW11.dll
> 
> Since there have been many new packages added since then, one needs to
> determine if more DLLs need to be skipped too.

Short of starting a program linked againsted a "potential" corrupted dll,
is there any other way to know if the dll was corrupted?  Perhaps some
heuristics in rebase to detect this (if possible) and restore the original
dll returning a message stating that corruption has occurred might be the
way to go?  Perhaps there is something common in the mangled dlls hex that
can be used to identify this corruption?

> Additionally, it was recommended on cygwin-apps to avoid rebasing
> cygwin1.dll.  Note, however that I have determined empirically that
> rebasing cygwin1.dll does not corrupt it.
> 
> Unfortunately, the above is just a workaround.  We really need to figure
> out why some DLLs get corrupted by rebasing.  I have evidence that it
> may have something to due to with stripping.  I arrived at this
> hypothesis because the PostgreSQL DLLs get corrupted if I rebase them
> when they are stripped but do not when unstripped.  On the other hand,
> may other DLLs (e.g., all of the Python ones) can be rebased after
> stripping.
> 
> Yes, please.  I'm willing to review your drafts.

I'll draw up a tentitive version using the LDP HOWTO sgml style and send
it as soon as it is ready.  You know, it occurs to me that cygwin is
getting big enough to justify a Cygwin Documentation Project...  Anyhow,
I'm going to cull the archives for questions on rebase, please tell me if
there are any other MLs on which you discussed this.
 
> OK, the above indicates that rebase.exe is blowing up in the call to
> ReBaseImage().  So, either these is a problem with ReBaseImage() (under
> Me) or bad arguments are being passed.  Can you get the values of the
> arguments?
> 
> Thanks,
> Jason

Forgive my ignorance, but how do you suggest I approach this?  Since
rebase isn't linked against cygwin1.dll, strace doesn't work on it.  Is
there a way to do this operation gdb or is there another tool I should
use?

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Rebase 1.5-1: Causes invalid page fault

[Jason Tishler]

Nicholas,

On Tue, Jun 18, 2002 at 05:52:46AM -0700, Nicholas Wourms wrote:
> --- Jason Tishler <jason@tishler.net> wrote:
> > Since there have been many new packages added since then, one needs to
> > determine if more DLLs need to be skipped too.
> 
> Short of starting a program linked againsted a "potential" corrupted dll,
> is there any other way to know if the dll was corrupted?  Perhaps some
> heuristics in rebase to detect this (if possible) and restore the original
> dll returning a message stating that corruption has occurred might be the
> way to go?

The above has already been suggested by Rob.  Although inconvenient, I
don't see a way around it unless someone figures out how to prevent the
corruption from occurring in the first place.

> Perhaps there is something common in the mangled dlls hex that can be
> used to identify this corruption?

At the command line, you can use file:

    $ file cygcurl-2.dll
    cygcurl-2.dll: MS Windows PE Intel 80386 console DLL
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    $ rebase -d -b 0x68000000 -o 0x10000 cygcurl-2.dll
    C:\cygwin\tmp\cygcurl-2.dll: new base = 67ff0000, new size = 30000

    $ file cygcurl-2.dll
    cygcurl-2.dll: MS-DOS executable (EXE), OS/2 or MS Windows
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Inside of a program, you can examine the PE header (specifically the PE
characteristics field).  See rebaser::is_rebaseable() in the following:

    http://cygwin.com/ml/cygwin-apps/2002-02/msg00010.html

for some ideas.

> > Yes, please.  I'm willing to review your drafts.
> 
> I'll draw up a tentitive version using the LDP HOWTO sgml style and send
> it as soon as it is ready.  You know, it occurs to me that cygwin is
> getting big enough to justify a Cygwin Documentation Project...  Anyhow,
> I'm going to cull the archives for questions on rebase, please tell me if
> there are any other MLs on which you discussed this.

It should "all" be on the cygwin lists, but I have discussed this issue
on the Python list too.  The Python discussion has been captured here:

    http://www.zope.org/Members/dgeorgieff/howto_zope_cvs_on_cygwin/

> > OK, the above indicates that rebase.exe is blowing up in the call to
> > ReBaseImage().  So, either these is a problem with ReBaseImage() (under
> > Me) or bad arguments are being passed.  Can you get the values of the
> > arguments?
> 
> Forgive my ignorance, but how do you suggest I approach this?  Since
> rebase isn't linked against cygwin1.dll, strace doesn't work on it.  Is
> there a way to do this operation gdb or is there another tool I should
> use?

Use gdb by setting a breakpoint ("b" command) at the call to
ReBaseImage() and then printing ("p" command) out the arguments.  Do
they look valid?

Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Rebase 1.5-1: Causes invalid page fault

[Nicholas Wourms]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1327 bytes --]

Jason,

[SNIP]
> 
> Use gdb by setting a breakpoint ("b" command) at the call to
> ReBaseImage() and then printing ("p" command) out the arguments.  Do
> they look valid?

Hmm gdb wouldn't let me set a breakpoint on ReBaseImage (it says the
symbol can't be found), so I just set it to line 58.  When I step through
the execution, I discover that the pathname argument prints out to:
"C:\\Cygnus\\cygwin\\bin\\cygXpm-noX4.dll\000¢ö¿\030Ö\003x\000Ö\003x\001\000\000\000\233\000\212\000(ýw\000Jä\000x\001\000\000\000!\000\000\000&»ö¿P\212­\201\030Ö\003x\000Ö\003x\013\000\000\000\234\000\212\000Pýw\000Jä\000x\013\000\000\000\000\000W\000&»ö¿\001\000\000\000\000\000W\000&»ö¿P\212­\2010\n\212\000\206\002\000\000è\035\000x\234ýw\000±Ì\000x\t\000\000\000¤Ì\000xx½­\201+\000\000\000\000\000W\000\000Ö\003x\233\000\212\000\000\000\212\00082\003xÿÿÿÿÀýw\000hÿw\000"

Is all that extra junk supposed to be tacked on?

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Rebase 1.5-1: Causes invalid page fault

[Christopher Faylor]

On Tue, Jun 18, 2002 at 08:35:47AM -0700, Nicholas Wourms wrote:
>>Use gdb by setting a breakpoint ("b" command) at the call to
>>ReBaseImage() and then printing ("p" command) out the arguments.  Do
>>they look valid?
>
>Hmm gdb wouldn't let me set a breakpoint on ReBaseImage (it says the
>symbol can't be found), so I just set it to line 58.  When I step
>through the execution, I discover that the pathname argument prints out
>to:
>"C:\\Cygnus\\cygwin\\bin\\cygXpm-noX4.dll\000???\030?\003x\000?\003x\001\000\000\000\233\000\212\000(?w\000J?\000x\001\000\000\000!\000\000\000&???P\212?\201\030?\003x\000?\003x\013\000\000\000\234\000\212\000P?w\000J?\000x\013\000\000\000\000\000W\000&???\001\000\000\000\000\000W\000&???P\212?\2010\n\212\000\206\002\000\000?\035\000x\234?w\000??\000x\t\000\000\000??\000xx??\201+\000\000\000\000\000W\000\000?\003x\233\000\212\000\000\000\212\00082\003x??????w\000h?w\000"
>
>Is all that extra junk supposed to be tacked on?

Probably.  It is a null terminated string so it should be fine.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Rebase 1.5-1: Causes invalid page fault

[Jason Tishler]

Nicholas,

On Tue, Jun 18, 2002 at 08:35:47AM -0700, Nicholas Wourms wrote:
> [SNIP]
> > 
> > Use gdb by setting a breakpoint ("b" command) at the call to
                                                  ^^^^^^^^^^^^^^
> > ReBaseImage() and then printing ("p" command) out the arguments.  Do
    ^^^^^^^^^^^^^
> > they look valid?
> 
> Hmm gdb wouldn't let me set a breakpoint on ReBaseImage (it says the
> symbol can't be found), so I just set it to line 58.

You *did* as I suggested -- sorry, if I was unclear.

> When I step through
> the execution, I discover that the pathname argument prints out to:
> "C:\\Cygnus\\cygwin\\bin\\cygXpm-noX4.dll\000???\030?\003x\000?...
                                           ^^^^

pathname is null terminated -- this is good.  Is it null terminated for
*all* DLLs?

> Is all that extra junk supposed to be tacked on?

pathname is defined as:

    char pathname[MAX_PATH + 1];

So, the "junk" is just the tail end of the character array.

Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Rebase 1.5-1: Causes invalid page fault

[Nicholas Wourms]

--- Jason Tishler <jason@tishler.net> wrote:
> > When I step through
> > the execution, I discover that the pathname argument prints out to:
> > "C:\\Cygnus\\cygwin\\bin\\cygXpm-noX4.dll\000???\030?\003x\000?...
>                                            ^^^^
> 
> pathname is null terminated -- this is good.  Is it null terminated for
> *all* DLLs?

Jason,

I'm going to have to start printing the arguments one by one as I step
through the execution, because it crashes before it can do the next loop. 
So in effect, the other dlls aren't being processed yet.  Sorry I had a
brain fart on the null termination, you're totally right on that one... 
Unfortunately, gdb refuses to restart execution from the beginning (it
will crap out), so I have to restart gdb each time.  Anyhow, I'll see what
I can't dig up now.  I'll admit I'm no wizard at writing code, so please
bear with me if I stumble now and then :-).

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Rebase 1.5-1: Causes invalid page fault

[Jason Tishler]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

Nicholas,

On Tue, Jun 18, 2002 at 09:09:10AM -0700, Nicholas Wourms wrote:
> --- Jason Tishler <jason@tishler.net> wrote:
> > pathname is null terminated -- this is good.  Is it null terminated for
> > *all* DLLs?
> 
> I'm going to have to start printing the arguments one by one as I step
> through the execution, because it crashes before it can do the next loop. 
> So in effect, the other dlls aren't being processed yet.

Hmm...  I just noticed that maybe the SymbolPath argument should be ""
(i.e., the empty string) and not 0 (i.e., the null pointer).  Please try
the attached patch.  Does this fix rebase for you?

Thanks,
Jason

[-- Attachment #2: rebase.c.diff --]
[-- Type: text/plain, Size: 458 bytes --]

--- rebase.c	2002/05/10 12:00:54	1.5
+++ rebase.c	2002/06/18 17:01:06
@@ -56,7 +56,7 @@ main (int argc, char *argv[])
       get_pathname (argv[i], pathname, sizeof (pathname));
       prev_new_image_base = new_image_base;
       aStatus = ReBaseImage (pathname,		/* CurrentImageName */
-			     0,			/* SymbolPath */
+			     "",		/* SymbolPath */
 			     TRUE,		/* fReBase */
 			     FALSE,		/* fRebaseSysfileOk */
 			     down_flag,		/* fGoingDown */


[-- Attachment #3: Type: text/plain, Size: 214 bytes --]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Rebase 1.5-1: Causes invalid page fault

[Nicholas Wourms]

Jason,

> 
> Hmm...  I just noticed that maybe the SymbolPath argument should be ""
> (i.e., the empty string) and not 0 (i.e., the null pointer).  Please try
> the attached patch.  Does this fix rebase for you?

Yes and no,

Here's what's happening:

1)I run it on the first two files and it works (though not really as
you'll see later on):

$ rebase -d -b 0x68000000 -o 0x10000 cygXpm-X4.dll cygXpm-noX4.dll
C:\Cygnus\cygwin\bin\cygXpm-X4.dll: new base = 67ff0000, new size = 10000 
                                                                   
C:\Cygnus\cygwin\bin\cygXpm-noX4.dll: new base = 67fe0000, new size =
10000

2)I run it on cygXpm-X4.dll cygXpm-noX4.dll cygbz21.0.dll, and it
pagefaults.

3)I run it on cygbz21.0.dll alone and it pagefaults.

Now here's the *Interesting part*

4)I run file on all three and the results are:

$ file cygXpm-X4.dll
cygXpm-X4.dll: MS-DOS executable (EXE), OS/2 or MS Windows
$ file cygXpm-noX4.dll
cygXpm-noX4.dll: MS-DOS executable (EXE), OS/2 or MS Windows
$ file cygbz21.0.dll
cygbz21.0.dll: MS Windows PE Intel 80386 console DLL

So it "works" on the dll's you say are corrupted but it won't work on the
other dll's which are intact.  Now how did these dll's get corrupted in
the first place is beyond me.  The further question is if they are indeed
really corrupt?  I haven't noticed any problems with X, so I assume they
aren't.  What is your thoughts on this?  I'm thinking I should run through
gdb with a file like cygbz21.0.dll.  Also, I have installed the Platform
SDK, so what arguments should I try with the rebase utility that comes
with it?

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Rebase 1.5-1: Causes invalid page fault

[Jason Tishler]

Nicholas,

On Tue, Jun 18, 2002 at 11:21:58AM -0700, Nicholas Wourms wrote:
> $ rebase -d -b 0x68000000 -o 0x10000 cygXpm-X4.dll cygXpm-noX4.dll
> C:\Cygnus\cygwin\bin\cygXpm-X4.dll: new base = 67ff0000, new size = 10000 
> C:\Cygnus\cygwin\bin\cygXpm-noX4.dll: new base = 67fe0000, new size = 10000

DLLs that get corrupted seem to display the expected output anyway.
Sigh...

> 2)I run it on cygXpm-X4.dll cygXpm-noX4.dll cygbz21.0.dll, and it
> pagefaults.
> 
> 3)I run it on cygbz21.0.dll alone and it pagefaults.
> 
> Now here's the *Interesting part*
> 
> 4)I run file on all three and the results are:
> 
> $ file cygXpm-X4.dll
> cygXpm-X4.dll: MS-DOS executable (EXE), OS/2 or MS Windows
> $ file cygXpm-noX4.dll
> cygXpm-noX4.dll: MS-DOS executable (EXE), OS/2 or MS Windows
> $ file cygbz21.0.dll
> cygbz21.0.dll: MS Windows PE Intel 80386 console DLL

You can also try objdump to test for corruption too:

    $ objdump -p cygcurl-2.dll
    objdump: cygcurl-2.dll: File format not recognized

> So it "works" on the dll's you say are corrupted but it won't work on the
> other dll's which are intact.

Maybe the two outcomes go through different code paths in ReBaseImage()?

> Now how did these dll's get corrupted in the first place is beyond me.

Maybe from a previous rebase run?  I strongly suggest playing with
copies of your DLLs -- not the originals.

> The further question is if they are indeed
> really corrupt?  I haven't noticed any problems with X, so I assume they
> aren't.  What is your thoughts on this?

Maybe you haven't used the corrupted DLLs?  I just tried with curl and
Windows popped up a dialog complaining that the DLL was "bad."

> I'm thinking I should run through gdb with a file like cygbz21.0.dll.

OK, but I'm not sure what more you will find.

> Also, I have installed the Platform SDK, so what arguments should I
> try with the rebase utility that comes with it?

I was going to suggest the above, but I wasn't sure if you had the SDK
or not.  Use the same arguments sans the offset (i.e., "-o") option
since the SDK's rebase doesn't support it.

BTW, under Windows 2000 I get the following:

    $ file cygXpm-*
    cygXpm-X4.dll:   MS Windows PE Intel 80386 console DLL
    cygXpm-noX4.dll: MS Windows PE Intel 80386 console DLL
    $ rebase -d -b 0x68000000 -o 0x10000 cygXpm-*
    C:\cygwin\tmp\cygXpm-X4.dll: new base = 67fe0000, new size = 20000
    C:\cygwin\tmp\cygXpm-noX4.dll: new base = 67fc0000, new size = 20000
    $ file cygXpm-*
    cygXpm-X4.dll:   MS Windows PE Intel 80386 console DLL
    cygXpm-noX4.dll: MS Windows PE Intel 80386 console DLL

Is it time to upgrade? :,)

Thanks,
Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Rebase 1.5-1: Causes invalid page fault

[Nicholas Wourms]

Jason,

--- Jason Tishler <jason@tishler.net> wrote:
[Snip]
> > Also, I have installed the Platform SDK, so what arguments should I
> > try with the rebase utility that comes with it?
> 
> I was going to suggest the above, but I wasn't sure if you had the SDK
> or not.  Use the same arguments sans the offset (i.e., "-o") option
> since the SDK's rebase doesn't support it.

I am beginning to think that rebasing dll's isn't necessary for WinME/9x,
due to the differences in memory management.  I only say this because in
the doco's from Microsoft ReBase.exe is referred to as the NT DLL Rebase
Tool.  Anyhow, here is what I get with sdk rebase:

REBASE: *** RelocateImage failed (cygbz21.0.dll).  Image may be corrupted

Any thoughts on this?

Cheers,
Nicholas


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Rebase 1.5-1: Causes invalid page fault

[Jason Tishler]

Nicholas,

On Wed, Jun 19, 2002 at 07:13:44AM -0700, Nicholas Wourms wrote:
> I am beginning to think that rebasing dll's isn't necessary for WinME/9x,
> due to the differences in memory management.  I only say this because in
> the doco's from Microsoft ReBase.exe is referred to as the NT DLL Rebase
> Tool.

Are you sure?  Because the MSDN:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/imagehlp_1hut.asp

states that ReBaseImage() is available on Windows 95/98/Me.

Additionally, the MSDN:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tools/perfutil_2z39.asp

does *not* indicate that rebase.exe is for NT only.

> Anyhow, here is what I get with sdk rebase:
> 
> REBASE: *** RelocateImage failed (cygbz21.0.dll).  Image may be corrupted
> 
> Any thoughts on this?

Maybe your cygbz21.0.dll was already corrupted?  Please try again with a
known good one from the tarball.  Use file to verify that the DLL is OK
before trying to rebase.

Thanks,
Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Rebase 1.5-1: Causes invalid page fault

[Nicholas Wourms]

--- Jason Tishler <jason@tishler.net> wrote:
> Are you sure?  Because the MSDN:

No....
 
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/imagehlp_1hut.asp
> 
> states that ReBaseImage() is available on Windows 95/98/Me.
> 
> Additionally, the MSDN:
> 
>    
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tools/perfutil_2z39.asp
> 
> does *not* indicate that rebase.exe is for NT only.

I know, it just is extemely frustrating :-).  I was quick to assume,
because I remebered the help for my SDK referring to it as the NT Rebase
utility or something like that.  You are most likely correct though.

> Maybe your cygbz21.0.dll was already corrupted?  Please try again with a
> known good one from the tarball.  Use file to verify that the DLL is OK
> before trying to rebase.

Ok, I just tried running it on the latest libpython2.2.dll both with the
SDK version and with Microsoft's version.  Here are the results:

MS ReBase.exe:
C:\Cygnus\cygwin\tmp\automake>"C:\Program Files\Microsoft
SDK\Bin\ReBase.exe" -d
 -b 0x68000000 libpython2.2.dll
REBASE: *** RelocateImage failed (libpython2.2.dll).  Image may be
corrupted

REBASE: Total Size of mapping 0x0000000000000000
REBASE: Range 0x0000000068000000 -0x0000000068000000

Ironically, when I checked this file in cygwin with "file", it says
libpython2.2.dll: MS Windows PE Intel 80386 console DLL
Does that mean it is ok?  Did rebase actually work?

Cygwin's rebase gave me the same pagefault as before.  So if the previous
indicates success, then at least we know it isn't me?

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Rebase 1.5-1: Causes invalid page fault

[Jason Tishler]

Nicholas,

On Thu, Jun 27, 2002 at 01:48:41PM -0700, Nicholas Wourms wrote:
> Ok, I just tried running it on the latest libpython2.2.dll both with the
> SDK version and with Microsoft's version.  Here are the results:
> 
> MS ReBase.exe:
> C:\Cygnus\cygwin\tmp\automake>"C:\Program Files\Microsoft SDK\Bin\ReBase.exe" -d -b 0x68000000 libpython2.2.dll
> REBASE: *** RelocateImage failed (libpython2.2.dll).  Image may be
> corrupted
> 
> REBASE: Total Size of mapping 0x0000000000000000
                                ^^^^^^^^^^^^^^^^^^
                                ******************

> REBASE: Range 0x0000000068000000 -0x0000000068000000
> 
> Ironically, when I checked this file in cygwin with "file", it says
> libpython2.2.dll: MS Windows PE Intel 80386 console DLL
>
> Does that mean it is ok?

I don't know.  Does python still work?

> Did rebase actually work?

I don't think so.  The above indicates a size of 0 -- this is bad.  You
can use objdump to verify if the rebasing was successful:

    $ objdump -p libpython2.2.dll | fgrep ImageBase
    ImageBase               67f30000

Note I get the following (under Windows 2000):

    $ rebase -d -b 0x68000000 libpython2.2.dll

    REBASE: Total Size of mapping 0x000d0000
    REBASE: Range 0x67f30000 -0x68000000

> Cygwin's rebase gave me the same pagefault as before.  So if the
> previous indicates success, then at least we know it isn't me?

Sorry, I don't have access to 9x/Me so you will have to debug the
problem with my rebase tool under Me.

Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re[2]: Rebase 1.5-1: Causes invalid page fault

[Pavel Tsekov]

[snip]

NW> Hmm gdb wouldn't let me set a breakpoint on ReBaseImage (it says the
NW> symbol can't be found), so I just set it to line 58.  When I step through
NW> the execution, I discover that the pathname argument prints out to:
NW> "C:\\Cygnus\\cygwin\\bin\\cygXpm-noX4.dll\000

You printed just the first argument.  There is a total of 11 arguments
to this function.

BOOL ReBaseImage(
  PSTR CurrentImageName,  
  PSTR SymbolPath,      
  BOOL fReBase,          
  BOOL fRebaseSysfileOk,  
  BOOL fGoingDown,       
  ULONG CheckImageSize,  
  ULONG *OldImageSize,  
  ULONG_PTR *OldImageBase,  
  ULONG *NewImageSize,  
  ULONG_PTR *NewImageBase,  
  ULONG TimeStamp        
);

It'll be good to look at all of them. The most dangerous should be the
pointer arguments though. Btw do you have the MS rebase.exe ? If you
have it, you can try it to see, if it crashes the same way as Jason's
tool. If this is the case, then maybe there is something wrong with
these APIs on WindowsMe or the image you're trying to rebase itself.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Re[2]: Rebase 1.5-1: Causes invalid page fault

[Nicholas Wourms]

Pavel,

--- Pavel Tsekov <ptsekov@syntrex.com> wrote:
[snip]
> 
> You printed just the first argument.  There is a total of 11 arguments
> to this function.
> 
> BOOL ReBaseImage(
>   PSTR CurrentImageName,  
>   PSTR SymbolPath,      
>   BOOL fReBase,          
>   BOOL fRebaseSysfileOk,  
>   BOOL fGoingDown,       
>   ULONG CheckImageSize,  
>   ULONG *OldImageSize,  
>   ULONG_PTR *OldImageBase,  
>   ULONG *NewImageSize,  
>   ULONG_PTR *NewImageBase,  
>   ULONG TimeStamp        
> );

Yes, I was being too hasty :-(.  I plan to look at them now.

> It'll be good to look at all of them. The most dangerous should be the
> pointer arguments though. Btw do you have the MS rebase.exe ? If you
> have it, you can try it to see, if it crashes the same way as Jason's
> tool. If this is the case, then maybe there is something wrong with
> these APIs on WindowsMe or the image you're trying to rebase itself.
> 

*Sigh* I was hoping I could avoid that bloat, but It looks like it is
inevitable...  Ok let me go get the platform sdk now...  A question
though, would rebasing dll's on another machine and then moving them to
this machine work?

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Rebase 1.5-1: Causes invalid page fault

[Jason Tishler]

On Tue, Jun 18, 2002 at 06:04:31PM +0200, Pavel Tsekov wrote:
> You printed just the first argument.  There is a total of 11 arguments
> to this function.
> 
> BOOL ReBaseImage(
>   PSTR CurrentImageName,  
>   PSTR SymbolPath,      
>   BOOL fReBase,          
>   BOOL fRebaseSysfileOk,  
>   BOOL fGoingDown,       
>   ULONG CheckImageSize,  
>   ULONG *OldImageSize,  
>   ULONG_PTR *OldImageBase,  
         ^^^^
         ****
>   ULONG *NewImageSize,  
>   ULONG_PTR *NewImageBase,  
         ^^^^
         ****
>   ULONG TimeStamp        
> );

The ULONG_PTR above is causing me some concern.  Note that the above
signature does *not* agree with the header file (either MinGW or MSVC)
and I cannot find the definition of ULONG_PTR.  Is the above a typo in
the MSDN or are OldImageBase and NewImageBase really suppose to be a
pointer to pointer?

Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re[2]: Rebase 1.5-1: Causes invalid page fault

[Pavel Tsekov]

JT> On Tue, Jun 18, 2002 at 06:04:31PM +0200, Pavel Tsekov wrote:
>> You printed just the first argument.  There is a total of 11 arguments
>> to this function.
>> 
>> BOOL ReBaseImage(
>>   PSTR CurrentImageName,  
>>   PSTR SymbolPath,      
>>   BOOL fReBase,          
>>   BOOL fRebaseSysfileOk,  
>>   BOOL fGoingDown,       
>>   ULONG CheckImageSize,  
>>   ULONG *OldImageSize,  
>>   ULONG_PTR *OldImageBase,  
JT>          ^^^^
JT>          ****
>>   ULONG *NewImageSize,  
>>   ULONG_PTR *NewImageBase,  
JT>          ^^^^
JT>          ****
>>   ULONG TimeStamp        
>> );

JT> The ULONG_PTR above is causing me some concern.  Note that the above
JT> signature does *not* agree with the header file (either MinGW or MSVC)
JT> and I cannot find the definition of ULONG_PTR.  Is the above a typo in
JT> the MSDN or are OldImageBase and NewImageBase really suppose to be a
JT> pointer to pointer?

The above is from help library that is coming with the downloadable
Platform SDK. It is dated November, 2001.

I just grepped /usr/include/w32api:

./basetsd.h:100:typedef  unsigned long ULONG_PTR, *PULONG_PTR;

So it is not a pointer to pointer. They have chosen a strange name
though :)


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Rebase 1.5-1: Causes invalid page fault

[Jason Tishler]

Pavel,

On Tue, Jun 18, 2002 at 10:41:10PM +0200, Pavel Tsekov wrote:
> JT> The ULONG_PTR above is causing me some concern.
> 
> The above is from help library that is coming with the downloadable
> Platform SDK. It is dated November, 2001.
>
> I just grepped /usr/include/w32api:

I grep-ed VC98/Include/*.H but not the Platform SDK (which I don't have
installed).

> ./basetsd.h:100:typedef  unsigned long ULONG_PTR, *PULONG_PTR;
> 
> So it is not a pointer to pointer. They have chosen a strange name
> though :)

Thanks for the above.

Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Re[2]: Rebase 1.5-1: Causes invalid page fault

[Bernard A Badger]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Pavel Tsekov
> Sent: Tuesday, June 18, 2002 4:41 PM
> To: cygwin@cygwin.com
> Subject: Re[2]: Rebase 1.5-1: Causes invalid page fault
> 
> 
> JT> On Tue, Jun 18, 2002 at 06:04:31PM +0200, Pavel Tsekov wrote:
> >> You printed just the first argument.  There is a total of 11 arguments
> >> to this function.
> >> 
> >> BOOL ReBaseImage(
> >>   PSTR CurrentImageName,  
[SNIP]
> >>   ULONG_PTR *OldImageBase,  
> JT>          ^^^^
> JT>          ****
> >>   ULONG *NewImageSize,  
> >>   ULONG_PTR *NewImageBase,  
> JT>          ^^^^
> JT>          ****
> >>   ULONG TimeStamp        
> >> );
> 
> JT> The ULONG_PTR above is causing me some concern.  Note that the above
> JT> signature does *not* agree with the header file (either MinGW or MSVC)
> JT> and I cannot find the definition of ULONG_PTR.  Is the above a typo in
> JT> the MSDN or are OldImageBase and NewImageBase really suppose to be a
> JT> pointer to pointer?
> 
> The above is from help library that is coming with the downloadable
> Platform SDK. It is dated November, 2001.
> 
> I just grepped /usr/include/w32api:
> 
> ./basetsd.h:100:typedef  unsigned long ULONG_PTR, *PULONG_PTR;
> 
> So it is not a pointer to pointer. They have chosen a strange name
> though :)

Which "it"?  I thought the concern was whether 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Re[2]: Rebase 1.5-1: Causes invalid page fault

[Bernard A Badger]

Below.
> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Pavel Tsekov
> Sent: Tuesday, June 18, 2002 4:41 PM
> To: cygwin@cygwin.com
> Subject: Re[2]: Rebase 1.5-1: Causes invalid page fault
>
>
> JT> On Tue, Jun 18, 2002 at 06:04:31PM +0200, Pavel Tsekov wrote:
> >> You printed just the first argument.  There is a total of 11 arguments
> >> to this function.
> >>
> >> BOOL ReBaseImage(
> >>   PSTR CurrentImageName,
> >>   PSTR SymbolPath,
> >>   BOOL fReBase,
> >>   BOOL fRebaseSysfileOk,
> >>   BOOL fGoingDown,
> >>   ULONG CheckImageSize,
> >>   ULONG *OldImageSize,
> >>   ULONG_PTR *OldImageBase,
> JT>          ^^^^
> JT>          ****
> >>   ULONG *NewImageSize,
> >>   ULONG_PTR *NewImageBase,
> JT>          ^^^^
> JT>          ****
> >>   ULONG TimeStamp
> >> );
>
> JT> The ULONG_PTR above is causing me some concern.  Note that the above
> JT> signature does *not* agree with the header file (either MinGW or MSVC)
> JT> and I cannot find the definition of ULONG_PTR.  Is the above a typo in
> JT> the MSDN or are OldImageBase and NewImageBase really suppose to be a
> JT> pointer to pointer?
>
> The above is from help library that is coming with the downloadable
> Platform SDK. It is dated November, 2001.
>
> I just grepped /usr/include/w32api:
>
> ./basetsd.h:100:typedef  unsigned long ULONG_PTR, *PULONG_PTR;
>
> So it is not a pointer to pointer. They have chosen a strange name
> though :)
Which "it" are you talking about?
The typedef you found defines ULONG_PTR as a pointer to unsigned long,
and also defines PULONG_PTR as a pointer to pointer to unsigned long.
But I thought the issue was the type of NewImageBase.

The question was whether
	ULONG_PTR *NewImageBase,
defined a pointer to a pointer --- it does!
*NewImageBase defines NewImageBase as a pointer to ULONG_PTR,
which is itself a pointer, so it is, again, a
pointer-to-pointer-to-unsigned-long.



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Re[2]: Rebase 1.5-1: Causes invalid page fault

[Jon Cast]

Bernard A Badger <bab@vx.com> wrote:

> > -----Original Message-----
> > From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> > Of Pavel Tsekov
> > Sent: Tuesday, June 18, 2002 4:41 PM
> > To: cygwin@cygwin.com
> > Subject: Re[2]: Rebase 1.5-1: Causes invalid page fault

<snipped/>
> > The above is from help library that is coming with the
> > downloadable Platform SDK. It is dated November, 2001.

> > I just grepped /usr/include/w32api:

> > ./basetsd.h:100:typedef  unsigned long ULONG_PTR, *PULONG_PTR;

> > So it is not a pointer to pointer. They have chosen a strange name
> > though :)

> Which "it" are you talking about?  The typedef you found defines
> ULONG_PTR as a pointer to unsigned long, and also defines PULONG_PTR
> as a pointer to pointer to unsigned long.  But I thought the issue
> was the type of NewImageBase.

No, `typedef unsigned long ULONG_PTR' defines `ULONG_PTR' as a synonym
for `unsigned long'.

Btw., if I remember the MSDN documentation correctly, ULONG_PTR is
supposed an integer with the the same /size/ as a pointer, but also a
typedef for unsigned long where possible.  Hence the name.

> The question was whether
> 	ULONG_PTR *NewImageBase,
> defined a pointer to a pointer --- it does!  *NewImageBase defines
> NewImageBase as a pointer to ULONG_PTR, which is itself a pointer,
> so it is, again, a pointer-to-pointer-to-unsigned-long.

No, it's a pointer to unsigned long which is really a pointer.

Jon Cast

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Re[2]: Rebase 1.5-1: Causes invalid page fault

[Bernard A Badger]

> -----Original Message-----
> > > ./basetsd.h:100:typedef  unsigned long ULONG_PTR, *PULONG_PTR;
> > > So it is not a pointer to pointer. They have chosen a strange name
> > > though :)
> 
> > Which "it" are you talking about?  The typedef you found defines
> > ULONG_PTR as a pointer to unsigned long, and also defines PULONG_PTR
> > as a pointer to pointer to unsigned long.  But I thought the issue
> > was the type of NewImageBase.
> 
> No, `typedef unsigned long ULONG_PTR' defines `ULONG_PTR' as a synonym
> for `unsigned long'.
> 
> Btw., if I remember the MSDN documentation correctly, ULONG_PTR is
> supposed an integer with the the same /size/ as a pointer, but also a
> typedef for unsigned long where possible.  Hence the name.
> 
> > The question was whether
> > 	ULONG_PTR *NewImageBase,
> > defined a pointer to a pointer --- it does!  *NewImageBase defines
> > NewImageBase as a pointer to ULONG_PTR, which is itself a pointer,
> > so it is, again, a pointer-to-pointer-to-unsigned-long.
> 
> No, it's a pointer to unsigned long which is really a pointer.
> 
> Jon Cast
Ack!  You are so right!  I was blinded by the "_PTR" in the name ULONG_PTR,
and didn't understand that that was the "strange name" you meant.

My apologies to all.



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/