snprintf & release schedule

[Marc Slemko <ma...@znep.com>]

The way things are looking, I will have my buffer overflow patches
finished up Friday night.  At that point, I will send them out and beg
people to review them closely.  Hopefully they can get reviewed by a few
people within a day or so.  

Then we need to bring in ap_snprintf into the tree.  We either need it
working on 64-bit machines or need to say "this beta won't work on 64-bit
machines unless you have snprintf".  

At that point, what is left before the next beta can be released?  If
there is anything else that needs to go in before 1.2, it should be done
now if possible.  

The FIN_WAIT_2 stuff is a big problem.  I have a report from a SunOS user
that NO_LINGCLOSE did _not_ help but using my hacked http_main.c did.
Still trying various things to see what it was, should know more tomorrow,
but it looks like there may be something in the wait_or_timeout changes.  

Any other issues that should be resolved should be brought up now if we
want to avoid 43 patches the hour before the beta...

Possible ones:
	- ssi slowness
	- finalize/cleanup indexing fix

...and a bunch of others I don't have time to pay attention to.

1.2 doesn't seem to be as settled as I would like yet, but... hopefully it
will come together.

Re: snprintf & release schedule

[Marc Slemko <ma...@znep.com>]

On Fri, 17 Jan 1997, Brian Behlendorf wrote:

> I'd say the snprintf patch is the only thing I would want before the next beta.
> Lots of unresolved bugs in the bugdb I at least want to look at before 1.2
> final.

Then I'm not sure we will get a stable 1.2 out with a 1.2b5 --> 1.2b6 -->
1.2 timeline.

Ideal situation would be that the last beta and the release would be
identical except for version number.  That doesn't look very likely, but
we still need to be as close to that as possible.  Take 1.1.2 as an
example.  Two quick changes, one very trivial, two bugs.

IMHO, anyone who thinks that 1.2 will be the last release before 2.0 is
deluded, that is if 1.2 is released in a couple of weeks.

Re: snprintf & release schedule

[ra...@lerdorf.on.ca]

> We are tracking multiple targets; it isn't voodo, but it is hard to make
> corrolations when there appears to be more than one problem WRT
> FIN_WAIT_2. It is slow going because I can't reproduce the problem, so
> everything is a guess. 

I tuned out on this thread long ago because I really don't have a clue in
that part of the code.  However, having checked my error_log on one of
the machines I run, I see:

[Fri Jan 17 10:14:59 1997] shutdown: Connection reset by peer
[Fri Jan 17 10:14:59 1997] - lingering_close
[Fri Jan 17 10:15:37 1997] shutdown: Connection reset by peer
[Fri Jan 17 10:15:37 1997] - lingering_close
[Fri Jan 17 10:15:51 1997] shutdown: Connection reset by peer
[Fri Jan 17 10:15:51 1997] - lingering_close
[Fri Jan 17 10:17:13 1997] shutdown: Connection reset by peer
[Fri Jan 17 10:17:13 1997] - lingering_close
[Fri Jan 17 10:17:50 1997] shutdown: Connection reset by peer
[Fri Jan 17 10:17:50 1997] - lingering_close
[Fri Jan 17 10:18:56 1997] shutdown: Connection reset by peer
[Fri Jan 17 10:18:56 1997] - lingering_close
[Fri Jan 17 10:20:54 1997] shutdown: Connection reset by peer
[Fri Jan 17 10:20:54 1997] - lingering_close

I assume this is the symptom of this problem?  It looks like there is 
some correlation between these errors and some specific entries in the
access_log.  Before I start writing some scripts to dig out this information,
please confirm that this is the symptom we are chasing.

-Rasmus

Re: snprintf & release schedule

[Marc Slemko <ma...@znep.com>]

On Fri, 17 Jan 1997, Brian Behlendorf wrote:

[...FIN_WAIT_2 stuff...]

> I have been left in the dust by the voluminous conversation on this matter -
> since it appears to still be voodoo despite the hours spent on it, would it be
> worth writing up a complete problem report, and sending it out over the
> apache-announce mailing list?  I think so.  I would expect *someone* to know
> what's going on.  Maybe even provide some compilation options so folks can test
> different "fixes" and give feedback on them.  I guess I'm saying, if we're
> running out of brainpower on this list to solve this, we've got an army of fans
> to help us solve the problem.  We just need to make sure we don't waste their
> time by asking the wrong questions.

Hey, chop your line length.  <g>

I have asked everyone I can find with the problem to try a few things (I
posted the list here) and that has tracked things down to:
	- NO_LINGWAIT does help a LOT sometimes
	- NO_LINGWAIT does not help one bit sometimes

We aren't running out of brainpower (I don't think...) but we are running
out of people who know for SURE what the code is doing and why (must be a
half dozen "perhaps bugs" that were brought up in this area) and we are
running out of time.  People only take so many betas before they say "oh,
1.2b931?  I'll skip it...".  A stable 1.2 release (not necessarily the
first 1.2 release) is likely more than a month away.

We are tracking multiple targets; it isn't voodo, but it is hard to make
corrolations when there appears to be more than one problem WRT
FIN_WAIT_2. It is slow going because I can't reproduce the problem, so
everything is a guess. 

Re: snprintf & release schedule

[Brian Behlendorf <br...@organic.com>]

On Fri, 17 Jan 1997, Marc Slemko wrote:
> Then we need to bring in ap_snprintf into the tree.  We either need it
> working on 64-bit machines or need to say "this beta won't work on 64-bit
> machines unless you have snprintf".  

Irix 6.2 does not appear to have snprintf.  Maybe 6.3 or 6.4 does, I don't
know.  At least, "man snprintf" and "grep snprintf" on files under /usr/include
didn't return anything.

Marc, if you want a login to a 6.2 machine I can probably arrange that.

> At that point, what is left before the next beta can be released?  If
> there is anything else that needs to go in before 1.2, it should be done
> now if possible.  

I'd say the snprintf patch is the only thing I would want before the next beta.
Lots of unresolved bugs in the bugdb I at least want to look at before 1.2
final.

> The FIN_WAIT_2 stuff is a big problem.  I have a report from a SunOS user
> that NO_LINGCLOSE did _not_ help but using my hacked http_main.c did.
> Still trying various things to see what it was, should know more tomorrow,
> but it looks like there may be something in the wait_or_timeout changes.  

I have been left in the dust by the voluminous conversation on this matter -
since it appears to still be voodoo despite the hours spent on it, would it be
worth writing up a complete problem report, and sending it out over the
apache-announce mailing list?  I think so.  I would expect *someone* to know
what's going on.  Maybe even provide some compilation options so folks can test
different "fixes" and give feedback on them.  I guess I'm saying, if we're
running out of brainpower on this list to solve this, we've got an army of fans
to help us solve the problem.  We just need to make sure we don't waste their
time by asking the wrong questions.

> Any other issues that should be resolved should be brought up now if we
> want to avoid 43 patches the hour before the beta...
> 
> Possible ones:
> 	- ssi slowness

I would like someone to at least look at Rasmus's suggestion of mmapping the
file.

> 1.2 doesn't seem to be as settled as I would like yet, but... hopefully it
> will come together.

By hook or by crook!

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  www.apache.org  hyperreal.com  http://www.organic.com/JOBS