This is the mail archive of the cygwin@cygwin.com 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: Apache 1.3.22 on cygwin under XP - loosing data


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/


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