Re: Apache 1.3.22 on cygwin under XP - loosing data

Re: Apache 1.3.22 on cygwin under XP - loosing data

[Paul McFerrin]

Nice thought...  I did verify that all of the mounts are binmode mounts.

I saved one of the bad images that the browser downloaded and compared it with the original
file on disk.  Here is what I've observed....
	- The two files (good & bad) were identical in size!
	- The bad file did contain some \n and \r but there were not adjacent.

I did a "cmp good_file bad_file" and here is a partial output:
 32769 172   0  
 32771 377 341
 32772   0 303
 32773 274   0
 32774 333   0
 32775 234 342
 32776 204 303
 32777  50  22
 32778 262   0
 32779   7   0
 32780 146   0
 32781  41 265
 ...

As you can see, it is NOT a cr/nl problem.  It looks like bits are getting dropped.  Another
thing to note, I can purge my cache and reload the page.  The reloaded page is still screwey
but NOT in an identical fashion.  If it was a cr/nl problem, I would expect it to be
reproducable.

-paul mcferrin


Dan Dixon wrote:
> 
> I have the same problem with the install I did tonight.
> Just a guess, but you know what it looks like?  It looks
> like a text/binary mode issue.  Any picture that has a cr/lf
> in it will get trashed, but not every picture.  I'm going to
> write a perl script to check for this and see if it lines up
> with the pictures that are getting trashed.  Now I have
> now idea how to fix this :)
> 
> -dan

--
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: Apache 1.3.22 on cygwin under XP - loosing data

[djnews]

I agree with what you found.  I now can get it to fail on plain html text as
well.
It usually starts to corrupt bits at around the 32K point.  I can pull up
hundreds
of thumbnails (~10-20K) without a problem. Out of hundreds of bigger
jpgs, 100% of the bad ones are >32K and 100% of the bad ones are <40K
(but it is not a clean break at 32K).  Also, text htmls go bad around the
same
point.  I have actually gotten it to pick up what looks like data from
another
file on disk!  I have seen that behavior 3 or 4 times.

I have tried the httpd binary that came with the cygwin distribution as well
as the build you can link to on the "Software" page.  They both fail.
I know they are the same revision (Apache/1.3.24 (cygwin)) but they are
wildly differrent sizes so I figured I'd try them both.

I have not yet download the win32 build at apache.org but I might try
that next.

-dan
----- Original Message -----
From: "Paul McFerrin" <pmcferrin@insight.rr.com>
To: "Dan Dixon" <dan@thedixons.com>; <cygwin@cygwin.com>
Sent: Monday, May 27, 2002 2:31 PM
Subject: Re: Apache 1.3.22 on cygwin under XP - loosing data


> Nice thought...  I did verify that all of the mounts are binmode mounts.
>
> I saved one of the bad images that the browser downloaded and compared it
with the original
> file on disk.  Here is what I've observed....
> - The two files (good & bad) were identical in size!
> - The bad file did contain some \n and \r but there were not adjacent.
>
> I did a "cmp good_file bad_file" and here is a partial output:
>  32769 172   0
>  32771 377 341
>  32772   0 303
>  32773 274   0
>  32774 333   0
>  32775 234 342
>  32776 204 303
>  32777  50  22
>  32778 262   0
>  32779   7   0
>  32780 146   0
>  32781  41 265
>  ...
>
> As you can see, it is NOT a cr/nl problem.  It looks like bits are getting
dropped.  Another
> thing to note, I can purge my cache and reload the page.  The reloaded
page is still screwey
> but NOT in an identical fashion.  If it was a cr/nl problem, I would
expect it to be
> reproducable.
>
> -paul mcferrin
>
>
> Dan Dixon wrote:
> >
> > I have the same problem with the install I did tonight.
> > Just a guess, but you know what it looks like?  It looks
> > like a text/binary mode issue.  Any picture that has a cr/lf
> > in it will get trashed, but not every picture.  I'm going to
> > write a perl script to check for this and see if it lines up
> > with the pictures that are getting trashed.  Now I have
> > now idea how to fix this :)
> >
> > -dan
>
>


--
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: Apache 1.3.22 on cygwin under XP - loosing data

[Paul McFerrin]

Dan:

I had to rebase everything manually myself.  Without the rebase, the httpd processes could
not even complete a fork!  The arguments that I used were the same used by someone else for
a different application and not specificially Apache.

I've asked someone to shed some light on educating me on just what those arguments mean so I
don't have to be in the dark on this subject.  Heck I really don't know if they are suitable
for Apache.

I too would like to get this issue resolved.  Jason are you listening?

-paul mcferrin

