Mail Archives: cygwin/2002/05/29/08:57:24
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 AT thedixons DOT 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 AT insight DOT rr DOT com>
> To: <djnews AT thedixons DOT 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 AT thedixons DOT 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 AT insight DOT rr DOT com>
> > > To: "Dan Dixon" <dan AT thedixons DOT com>; <cygwin AT cygwin DOT 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/
- Raw text -