[PATCH: apr_hash.c]
apr_hash.c has a very obscure bug in it, though I'm very surprised nobody
has been bitten by it before. It is possible, when expanding the table,
to use an old pointer and overwrite the hash entry value upon return from
find_entry. Anyway, this small patch fixes it. I have a testhash.c for
the tests directory as well, if anyone thinks we need it.
-- Jon
Index: apr_hash.c
===
RCS file: /home/cvspublic/apr/tables/apr_hash.c,v
retrieving revision 1.16
diff -u -u -r1.16 apr_hash.c
--- apr_hash.c 2001/03/07 17:57:19 1.16
+++ apr_hash.c 2001/03/09 00:32:27
@@ -275,10 +275,7 @@
he-klen = klen;
he-val = val;
*hep = he;
-/* check that the collision rate isn't too high */
-if (++ht-count ht-max) {
- expand_array(ht);
-}
+ht-count++;
return hep;
}
@@ -310,6 +307,10 @@
else {
/* replace entry */
(*hep)-val = val;
+/* check that the collision rate isn't too high */
+if (ht-count ht-max) {
+expand_array(ht);
+}
}
}
/* else key not present and val==NULL */
Re: cvs commit: apr-util configure.in
No. We run xml/expat/configure, and it produces that Makefile. APRUTIL shouldn't be doing this. Please back out this change. -g On Fri, Mar 09, 2001 at 08:29:04AM -, [EMAIL PROTECTED] wrote: martin 01/03/09 00:29:03 Modified:.configure.in Log: Make Makefile in xml/expat Revision ChangesPath 1.13 +1 -0 apr-util/configure.in Index: configure.in === RCS file: /home/cvs/apr-util/configure.in,v retrieving revision 1.12 retrieving revision 1.13 diff -u -u -r1.12 -r1.13 --- configure.in2001/02/24 14:17:24 1.12 +++ configure.in2001/03/09 08:29:03 1.13 @@ -93,5 +93,6 @@ hooks/Makefile uri/Makefile xml/Makefile + xml/expat/Makefile $test_Makefile ]) -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util configure.in
This change gets things building for me on BeOS... david No. We run xml/expat/configure, and it produces that Makefile. APRUTIL shouldn't be doing this. Please back out this change. -g On Fri, Mar 09, 2001 at 08:29:04AM -, [EMAIL PROTECTED] wrote: martin 01/03/09 00:29:03 Modified:.configure.in Log: Make Makefile in xml/expat Revision ChangesPath 1.13 +1 -0 apr-util/configure.in Index: configure.in === RCS file: /home/cvs/apr-util/configure.in,v retrieving revision 1.12 retrieving revision 1.13 diff -u -u -r1.12 -r1.13 --- configure.in 2001/02/24 14:17:24 1.12 +++ configure.in 2001/03/09 08:29:03 1.13 @@ -93,5 +93,6 @@ hooks/Makefile uri/Makefile xml/Makefile + xml/expat/Makefile $test_Makefile ]) -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr CHANGES configure.in
Boolean switches should use AC_ARG_ENABLE(). AC_ARG_WITH is to allow you to specify configure with this package. The code below should fall out simply as: AC_ARG_ENABLE(sendfile, [ --enable-sendfile Enable or disable sendfile support] [ if test $enable_sendfile = yes; then sendfile=1 else sendfile=0 fi ]) No switch leaves sendfile unset (e.g. default to the platform availability). --enable-sendfile sets it to 1, and --disable-sendfile sets it to 0. Users expect AC_ARG_ENABLE type switches for these things. (--with-debug and --with-maintainer-mode need to switch, too, for that matter) Cheers, -g On Tue, Mar 06, 2001 at 12:10:42PM -0800, [EMAIL PROTECTED] wrote: On Tue, 6 Mar 2001, Roy T. Fielding wrote: On Tue, Mar 06, 2001 at 04:54:49AM -, [EMAIL PROTECTED] wrote: +++ configure.in2001/03/06 04:54:49 1.256 @@ -350,6 +350,13 @@ dnl threaded poll() and we don't want to use sendfile on early FreeBSD dnl systems if we are also using threads. +AC_ARG_WITH(sendfile, [ --with-sendfile Force sendfile to be on or off], + [ if test $withval = yes; then +sendfile=1 +else +sendfile=0 +fi ] ) + This seems to say that --with-sendfile means --without-sendfile. I think that --with options should always default to yes if no =value is given. Otherwise, the option should be --disable-sendfile. The way that autoconf works, by using AC_ARG_WITH, we get multiple options: --with-sendfile=yes --with-sendfile --with-sendfile=no --without-sendfile The first two are the same, as are the last two. The logic in that file makes --with-sendfile force sendfile to be on, and --without-sendfile to force it to be off. Ryan ___ Ryan Bloom[EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 --- -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util/xml Makefile.in
Ah. I missed this because during my testing, I was doing builds manually within xml/expat. I never did a complete from-scratch build. thx! -g On Thu, Mar 08, 2001 at 06:30:33PM -, [EMAIL PROTECTED] wrote: rbb 01/03/08 10:30:30 Modified:xml Makefile.in Log: Always build expat. This can probably be removed if we are told to look for expat some place else. For now, this gets Apache building again on Unix. Revision ChangesPath 1.5 +2 -0 apr-util/xml/Makefile.in Index: Makefile.in === RCS file: /home/cvs/apr-util/xml/Makefile.in,v retrieving revision 1.4 retrieving revision 1.5 diff -u -d -b -w -u -r1.4 -r1.5 --- Makefile.in 2001/02/24 14:17:25 1.4 +++ Makefile.in 2001/03/08 18:30:20 1.5 @@ -1,5 +1,7 @@ TARGETS = apr_xml.lo +SUBDIRS=expat + # bring in rules.mk for standard functionality @INCLUDE_RULES@ -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util configure.in
On Fri, Mar 09, 2001 at 05:06:25AM -0800, Greg Stein wrote: No. We run xml/expat/configure, and it produces that Makefile. APRUTIL shouldn't be doing this. Please back out this change. That is not really true. It definitely did not generate the Makefile, that's why I added the patch in the first place. I always do buildconf configure make clean make, and make clean bailed out because the apr-util/xml/expat/Makefile was not generated. Martin. -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-41143 | 81730 Munich, Germany
Re: httpd-2.0/apr/apr-util Code Freeze
I don't think it has anything to do with mechanics, nor will throwing more process at the problem fix it. (more process will simply bog down what we can accomplish) No... the problem is about perception. The rate of change recently has just been quite high. It just isn't very conceivable to make a release in that environment. The other side of the coin is what the result of the tag/roll is. We had some slight problems in the Windows .mak files. OtherBill went and patched those up, and created a new zip file. Do we know the quality? No, but we know it (at least) builds. So we ought to just toss it out there as alpha. Believing it to be more than alpha is also a bit alarming. We *just* fixed some serious problems in the C-L filter, and had some pretty big work in mod_include. Cheers, -g On Fri, Mar 09, 2001 at 02:28:51AM +1100, Luke Kenneth Casson Leighton wrote: create a release based on an ongoing frantic development tree, all you have to do is selectively tag the repository to include only those revisions that you consider to be stable. There is no rule that requires the entire HEAD to be tagged at once, and there is nothing wrong with moving tags from one revision to another within CVS *provided* that such moves are made before a tarball based on that tag is released. roy, sounds like you already appreciate the need for partial / selective tagging. the difference between what you propose and what i propose is that the _developers_ must use - on a daily basis - selective / partial tagging - _not_ the release manager. then and _only_ then can this rule be applied and be more confident to work: no developer shall commit code to cvs main if it don't work / ain't stable. of course, you can't fix all the bugs, and you can't forsee what might happen if two developers do two cvs merges simultaneously from two of their partial-cvs-tags, but we have that already on a smaller-scale on a per-file basis: you can't forsee what might happen if two developers fix the same problem in the same file in different ways! that's the trade-off you get with concurrent versioning. luke - Luke Kenneth Casson Leighton [EMAIL PROTECTED] - i want a world of dreams, run by near-sighted visionaries good. that's them sorted out. now, on _this_ world... -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util configure.in
I have found recently, that buildconf doesn't really do what you expect in a lot of cases. Namely, it doesn't tend to traverse into srclib/apr and srclib/apr-util, and run those buildconf's. Try running those manually right now. I was going to investigate further before posting the bug, but time isn't being kind to me. :-) Ryan On Fri, 9 Mar 2001, Martin Kraemer wrote: On Fri, Mar 09, 2001 at 05:06:25AM -0800, Greg Stein wrote: No. We run xml/expat/configure, and it produces that Makefile. APRUTIL shouldn't be doing this. Please back out this change. That is not really true. It definitely did not generate the Makefile, that's why I added the patch in the first place. I always do buildconf configure make clean make, and make clean bailed out because the apr-util/xml/expat/Makefile was not generated. Martin. -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-41143 | 81730 Munich, Germany ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr-util configure.in
On Fri, Mar 09, 2001 at 03:01:36PM +0100, Martin Kraemer wrote: On Fri, Mar 09, 2001 at 05:06:25AM -0800, Greg Stein wrote: No. We run xml/expat/configure, and it produces that Makefile. APRUTIL shouldn't be doing this. Please back out this change. That is not really true. It definitely did not generate the Makefile, that's why I added the patch in the first place. I always do buildconf configure make clean make, and make clean bailed out because the apr-util/xml/expat/Makefile was not generated. A snippet of my configuration log: updating cache ../../../.././config.cache creating ./config.status creating Makefile creating lib/Makefile creating lib/expat.h creating config.h xml/expat configured properly I see the Makefile getting created there :-) ... I figured out the problem. In the APRUTIL configuration, you'll see some lines like this: checking for Expat in /usr... no checking for Expat in /usr/local... no checking for Expat in xml/expat-cvs... no checking for Expat in xml/expat... yes What are you seeing on your platform? I'm guessing that Expat was installed and found in one of those other locations. Thus, aprutil's configure never ran xml/expat/configure, thus never making xml/expat/Makefile. Prolly the same for David. The right answer is to fix xml/Makefile.in to recurse only if APRUTIL decides to use its builtin expat. Fix approacheth... Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util configure.in
That is probably the stupid dependency stuff in build2.mk. httpd's buildconf should unconditionally recurse. But Martin's error is something else, I believe (see other note). I'm testing a fix now. Cheers, -g On Fri, Mar 09, 2001 at 06:25:40AM -0800, [EMAIL PROTECTED] wrote: I have found recently, that buildconf doesn't really do what you expect in a lot of cases. Namely, it doesn't tend to traverse into srclib/apr and srclib/apr-util, and run those buildconf's. Try running those manually right now. I was going to investigate further before posting the bug, but time isn't being kind to me. :-) Ryan On Fri, 9 Mar 2001, Martin Kraemer wrote: On Fri, Mar 09, 2001 at 05:06:25AM -0800, Greg Stein wrote: No. We run xml/expat/configure, and it produces that Makefile. APRUTIL shouldn't be doing this. Please back out this change. That is not really true. It definitely did not generate the Makefile, that's why I added the patch in the first place. I always do buildconf configure make clean make, and make clean bailed out because the apr-util/xml/expat/Makefile was not generated. Martin. -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-41143 | 81730 Munich, Germany ___ Ryan Bloom[EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 --- -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util configure.in
On Fri, 9 Mar 2001, Greg Stein wrote: That is probably the stupid dependency stuff in build2.mk. httpd's buildconf should unconditionally recurse. But Martin's error is something else, I believe (see other note). I'm testing a fix now. Okay, and that fix needs to go in (I mentioned it in my commit log in fact), but when I hit this bug, it was fixed by doing a buildconf in srclib/apr and srclib/apr-util. Ryan Cheers, -g On Fri, Mar 09, 2001 at 06:25:40AM -0800, [EMAIL PROTECTED] wrote: I have found recently, that buildconf doesn't really do what you expect in a lot of cases. Namely, it doesn't tend to traverse into srclib/apr and srclib/apr-util, and run those buildconf's. Try running those manually right now. I was going to investigate further before posting the bug, but time isn't being kind to me. :-) Ryan On Fri, 9 Mar 2001, Martin Kraemer wrote: On Fri, Mar 09, 2001 at 05:06:25AM -0800, Greg Stein wrote: No. We run xml/expat/configure, and it produces that Makefile. APRUTIL shouldn't be doing this. Please back out this change. That is not really true. It definitely did not generate the Makefile, that's why I added the patch in the first place. I always do buildconf configure make clean make, and make clean bailed out because the apr-util/xml/expat/Makefile was not generated. Martin. -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-41143 | 81730 Munich, Germany ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 --- -- Greg Stein, http://www.lyra.org/ ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: httpd-2.0/apr/apr-util Code Freeze
On Sat, 10 Mar 2001, Luke Kenneth Casson Leighton wrote: On Fri, 9 Mar 2001, Greg Stein wrote: I don't think it has anything to do with mechanics, nor will throwing more process at the problem fix it. (more process will simply bog down what we can accomplish) ...? if nothing else: cd apr cvs tag -b apr_dev [needs recursive option] cd .. mkdir apr_dev; cd !$ cvs co -r apr_dev apr cd .. mkdir httpd_combined; cd !$ cvs co httpd rm -fr apr mv ../apr_dev apr this assumes that the apr library is in httpd/apr, which it probably isn't, it's probably in httpd/src. the same process applies to if you want to use the version of apr that's already in httpd, except you do: rm -fr httpd/apr cvs co -r apr_dev httpd/apr No... the problem is about perception. The rate of change recently has just been quite high. It just isn't very conceivable to make a release in that environment. ... ah, that's different. _however_ :) once you _get_ to the point where cvs main is always-releasable, then using this multi-tag process could help make cvs main _remain_ always-releasable. for, as you described - some significant modifications to mod_include could be done in a dev_mod_include_rewrite tag, and only when completed are they cvs merged into cvs main. surely that's not too much process to cause more pain than the benefits are worth, neh? There is a lot of resistance to using tags and branches the way you suggest Luke. I believe it has already received a -1 on this list at some point, but I would have to look. There are a lot of people who would agree with you that branching is a good thing, we just need to figure out how to address the concerns that other people have. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: httpd-2.0/apr/apr-util Code Freeze
On Fri, Mar 09, 2001 at 06:54:29AM -0800, [EMAIL PROTECTED] wrote: On Sat, 10 Mar 2001, Luke Kenneth Casson Leighton wrote: On Fri, 9 Mar 2001, Greg Stein wrote: I don't think it has anything to do with mechanics, nor will throwing more process at the problem fix it. (more process will simply bog down what we can accomplish) ...? if nothing else: [ scheme described at Advogato ] ... No... the problem is about perception. The rate of change recently has just been quite high. It just isn't very conceivable to make a release in that environment. ... ah, that's different. _however_ :) Saw that coming :-) once you _get_ to the point where cvs main is always-releasable, then using this multi-tag process could help make cvs main _remain_ always-releasable. We only need it releasable when we want to release :-) Seriously, the general policy is do your best to keep it compiling and working, but we understand that sometimes things simply break. We have about a half dozen active committers, and things tend to work out fine (no stepping on toes). We haven't really need any long term branching, but I do know a couple cases where it would have been nice. for, as you described - some significant modifications to mod_include could be done in a dev_mod_include_rewrite tag, and only when completed are they cvs merged into cvs main. surely that's not too much process to cause more pain than the benefits are worth, neh? It actually has some pretty big pain because of the merge problem. CVS has horrible merging issues :-). Let's say that you had to grab some stuff from HEAD and pull it into dev_mod_include_rewrite. Say, because some of the code *around* you has changed, so you need the compensating changes from HEAD into your branch. Later on, you go to merge a reasonable stable form of the branch back into HEAD, but all those bits you pulled over get reapplied back to HEAD, generating a bunch of conflicts. You bitch, fix them, then check in the new HEAD. You continue some more work on the branch. You're finally done, so you go to merge it back onto HEAD. Now you're really screwed. Pretty much the entire set of changes causes conflicts because CVS doesn't record that you already merged a good portion of the branch onto the HEAD. It is a pain in the ass. There is a lot of resistance to using tags and branches the way you suggest Luke. I believe it has already received a -1 on this list at some point, but I would have to look. There are a lot of people who would agree with you that branching is a good thing, we just need to figure out how to address the concerns that other people have. I don't know if a -1 occurred, but I'd certainly consider a negative vote quite strongly (veto? dunno). The merge problem is just a pain in the ass. Personally, I'd just state that we don't worry about the problem. Subversion has *very* easy branching. And it records information about merges, so you won't see the problems above. I'm presuming we'll want to switch to SVN for any number of excellent reasons, and that would bring along a much better branch/merge capability. Cheers, -g -- Greg Stein, http://www.lyra.org/
Problem with apr-util/xml/expat
Hi, I have some problems with the Makefile on apr-util/xml/expat. The option -Wp,-MD,.deps/$(*F).pp is no understand neither on Solaris nor on ReliantUnix. On Solaris the fix is to use: +++ $(LTCOMPILE) -xM $ .deps/$(*F).pp; \ $(LTCOMPILE) -c $ +++ Instead of $(LTCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $ On ReliantUnix the -xM option is -M, so I have: +++ $(LTCOMPILE) -M $ .deps/$(*F).pp; \ $(LTCOMPILE) -c $ +++ I am afraid we need a way to find how -Wp,-MD, option should be processed. Cheers Jean-frederic
Re: Problem with apr-util/xml/expat
Tru64 is busted with this too, though when I do make from toplevel, link of dftables failes because libexpat.la does not exist. A make from xml just says Making all in expat A make from xml/expat does nothing. Oh, I have to touch config.status for some reason. When I do make from srclib/apr-util/xml/expat/lib I get /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.2 -I/home/trawick/apache/httpd-2.0/srclib/apr-util/xml/expat/lib -I.. -DOSF1 -DAPACHE_XLATE -g -c xmlparse.c cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.2\ -I/home/trawick/apache/httpd-2.0/srclib/apr-util/xml/expat/lib -I.. -DOSF1 -DAPACHE_XLATE -g -Wp,-MD,.deps/xmlparse.pp -c xmlparse.c -o xmlparse.o cc: Severe: No such file or directory ... file is '.deps/xmlparse.pp' *** Exit 1 Stop. jean-frederic clere [EMAIL PROTECTED] writes: Hi, I have some problems with the Makefile on apr-util/xml/expat. The option -Wp,-MD,.deps/$(*F).pp is no understand neither on Solaris nor on ReliantUnix. On Solaris the fix is to use: +++ $(LTCOMPILE) -xM $ .deps/$(*F).pp; \ $(LTCOMPILE) -c $ +++ Instead of $(LTCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $ On ReliantUnix the -xM option is -M, so I have: +++ $(LTCOMPILE) -M $ .deps/$(*F).pp; \ $(LTCOMPILE) -c $ +++ I am afraid we need a way to find how -Wp,-MD, option should be processed. Cheers Jean-frederic -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Problem with apr-util/xml/expat
Fixed. Cheers, -g On Fri, Mar 09, 2001 at 11:22:04AM -0500, Jeff Trawick wrote: Tru64 is busted with this too, though when I do make from toplevel, link of dftables failes because libexpat.la does not exist. A make from xml just says Making all in expat A make from xml/expat does nothing. Oh, I have to touch config.status for some reason. When I do make from srclib/apr-util/xml/expat/lib I get /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -DPACKAGE=expat -DVERSION=expat_1.95.2 -I/home/trawick/apache/httpd-2.0/srclib/apr-util/xml/expat/lib -I.. -DOSF1 -DAPACHE_XLATE -g -c xmlparse.c cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -DVERSION=\expat_1.95.2\ -I/home/trawick/apache/httpd-2.0/srclib/apr-util/xml/expat/lib -I.. -DOSF1 -DAPACHE_XLATE -g -Wp,-MD,.deps/xmlparse.pp -c xmlparse.c -o xmlparse.o cc: Severe: No such file or directory ... file is '.deps/xmlparse.pp' *** Exit 1 Stop. jean-frederic clere [EMAIL PROTECTED] writes: Hi, I have some problems with the Makefile on apr-util/xml/expat. The option -Wp,-MD,.deps/$(*F).pp is no understand neither on Solaris nor on ReliantUnix. On Solaris the fix is to use: +++ $(LTCOMPILE) -xM $ .deps/$(*F).pp; \ $(LTCOMPILE) -c $ +++ Instead of $(LTCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $ On ReliantUnix the -xM option is -M, so I have: +++ $(LTCOMPILE) -M $ .deps/$(*F).pp; \ $(LTCOMPILE) -c $ +++ I am afraid we need a way to find how -Wp,-MD, option should be processed. Cheers Jean-frederic -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien... -- Greg Stein, http://www.lyra.org/