djnews@thedixons.com wrote:
> 
> I'm clueless at this point, sorry. It'd sure be nice to get this working
> though.
> By the way, is that rebase command being run in an install somewhere or
> did you run that manually?  As far as I know, I didn't run it anywhere.
> 
> -dan
> 
> ----- Original Message -----
> From: "Paul McFerrin" <pmcferrin@insight.rr.com>
> To: <djnews@thedixons.com>
> Sent: Monday, May 27, 2002 9:44 PM
> Subject: Re: Apache 1.3.22 on cygwin under XP - loosing data
> 
> > I just downloaded an .exe file that was larger tnan 1MB.  When I did a
> comparison of the
> > downloaded file with the original file, the byte offset of the first
> incorrect byte was at
> > 32769.  I repeated this experiment with another .exe file and again the
> first incorrect byte
> > was at 32769.  The incorrect bytes continued until the end of the file.
> >
> > This seems to substantiate your theory of the 32K boundary.
> >
> > I would like for someone to explain to me what the following command is
> doing to the DLL's:
> > $ rebase -d -b 0x68000000 -o 0x10000 ... file
> > Could it be that the values supplied might not be totally correct for this
> application?
> > Since I really have no knowledge, making adjustment to these values would
> definitely put me
> > into the dark.
> >
> > This is my last application to be moved over to the XP platform.  Once it
> is move, I will
> > have a surplus machine.
> >
> > -Paul McFerrin
> >
> > djnews@thedixons.com wrote:
> > >
> > > I agree with what you found.  I now can get it to fail on plain html
> text as
> > > well.
> > > It usually starts to corrupt bits at around the 32K point.  I can pull
> up
> > > hundreds
> > > of thumbnails (~10-20K) without a problem. Out of hundreds of bigger
> > > jpgs, 100% of the bad ones are >32K and 100% of the bad ones are <40K
> > > (but it is not a clean break at 32K).  Also, text htmls go bad around
> the
> > > same
> > > point.  I have actually gotten it to pick up what looks like data from
> > > another
> > > file on disk!  I have seen that behavior 3 or 4 times.
> > >
> > > I have tried the httpd binary that came with the cygwin distribution as
> well
> > > as the build you can link to on the "Software" page.  They both fail.
> > > I know they are the same revision (Apache/1.3.24 (cygwin)) but they are
> > > wildly differrent sizes so I figured I'd try them both.
> > >
> > > I have not yet download the win32 build at apache.org but I might try
> > > that next.
> > >
> > > -dan
> > > ----- Original Message -----
> > > From: "Paul McFerrin" <pmcferrin@insight.rr.com>
> > > To: "Dan Dixon" <dan@thedixons.com>; <cygwin@cygwin.com>
> > > Sent: Monday, May 27, 2002 2:31 PM
> > > Subject: Re: Apache 1.3.22 on cygwin under XP - loosing data
> > >
> > > > Nice thought...  I did verify that all of the mounts are binmode
> mounts.
> > > >
> > > > I saved one of the bad images that the browser downloaded and compared
> it
> > > with the original
> > > > file on disk.  Here is what I've observed....
> > > > - The two files (good & bad) were identical in size!
> > > > - The bad file did contain some \n and \r but there were not adjacent.
> > > >
> > > > I did a "cmp good_file bad_file" and here is a partial output:
> > > >  32769 172   0
> > > >  32771 377 341
> > > >  32772   0 303
> > > >  32773 274   0
> > > >  32774 333   0
> > > >  32775 234 342
> > > >  32776 204 303
> > > >  32777  50  22
> > > >  32778 262   0
> > > >  32779   7   0
> > > >  32780 146   0
> > > >  32781  41 265
> > > >  ...
> > > >
> > > > As you can see, it is NOT a cr/nl problem.  It looks like bits are
> getting
> > > dropped.  Another
> > > > thing to note, I can purge my cache and reload the page.  The reloaded
> > > page is still screwey
> > > > but NOT in an identical fashion.  If it was a cr/nl problem, I would
> > > expect it to be
> > > > reproducable.
> > > >
> > > > -paul mcferrin
> > > >
> > > >
> > > > Dan Dixon wrote:
> > > > >
> > > > > I have the same problem with the install I did tonight.
> > > > > Just a guess, but you know what it looks like?  It looks
> > > > > like a text/binary mode issue.  Any picture that has a cr/lf
> > > > > in it will get trashed, but not every picture.  I'm going to
> > > > > write a perl script to check for this and see if it lines up
> > > > > with the pictures that are getting trashed.  Now I have
> > > > > now idea how to fix this :)
> > > > >
> > > > > -dan
> > > >
> > > >
> > >
> > > --
> > > 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/
> >
> >

--
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: Apache 1.3.22 on cygwin under XP - loosing data

[Jason Tishler]

Paul,

On Wed, May 29, 2002 at 08:32:13AM -0400, Paul McFerrin wrote:
> I had to rebase everything manually myself.  Without the rebase, the
> httpd processes could not even complete a fork!

The above is a well known issue that affects other Cygwin applications
such as Python too.

> The arguments that I used were the same used by someone else for a
> different application and not specificially Apache.

The above is correct.

> I've asked someone to shed some light on educating me on just what
> those arguments mean so I don't have to be in the dark on this subject.

The options to my rebase tool:

    $ rebase     
    usage: rebase -b BaseAddress [-d] [-o Offset] ImageFileName ...

have the same semantics as the ones supported by MS's tool:

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

I added the "-o Offset" option to spread out the base address by an
extra Offset amount because packing the DLLs "too close" can Cygwin's
fork() to still fail.

> Heck I really don't know if they are suitable for Apache.

Rebasing is suitable for all Cygwin apps that suffer from the DLL base
address conflict fork() issue.  Unfortunately, some DLLs do not survive
the rebase process.  It is yet to be determined why.  Want to help
figure this out?

> I too would like to get this issue resolved.

Me too.  The rebase functionality will ultimately be integrated into
Cygwin's setup.exe.

> Jason are you listening?

Yes.  Hmm...

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/