Re: APR Util Question

[Jeff Trawick]

On Fri, Jan 31, 2014 at 3:32 PM, Lamb, Joel  wrote:

>  Dev Team
>
>
>
> I couldn't find a list for support or questions, so I hope this is the
> correct list to sent to.
>
>
>
> I'm trying to build apr-util-1.5.3.tar.bz2 which I downloaded from your
> site.  I'm getting an error with testing and I can't seem to figure out
> what to do next.  Any help you can provide will be greatly appreciated.
>
>
>
> OS: Red Hat Enterprise Linux Server release 6.2 (Santiago)
>
>
>
> I was able to build apr-1.5.0.tar.bz2 with no issues.
>
>
>
> Command I'm running: rpmbuild -tb apr-util-1.5.3.tar.bz2
>
>
>
> Error I'm getting:
>
> Loaded freetds driver OK.
>
> Failed to open freetds[]
>
> Loaded odbc driver OK.
>
> [Fri Jan 31 15:22:57 2014] [dbd_odbc] SQLConnect returned SQL_ERROR (-1)
> at dbd/apr_dbd_odbc.c:1131 [unixODBC][Driver Manager]Data source name not
> found, and no default driver specified IM002
>
> Failed to open odbc[]
>
> teststrmatch: SUCCESS
>
> testuri : SUCCESS
>
> testuuid: -./testall: symbol lookup error:
> /root/rpmbuild/BUILD/apr-util-1.5.3/.libs/libaprutil-1.so.0: undefined
> symbol: apr_os_uuid_get
>
> Programs failed: testall
>
> make: *** [check] Error 127
>
> + exit 1
>
> error: Bad exit status from /var/tmp/rpm-tmp.aVaF6n (%check)
>

I guess the apr-util test suite is not running against the expected apr,
resulting in this failure.

Has apr-1.5.0 been installed?

Does testall still exist after the failure (/root/rpmbuild/BUILD/...)?  Can
you use ldd on testall to see which libapr-1.so gets picked up?



>
> Thank You
>
>
>
> *Joel A. Lamb *
>
> Senior Translations Engineer
> Frontier Communications
> 8001 West Jefferson Blvd
> Fort Wayne, Indiana 46804
> (260) 461-2168 (o)
> (260) 403-3095 (c)
> (260) 461-2124 (f)
>
> joel.l...@ftr.com
>
>
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1561041 - in /apr/apr/branches/1.5.x: ./ include/apr_errno.h

[Jeff Trawick]

On Fri, Jan 24, 2014 at 10:46 AM,  wrote:

> Author: jim
> Date: Fri Jan 24 15:46:47 2014
> New Revision: 1561041
>
> URL: http://svn.apache.org/r1561041
> Log:
> Merge r1561040 from trunk:
>
> Using UDS, we sometime try ops not supported on UDS. Make this
> a known (and therfore handable) issue
>
> Reviewed/backported by: jim
>
> Modified:
> apr/apr/branches/1.5.x/   (props changed)
> apr/apr/branches/1.5.x/include/apr_errno.h
>
> Propchange: apr/apr/branches/1.5.x/
>
> --
>   Merged /apr/apr/trunk:r1561040
>
> Modified: apr/apr/branches/1.5.x/include/apr_errno.h
> URL:
> http://svn.apache.org/viewvc/apr/apr/branches/1.5.x/include/apr_errno.h?rev=1561041&r1=1561040&r2=1561041&view=diff
>
> ==
> --- apr/apr/branches/1.5.x/include/apr_errno.h (original)
> +++ apr/apr/branches/1.5.x/include/apr_errno.h Fri Jan 24 15:46:47 2014
> @@ -833,6 +833,13 @@ APR_DECLARE(char *) apr_strerror(apr_sta
>  #define APR_EAFNOSUPPORT  (APR_OS_START_CANONERR + 27)
>  #endif
>
> +/** @see APR_STATUS_IS_EOPNOTSUPP */
> +#ifdef EOPNOTSUPP
> +#define APR_EOPNOTSUPP EOPNOTSUPP
> +#else
> +#define APR_EOPNOTSUPP(APR_OS_START_CANONERR + 28)
> +#endif
>

Doesn't this new API break APR versioning rules?  An app shouldn't have to
check for a specific patch level (as in your httpd change).

Aside from versioning, should APR reuse existing rc APR_ENOTIMPL when it
sees EOPNOTSUPP and/or APR_STATUS_IS_ENOTIMPL() checks for EOPNOTSUPP?

Nothing seems quite right...


> +
>  /** @} */
>
>  #if defined(OS2) && !defined(DOXYGEN)
> @@ -977,6 +984,8 @@ APR_DECLARE(char *) apr_strerror(apr_sta
>  || (s) == APR_OS_START_SYSERR + ERROR_ACCESS_DENIED)
>  #define APR_STATUS_IS_EAFNOSUPPORT(s)   ((s) == APR_AFNOSUPPORT \
>  || (s) == APR_OS_START_SYSERR + SOCEAFNOSUPPORT)
> +#define APR_STATUS_IS_EOPNOTSUPP(s) ((s) == APR_EOPNOTSUPP \
> +|| (s) == APR_OS_START_SYSERR + SOCEOPNOTSUPP)
>
>  /*
>  Sorry, too tired to wrap this up for OS2... feel free to
> @@ -990,7 +999,6 @@ APR_DECLARE(char *) apr_strerror(apr_sta
>  { SOCENOPROTOOPT,   ENOPROTOOPT },
>  { SOCEPROTONOSUPPORT,   EPROTONOSUPPORT },
>  { SOCESOCKTNOSUPPORT,   ESOCKTNOSUPPORT },
> -{ SOCEOPNOTSUPP,EOPNOTSUPP  },
>  { SOCEPFNOSUPPORT,  EPFNOSUPPORT},
>  { SOCEADDRINUSE,EADDRINUSE  },
>  { SOCEADDRNOTAVAIL, EADDRNOTAVAIL   },
> @@ -1122,6 +1130,8 @@ APR_DECLARE(char *) apr_strerror(apr_sta
>  || (s) == APR_OS_START_SYSERR + ERROR_DIR_NOT_EMPTY)
>  #define APR_STATUS_IS_EAFNOSUPPORT(s)   ((s) == APR_EAFNOSUPPORT \
>  || (s) == APR_OS_START_SYSERR + WSAEAFNOSUPPORT)
> +#define APR_STATUS_IS_EOPNOTSUPP(s) ((s) == APR_EOPNOTSUPP \
> +|| (s) == APR_OS_START_SYSERR + WSAEOPNOTSUPP)
>
>  #elif defined(NETWARE) && defined(USE_WINSOCK) && !defined(DOXYGEN) /*
> !defined(OS2) && !defined(WIN32) */
>
> @@ -1183,6 +1193,8 @@ APR_DECLARE(char *) apr_strerror(apr_sta
>  #define APR_STATUS_IS_ENOTEMPTY(s)  ((s) == APR_ENOTEMPTY)
>  #define APR_STATUS_IS_EAFNOSUPPORT(s)   ((s) == APR_EAFNOSUPPORT \
>  || (s) == APR_OS_START_SYSERR + WSAEAFNOSUPPORT)
> +#define APR_STATUS_IS_EOPNOTSUPP(s) ((s) == APR_EOPNOTSUPP \
> +|| (s) == APR_OS_START_SYSERR + WSAEOPNOTSUPP)
>
>  #else /* !defined(NETWARE) && !defined(OS2) && !defined(WIN32) */
>
> @@ -1302,6 +1314,8 @@ APR_DECLARE(char *) apr_strerror(apr_sta
>(s) == APR_EEXIST)
>  /** Address Family not supported */
>  #define APR_STATUS_IS_EAFNOSUPPORT(s)((s) == APR_EAFNOSUPPORT)
> +/** Socket operation not supported */
> +#define APR_STATUS_IS_EOPNOTSUPP(s)  ((s) == APR_EOPNOTSUPP)
>  /** @} */
>
>  #endif /* !defined(NETWARE) && !defined(OS2) && !defined(WIN32) */
>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [Patch] Fix for concurrent/race condition in apr_dir_make_recursive()

[Jeff Trawick]

On Mon, Jan 20, 2014 at 8:23 PM, Branko Čibej  wrote:

> On 21.01.2014 02:18, Branko Čibej wrote:
> > On 21.01.2014 01:55, Branko Čibej wrote:
> >> I've added a test case to testdir.c to exercise this code in parallel.
> > r1559873, original patch (with slightly tweaked comments) and test case.
> > Bert, can you please double-check that this works on Windows?
>
> Also r1559878 (1.5.x) and r1559879 (1.4.x).
>
> -- Brane
>
>
I see intermittent failures testing the 1.5.x branch on Linux (4 cores, 8
threads) after picking up your new testcase.  The two variations seen the
most are

testdir : |Line 84: expected <0>, but saw <2>
testdir : \Line 87: expected <0>, but saw <2>

I've also seen a single failure at line 85 as well as this one that needs
to be recovered from manually:
testdir : -Line 199: expected <0>, but saw <39> (39 is
"Directory not empty")

Current state as of the unrecoverable failure:
$ find data/prll/
data/prll/
data/prll/11
data/prll/11/12
data/prll/11/12/13
data/prll/11/12/13/14
data/prll/11/12/13/14/15data
data/prll/11/12/13/14/15data/prll
data/prll/11/12/13/14/15data/prll/11
data/prll/11/12/13/14/15data/prll/11/12

I didn't see a failure on Windows (2 virtualized processors).

---

Also, can you add a CHANGES entry in the 1.4.x and 1.5.x branches?


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1559721 - in /apr/apr-util/branches/1.5.x: CMakeLists.txt README.cmake

[Jeff Trawick]

On Mon, Jan 20, 2014 at 9:57 AM,  wrote:

> Author: trawick
> Date: Mon Jan 20 14:57:53 2014
> New Revision: 1559721
>
> URL: http://svn.apache.org/r1559721
> Log:
> Fix FILEOS tag in DLLs for cmake-based build.  (libaprutil.rc
> needs WINNT defined.)
>

AFAICT the traditional Windows build of apr-util doesn't have a way to
define WINNT.  (IMO it isn't worth messing with but YMMV.)


> (not worth mentioning in CHANGES)
>
> Modified:
> apr/apr-util/branches/1.5.x/CMakeLists.txt
> apr/apr-util/branches/1.5.x/README.cmake
>
> Modified: apr/apr-util/branches/1.5.x/CMakeLists.txt
> URL:
> http://svn.apache.org/viewvc/apr/apr-util/branches/1.5.x/CMakeLists.txt?rev=1559721&r1=1559720&r2=1559721&view=diff
>
> ==
> --- apr/apr-util/branches/1.5.x/CMakeLists.txt (original)
> +++ apr/apr-util/branches/1.5.x/CMakeLists.txt Mon Jan 20 14:57:53 2014
> @@ -221,6 +221,8 @@ SET(install_bin_pdb)
>  SET(install_lib_pdb)
>  SET(dbd_drivers)
>
> +# Note: The WINNT definition on some targets is used only by
> libaprutil.rc.
> +
>  # static expat (not installed)
>  ADD_LIBRARY(libexpat STATIC ${EXPAT_SOURCES})
>  SET_TARGET_PROPERTIES(libexpat PROPERTIES COMPILE_DEFINITIONS
> "XML_STATIC;COMPILED_FROM_DSP")
> @@ -230,7 +232,7 @@ ADD_LIBRARY(libaprutil-1 SHARED ${APR_SO
>  SET(install_targets ${install_targets} libaprutil-1)
>  SET(install_bin_pdb ${install_bin_pdb}
> ${PROJECT_BINARY_DIR}/libaprutil-1.pdb)
>  TARGET_LINK_LIBRARIES(libaprutil-1 ${APR_LIBRARIES} ${XMLLIB_LIBRARIES})
> -SET_TARGET_PROPERTIES(libaprutil-1 PROPERTIES COMPILE_DEFINITIONS
> "APU_DECLARE_EXPORT;XML_STATIC")
> +SET_TARGET_PROPERTIES(libaprutil-1 PROPERTIES COMPILE_DEFINITIONS
> "APU_DECLARE_EXPORT;XML_STATIC;WINNT")
>
>  ADD_LIBRARY(aprutil-1 STATIC ${APR_SOURCES}
> ${APR_PUBLIC_HEADERS_GENERATED})
>  SET(install_targets ${install_targets} aprutil-1)
> @@ -246,6 +248,7 @@ IF(APU_HAVE_CRYPTO)
>SET(install_targets ${install_targets} apr_crypto_openssl-1)
>SET(install_bin_pdb ${install_bin_pdb}
> ${PROJECT_BINARY_DIR}/apr_crypto_openssl-1.pdb)
>SET_TARGET_PROPERTIES(apr_crypto_openssl-1 PROPERTIES
> INCLUDE_DIRECTORIES "${APR_INCLUDE_DIRECTORIES};${OPENSSL_INCLUDE_DIR}")
> +  SET_TARGET_PROPERTIES(apr_crypto_openssl-1 PROPERTIES
> COMPILE_DEFINITIONS "WINNT")
>SET_TARGET_PROPERTIES(apr_crypto_openssl-1 PROPERTIES COMPILE_FLAGS
> "-DDLL_NAME=apr_crypto_openssl")
>TARGET_LINK_LIBRARIES(apr_crypto_openssl-1 libaprutil-1
> ${APR_LIBRARIES} ${OPENSSL_LIBRARIES})
>  ENDIF()
> @@ -257,7 +260,7 @@ IF(APU_HAVE_ODBC)
>SET(dbd_drivers ${dbd_drivers} odbc)
>TARGET_LINK_LIBRARIES(apr_dbd_odbc-1 libaprutil-1 ${APR_LIBRARIES}
> odbc32 odbccp32)
>SET_PROPERTY(TARGET apr_dbd_odbc-1 APPEND PROPERTY LINK_FLAGS
> /export:apr_dbd_odbc_driver)
> -  SET_TARGET_PROPERTIES(apr_dbd_odbc-1 PROPERTIES COMPILE_DEFINITIONS
> "APU_HAVE_ODBC;HAVE_SQL_H;APU_DECLARE_EXPORT;APU_DSO_MODULE_BUILD")
> +  SET_TARGET_PROPERTIES(apr_dbd_odbc-1 PROPERTIES COMPILE_DEFINITIONS
> "APU_HAVE_ODBC;HAVE_SQL_H;APU_DECLARE_EXPORT;APU_DSO_MODULE_BUILD;WINNT")
>SET_TARGET_PROPERTIES(apr_dbd_odbc-1 PROPERTIES COMPILE_FLAGS
> "-DDLL_NAME=apr_dbd_odbc")
>  ENDIF()
>
> @@ -267,6 +270,7 @@ IF(APR_HAS_LDAP)
>SET(install_targets ${install_targets} apr_ldap-1)
>SET(install_bin_pdb ${install_bin_pdb}
> ${PROJECT_BINARY_DIR}/apr_ldap-1.pdb)
>TARGET_LINK_LIBRARIES(apr_ldap-1 libaprutil-1 ${APR_LIBRARIES}
> ${LDAP_LIBRARIES})
> +  SET_TARGET_PROPERTIES(apr_ldap-1 PROPERTIES COMPILE_DEFINITIONS "WINNT")
>SET_TARGET_PROPERTIES(apr_ldap-1 PROPERTIES COMPILE_FLAGS
> "-DDLL_NAME=apr_ldap")
>SET(apr_ldap_libraries apr_ldap-1)
>  ELSE()
>
> Modified: apr/apr-util/branches/1.5.x/README.cmake
> URL:
> http://svn.apache.org/viewvc/apr/apr-util/branches/1.5.x/README.cmake?rev=1559721&r1=1559720&r2=1559721&view=diff
>
> ==
> --- apr/apr-util/branches/1.5.x/README.cmake (original)
> +++ apr/apr-util/branches/1.5.x/README.cmake Mon Jan 20 14:57:53 2014
> @@ -4,6 +4,8 @@ Status
>  --
>
>  This build support is currently intended only for Microsoft Windows.
> +Only Windows NT-based systems can be targeted.  (The traditional
> +Windows build support for APR can target Windows 9x as well.)
>
>  This build support is experimental.  Specifically,
>
>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Was your APR patch ignored?

[Jeff Trawick]

On Sat, Jan 18, 2014 at 8:36 AM, Jeff Trawick  wrote:

> If it was posted only to the mailing list, make sure there is a bug opened
> for it at https://issues.apache.org/bugzilla/
>
>
To clarify something that somebody just e-mailed me directly about:

There's nothing inherently wrong with posting a patch to the mailing list,
and if it is ignored there it isn't because it didn't follow some sort of
secret rule book.  The hint about the bug database is simply because it
will be out of sight/out of mind if no one takes an interest within a week
or so, whereas it can't disappear from the bug list.

--/--

Hey devs, what other hints might we collect together?  We have this doc:
http://apr.apache.org/patches.html  The part that is hard to describe is
what to do when nobody takes interest.  Sending a reminder to the dev@ list
every couple of weeks?  Sure.  But often there is a lack of motivation
among independent devs to make a judgement on issues of scope or
appropriateness (contrasted with "good" or "bad" code changes); somebody
eventually has to say something and hope that it will elicit a clear
positive or negative response from other devs.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: apr 1.5.x in a couple of weeks?

[Jeff Trawick]

On Sat, Jan 18, 2014 at 5:07 AM, Branko Čibej  wrote:

> On 17.01.2014 16:59, Jeff Trawick wrote:
> > We already have a couple of fixes for build regressions and a critical
> > functional fix for the new FreeBSD release.  (See below.)
> >
> > Others I'm interested in pushing along personally are the missing
> > -DWINNT define in the CMake-based build and the
> > apr_dir_make_recursive() patch posted yesterday (and more generally,
> > testing that API better on Unix and Windows).
> >
> > What fixes are *you* interested in pushing along?
>
> I'm going to take a closer look at Bert's patch for
> apr_dir_make_recursive. What that actually means is that I'm going to
> replicate the fix to the other implementations and get the whole lot
> committed to trunk and ported to 1.5.x, because I already know his patch
> works on Windows.
>

Cool!


>
> It would IMO be a valid fix for 1.4.x as well, if we want to ever deal
> with creating another 1.4 release.
>

Though there will probably never be another 1.4.x release, just backport
the fix if it is at all interesting to you instead of pondering the
imponderable.


>
> -- Brane
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Was your APR patch ignored?

[Jeff Trawick]

If it was posted only to the mailing list, make sure there is a bug opened
for it at https://issues.apache.org/bugzilla/

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

apr 1.5.x in a couple of weeks?

[Jeff Trawick]

We already have a couple of fixes for build regressions and a critical
functional fix for the new FreeBSD release.  (See below.)

Others I'm interested in pushing along personally are the missing -DWINNT
define in the CMake-based build and the apr_dir_make_recursive() patch
posted yesterday (and more generally, testing that API better on Unix and
Windows).

What fixes are *you* interested in pushing along?

--- current changes ---

  *) Fix apr_escape.c compilation errors on ebcdic platforms.
 [Eric Covener]

  *) FreeBSD 10: Correct a regression in 1.5.0 which affected non-
 blocking sockets in some applications, including httpd.  [Jeff
 Trawick]

  *) Windows cmake build: Fix incorrect installation of some .pdb
 files.  [Jeff Trawick]

  *) apr_skiplist: Add compatibility with C++ applications.
 [Jeff Trawick]

  *) When using shmget-based shared memory, the ID used for ftok is
 now an APR hash of the filename instead of the constant '1'.
 PR 53996 [Jim Jagielski]

  *) Correct a regression in 1.5.0 which affected out-of-tree
 builds on Unix.  [Rainer Jung]

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: CMake build doesn't define 'WINNT', but apr headers check for it anyway

[Jeff Trawick]

On Thu, Dec 5, 2013 at 9:13 AM, Bert Huijben  wrote:

> Hi,
>
>
>
> On Windows apr_arch_misc.h checks for the ‘WINNT’ define, which was
> unconditionally defined on Windows before the CMake build. But now it is no
> longer defined. This enables some additional dynamic load operations that
> could fail in some cases (See “Race condition in
> APR_DECLARE_LATE_DLL_FUNC() implementation”).
>

There's also a potential for other breakage, e.g., by not using Unicode FS
operations.

Even libaprutil.rc looks for WINNT.  I'm not sure that it can find it,
though; I guess that was copied from libapr.rc without creating a way to
define it.


>
> We could fix this by defining WINNT, but we might as well just remove the
> check as we don’t support systems older than NT 4.0 anyway..
>
>
>
> Bert
>

I thought we didn't either, but the support was never removed from the
traditional Windows build system or from the code.


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Event and atomics, round II

[Jeff Trawick]

On Tue, Jan 7, 2014 at 12:38 PM, Yann Ylavic  wrote:

> Hi,
>
> I cc to APR's dev list so to propose a patch regarding 
> apr_atomic_dec32()platform dependent return
> values.
>
> On Mon, Jan 6, 2014 at 5:27 PM, Yann Ylavic  wrote:
>
>>
>> On Mon, Dec 16, 2013 at 4:25 PM, Jim Jagielski  wrote:
>>
>>> Now that 2.4.7 has been out for awhile, I would have assumed
>>> that if people were hitting the "atomics not working as
>>> expected" error (using unsigned as signed), we would have
>>> started hearing about it... But, afaik, we haven't.
>>>
>>
>> Since this is reproductable on any platform using "atomic/unix/ia32.c" or
>> "atomic/os390/atomic.c" (no gcc/solaris atomic builtins available), I think
>> it should be fixed somehow.
>>
>>
>>> So this leads me to the following discussion: should we stay
>>> with the "workaround" started in
>>>
>>> http://svn.apache.org/viewvc?view=revision&revision=1545286
>>>
>>> where we use an zero-point offset, or go back to the old method,
>>> or do something else?
>>>
>>
>> apr_atomic_dec32() is documented (and acts) as returning 0 (when reached)
>> or non-0 (otherwise), and in the case where the implementation returns the
>> new (decremented) value as non-0, that's with a conversion for unsigned32
>> to signed32 (which is undefined AFAIK)
>> .
>>
>>
>> IMHO, apr_atomic_dec32() should be fixed to return a boolean value on all
>> platforms (as documented, no undefined conversion), and httpd use
>> apr_atomic_add32(&foo, -1) instead when it wants the previous value (or
>> previous - 1 for the new one).
>>
>
> The patch below is for apr_atomic_dec32() to always return a boolean value
> (as documented, 0 => hit zero, !0 => otherwise), on any platform.
>
> It avoids unsigned to signed conversion, but the caller can't expect
> anymore the returned value to be the new atomic value (that was platform
> dependent behaviour anyway).
>

+1 for APR trunk, +0.9 for future APR 1.6.x, -0.9 for APR 1.5.x...

alternate opinions?



>
> The caller should instead use apr_atomic_add32(&foo, -1) to decrement and
> get the previous value atomically (or all that minus 1 for the new value).
>
> Since the API is not really symetric now and requires the caller to do
> things like that, maybe a new API would be welcome, with symetric
> apr_atomic32_read/set/inc/dec/sub/add/cas() functions working on signed
> integers, and with the equivalent 64bits (where available) and pointer
> versions...
>
> Regards,
> Yann.
>
>
> Index: atomic/win32/apr_atomic.c
> ===
> --- atomic/win32/apr_atomic.c(revision 1556264)
> +++ atomic/win32/apr_atomic.c(working copy)
> @@ -75,7 +75,7 @@ APR_DECLARE(apr_uint32_t) apr_atomic_inc32(volatil
>  #if (defined(_M_IA64) || defined(_M_AMD64)) && !defined(RC_INVOKED)
>  return InterlockedIncrement(mem) - 1;
>  #elif defined(__MINGW32__)
> -return InterlockedIncrement((long *)mem) - 1;
> +return InterlockedIncrement((long *)mem) - 1L;
>  #else
>  return ((apr_atomic_win32_ptr_fn)InterlockedIncrement)(mem) - 1;
>  #endif
> @@ -84,11 +84,11 @@ APR_DECLARE(apr_uint32_t) apr_atomic_inc32(volatil
>  APR_DECLARE(int) apr_atomic_dec32(volatile apr_uint32_t *mem)
>  {
>  #if (defined(_M_IA64) || defined(_M_AMD64)) && !defined(RC_INVOKED)
> -return InterlockedDecrement(mem);
> +return InterlockedDecrement(mem) != 0;
>  #elif defined(__MINGW32__)
> -return InterlockedDecrement((long *)mem);
> +return InterlockedDecrement((long *)mem) != 0L;
>  #else
> -return ((apr_atomic_win32_ptr_fn)InterlockedDecrement)(mem);
> +return ((apr_atomic_win32_ptr_fn)InterlockedDecrement)(mem) != 0;
>  #endif
>  }
>
> Index: atomic/unix/ia32.c
> ===
> --- atomic/unix/ia32.c(revision 1556264)
> +++ atomic/unix/ia32.c(working copy)
> @@ -57,14 +57,14 @@ APR_DECLARE(apr_uint32_t) apr_atomic_inc32(volatil
>
>  APR_DECLARE(int) apr_atomic_dec32(volatile apr_uint32_t *mem)
>  {
> -unsigned char prev;
> +unsigned char flag;
>
>  asm volatile ("lock; decl %0; setnz %1"
> -  : "=m" (*mem), "=qm" (prev)
> +  : "=m" (*mem), "=qm" (flag)
>: "m" (*mem)
>: "memory");
>
> -return prev;
> +return flag != 0;
>  }
>
>  APR_DECLARE(apr_uint32_t) apr_atomic_cas32(volatile apr_uint32_t *mem,
> apr_uint32_t with,
> Index: atomic/unix/s390.c
> ===
> --- atomic/unix/s390.c(revision 1556264)
> +++ atomic/unix/s390.c(working copy)
> @@ -82,7 +82,7 @@ APR_DECLARE(void) apr_atomic_sub32(volatile apr_ui
>
>  APR_DECLARE(int) apr_atomic_dec32(volatile apr_uint32_t *mem)
>  {
> -return atomic_sub(mem, 1);
> +return atomic_sub(mem, 1) != 0;
>  }
>
>  APR_DECLARE(apr_uint32_t) apr_atomic_cas32(volatile apr_uint32_t *mem,
> apr_uint32_t with,
> Index: atomic/unix/mutex.c
> =

Re: Issue with apr-1.5.0 on FreeBSD 10beta3

[Jeff Trawick]

On Fri, Nov 22, 2013 at 4:21 AM, olli hauer  wrote:

> On 2013-11-22 00:08, Jeff Trawick wrote:
> > On Thu, Nov 21, 2013 at 5:48 PM, olli hauer  wrote:
> >
> >> Hi,
> >>
> >> sorry for late response to apr-1.5.0 ...
> >>
> >> I've done some tests with apr-1.5.0 on FreeBSD 10 (amd64)
> >> and it seems there is an issue that breaks apache24.
> >>
> >> With apr-1.5.0 apache22 works but apache24 is broken.
> >> apache starts fine, nothing special in the logs or during
> >> start with -X but no response is coming back.
> >>
> >> apr/apr-util test:
> >> 
> >> apr-1.5.0:  all tests passed [1]
> >> apr-util-1.5.3: all tests passed
> >>
> >>
> >> working configurations (FreeBSD beta3 [1]
> >> =
> >> apache22-2.2.26 apr-1.4.8 apr-util-1.5.3
> >> apache22-2.2.26 apr-1.5.0 apr-util-1.5.3
> >> apache24-2.4.6  apr-1.4.8 apr-util-1.5.2
> >> apache24-2.4.7  apr-1.4.8 apr-util-1.5.2
> >> apache24-2.4.6  apr-1.4.8 apr-util-1.5.3
> >> apache24-2.4.7  apr-1.4.8 apr-util-1.5.3
> >>
> >> broken combinations:
> >> =
> >> apache24-2.4.6  apr-1.5.0 apr-util-1.5.3
> >> apache24-2.4.7  apr-1.5.0 apr-util-1.5.3
> >>
> >> All tests where done with MPM worker.
> >>
> >>
> >> FreeBSD 8.4 (amd64) seems OK in all combinations
> >> FreeBSD 9.2 (amd64) seems OK in all combinations
> >>
> >> [1] FreeBSD 10 beta3 with iconv UTF7 patch r258316
> >> (head/lib/libiconv_modules/UTF7/citrus_utf7.c)
> >>
> >> Any hints where to start?
> >>
> >
> > Set LogLevel trace8 and compare good vs. bad.
> > Start with -X then attach with dtruss and compare good vs. bad.
> > Get open fds displayed by lsof and compare good vs. bad.
> > Is connection to client held open?  Get backtraces.
> >
> > I just compared 1.4.8 vs. 1.5.0 and didn't see anything that looked
> > remotely likely.
> >
>
> Small update,
>
> The issue is only present if apache24 is build with '--disable-v4-mapped'
> which should be the default for FreeBSD >= 5.x.
>
> Long time ago I've opened a PR since the httpd configure script contains
> an error https://issues.apache.org/bugzilla/show_bug.cgi?id=53824


As it turns out, the problem wasn't specific to --disable-v4-mapped.

This is fixed in httpd trunk r1551685.


>
>
> - apache24 build with '--disable-v4-mapped'
>  - Listen 80 -> broken
>  - Listen IPv4.addr:80 -> OK
>
> - apache24 build with '--enable-v4-mapped'
>  - Listen 80 -> OK
>  - Listen IPv4.addr:80 -> OK
>
>
> I think the issue comes from a wrong assumption in sockaddr.c.
>
> --- apr-1.4.8/network_io/unix/sockaddr.c2013-05-03
> 20:39:44.0 +0200
> +++ apr-1.5.0/network_io/unix/sockaddr.c2013-11-12
> 15:26:22.0 +0100
> @@ -839,6 +839,35 @@
>  return 0; /* not equal */
>  }
>
> +APR_DECLARE(int) apr_sockaddr_is_wildcard(const apr_sockaddr_t *addr)
> +{
> +static const char inaddr_any[
> +#if APR_HAVE_IPV6
> +sizeof(struct in6_addr)
> +#else
> +sizeof(struct in_addr)
> +#endif
> +] = {0};
> +
> +if (addr->ipaddr_ptr /* IP address initialized */
> +&& addr->ipaddr_len <= sizeof inaddr_any) { /* else bug
> elsewhere? */
> +if (!memcmp(inaddr_any, addr->ipaddr_ptr, addr->ipaddr_len)) {
> +return 1;
> +}
> +#if APR_HAVE_IPV6
> +if (addr->family == AF_INET6
> +&& IN6_IS_ADDR_V4MAPPED((struct in6_addr *)addr->ipaddr_ptr)) {
> +struct in_addr *v4 = (struct in_addr *)&((apr_uint32_t
> *)addr->ipaddr_ptr)[3];
> +
> +if (!memcmp(inaddr_any, v4, sizeof *v4)) {
> +return 1;
> +}
> +}
> +#endif
> +}
> +return 0;
> +}
>
>
> Haven't tested on OpenBSD/NetBSD but I suspect the issue is also present
> on this platforms.
>
> --
> olli
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Issue with apr-1.5.0 on FreeBSD 10beta3

[Jeff Trawick]

On Thu, Nov 21, 2013 at 5:48 PM, olli hauer  wrote:

> Hi,
>
> sorry for late response to apr-1.5.0 ...
>
> I've done some tests with apr-1.5.0 on FreeBSD 10 (amd64)
> and it seems there is an issue that breaks apache24.
>
> With apr-1.5.0 apache22 works but apache24 is broken.
> apache starts fine, nothing special in the logs or during
> start with -X but no response is coming back.
>

Fixed with 1.5.x commit r1551672...


> apr/apr-util test:
> 
> apr-1.5.0:  all tests passed [1]
> apr-util-1.5.3: all tests passed
>
>
> working configurations (FreeBSD beta3 [1]
> =
> apache22-2.2.26 apr-1.4.8 apr-util-1.5.3
> apache22-2.2.26 apr-1.5.0 apr-util-1.5.3
> apache24-2.4.6  apr-1.4.8 apr-util-1.5.2
> apache24-2.4.7  apr-1.4.8 apr-util-1.5.2
> apache24-2.4.6  apr-1.4.8 apr-util-1.5.3
> apache24-2.4.7  apr-1.4.8 apr-util-1.5.3
>
> broken combinations:
> =
> apache24-2.4.6  apr-1.5.0 apr-util-1.5.3
> apache24-2.4.7  apr-1.5.0 apr-util-1.5.3
>
> All tests where done with MPM worker.
>
>
> FreeBSD 8.4 (amd64) seems OK in all combinations
> FreeBSD 9.2 (amd64) seems OK in all combinations
>
> [1] FreeBSD 10 beta3 with iconv UTF7 patch r258316
> (head/lib/libiconv_modules/UTF7/citrus_utf7.c)
>
> Any hints where to start?
>
> --
> Regards,
> olli
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Issue with apr-1.5.0 on FreeBSD 10beta3

[Jeff Trawick]

On Sun, Dec 8, 2013 at 8:56 AM, Jeff Trawick  wrote:

> On Tue, Nov 26, 2013 at 4:01 PM, Rainer Jung wrote:
>
>> On 26.11.2013 15:58, olli hauer wrote:
>> > On 2013-11-25 23:25, Jeff Trawick wrote:
>>
>> >> See if this brings any happiness:
>> >>
>> >> Index: network_io/unix/sockets.c
>> >> ===
>> >> --- network_io/unix/sockets.c (revision 1545394)
>> >> +++ network_io/unix/sockets.c (working copy)
>> >> @@ -273,7 +273,7 @@
>> >>  #endif /* TCP_NODELAY_INHERITED */
>> >>  #if APR_O_NONBLOCK_INHERITED
>> >>  if (apr_is_option_set(sock, APR_SO_NONBLOCK) == 1) {
>> >> -apr_set_option(*new, APR_SO_NONBLOCK, 1);
>> >> +/* apr_set_option(*new, APR_SO_NONBLOCK, 1); */
>> >>  }
>> >>  #endif /* APR_O_NONBLOCK_INHERITED */
>> >
>> >
>> > I can confirm after removing the line in apr-1.5.0 apache24 no longer
>> hangs.
>> > (tested with apache-2.4.6 / 2.4.7)
>> >
>> > I seen now why this is triggered by comparing apr.h after `./configure',
>> >
>> >> grep APR_O_NONBLOCK_INHERITED work/apr-1.4.8/include/apr.h
>> > ./work/apr-1.4.8/include/apr.h:#define APR_O_NONBLOCK_INHERITED 0
>> >
>> >> grep APR_O_NONBLOCK_INHERITED work/apr-1.5.0/include/apr.h
>> > work/apr-1.5.0/include/apr.h:#define APR_O_NONBLOCK_INHERITED 1
>> >
>> >
>> >> There are some APR 1.5 autoconf changes to consider at
>> >>
>> http://svn.apache.org/viewvc/apr/apr/branches/1.5.x/build/apr_network.m4?view=log
>> >
>> > OK, backing out the changes from r1502805 seems to do the trick on 10b3
>> > http://svn.apache.org/viewvc?view=revision&revision=1502805
>> >
>> >> grep APR_O_NONBLOCK_INHERITED work/apr-1.5.0/include/apr.h
>> > work/apr-1.5.0/include/apr.h:#define APR_O_NONBLOCK_INHERITED 0
>>
>> But acking out that change simply breaks the configure test on any
>> platform, because the resulting detection program no longer compiles.
>>
>> So the real culprit, is that the detection isn't doing the right thing.
>>
>> The test was changed before the compilation fix in the following revision:
>>
>>
>> http://svn.apache.org/viewvc/apr/apr/branches/1.5.x/build/apr_network.m4?r1=887002&r2=1449569&pathrev=1502805&diff_format=h
>>
>> That was due to the fact that I saw the test providing unreliable
>> results on a busy machine.
>>
>> So the question to me is: is the O_NONBLOCK setting inherited from a
>> listening socket on FreeBSD 10 - that's what the test tries to detect -
>> and how can we fix this feature test?
>>
>
> O_NONBLOCK is inherited from either an IPv6 listener or IPv4 listener in
> the obvious case on FreeBSD (9 and 10 tested), where "obvious" = V6ONLY in
> default setting (clearly ON), IPv6 client socket used to connect to IPv6
> server socket, IPv4 client socket used to connect to IPv4 server socket.
>  If I set V6ONLY to OFF, I still see O_NONBLOCK inherited.
>
> This is with a pure sockets program, ruling out APR.
>
>
>>
>> Or: is the test correct, but it previously failed for systems, where the
>> Apache or APR code does not do the right thing if the test would have
>> succeeded.
>>
>
> I guess something about the real world scenario in httpd (combination of
> other settings on the socket or presence of another listener on the port or
> something else unexpected) is breaking this.  But I suppose there is other
> code that could be broken and needs to be tested for completeness, such as
> failing to set non-blocking in the listener but managing to set the flag in
> the APR socket.
>

I forgot that FreeBSD is a real OS (has source code for kernel installed) :)

To make a long story short, FreeBSD 10 introduces accept4().  APR uses
accept4() where it can find it.  accept4() on Linux and FreeBSD 10 both
have a SOCK_NONBLOCK flag, but on FreeBSD 10 the SOCK_NONBLOCK is the sole
determiner of whether or not the connected socket is non-blocking.

(Recall that my binaries built on FreeBSD 9 worked fine.)

So APR's use of accept4() was broken w.r.t. inherited non-blocking on
FreeBSD 10 but for a while we still worked because the configure-time check
didn't work right with clang (the normal compiler on FreeBSD 10).

Once the clang issue was resolved, we hit the bad use of
accept4()-on-FreeBSD 10.

I guess when calling accept4() and SOCK_NONBLOCK is defined we need to set
the SOCK_NONBLOCK flag if the listen socket is non-blocking, and not worry
about the more detailed semantics of accept4().

(untested as of yet, though I'm sure that will change in the next couple of
days)

--/--

This is separate from the httpd issue -- fixing the FreeBSD version check
for --{enable|disable}-v6mapped, for which there is a patch earlier in this
thread.


>
>
>
>>
>> Regards,
>>
>> Rainer
>>
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: CMake build doesn't define 'WINNT', but apr headers check for it anyway

[Jeff Trawick]

On Thu, Dec 5, 2013 at 9:13 AM, Bert Huijben  wrote:

> Hi,
>
>
>
> On Windows apr_arch_misc.h checks for the ‘WINNT’ define, which was
> unconditionally defined on Windows before the CMake build. But now it is no
> longer defined. This enables some additional dynamic load operations that
> could fail in some cases (See “Race condition in
> APR_DECLARE_LATE_DLL_FUNC() implementation”).
>
>
>
> We could fix this by defining WINNT, but we might as well just remove the
> check as we don’t support systems older than NT 4.0 anyway..
>
>
>
> Bert
>

Thanks!

Visual Studio project file maintainers, can I just remove the /D "WINNT"
everywhere?  I hate to leave that dangling.  (Obviously the C code will be
changed to stop referencing it too :) )

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: buffered files read after apr_file_close()'ed

[Jeff Trawick]

On Tue, Dec 3, 2013 at 9:15 AM, Daniel Lescohier
wrote:

> A null pointer will cause a segmentation fault.  Is it guaranteed that the
> memory page that the pointer 0xdeadbeef points to is one that is not marked
> readable & writable, so that one would get a segmentation fault on
> reading/writing to it?
>
> However, the functions still need to change to return errors for the cases
> when they are unbuffered files.  The buffer won't be referenced (and cause
> a crash) in those cases.
>
> I think the read/write functions should also do *nbytes=0 when filedes<0
> so caller's loops will stop looping.
>

For unbuffered files they'll generally get rv == EBADF  for free, right?
 And apr_file_read() for Unix seems to set *nbytes = 0 if an error occurs??

>
> In addition, apr_file_eof should return an error APR_EBADF:
>
> APR_DECLARE(apr_status_t) apr_file_eof(apr_file_t *fptr)
> {
> +if (fptr->filedes < 0) {
> +return APR_EBADF;
> +}
> if (fptr->eof_hit == 1) {
> return APR_EOF;
> }
> return APR_SUCCESS;
> }
>
>
(shrug)

* Cheap mechanisms in apr_FOO_close to help catch application bugs later
(e.g., invalidating pointers or file descriptors): awesome
* Adding sanity checking like this for application bugs: never-ending work
* Crashes due to application bugs: fine with me
* Negative feedback due to application bugs as long as we don't have to
check for the condition: awesome
* Hangs or incorrect/invalid feedback due to application bugs when
otherwise APR would require explicit code to check for it: fine with me

But then this particular mod_cache_disk bug doesn't seem so interesting to
me personally :)  (My own Mileage May Vary)

Maybe the extra sanity check is not in an API called over and over, so it
doesn't clutter the main path.  (not so bad)



>
> On Tue, Dec 3, 2013 at 8:41 AM, Stefan Ruppert  wrote:
>
>> Am 03.12.2013 14:18, schrieb Jeff Trawick:
>>
>>> On Tue, Dec 3, 2013 at 3:16 AM, Stefan Ruppert >> <mailto:s...@myarm.com>> wrote:
>>>
>>> Am 03.12.2013 00:37, schrieb William A. Rowe Jr.:
>>>
>>> On Mon, 02 Dec 2013 01:34:58 +0100
>>> Branko Čibej mailto:br...@apache.org>> wrote:
>>>
>>> On 02.12.2013 01:29, Eric Covener wrote:
>>>
>>> I am looking at a httpd bug that causes a hang on
>>> windows but
>>> succeeds on unix.
>>>
>>> It seems that (short) files are opened w/ buffering,
>>> read,
>>> apr_file_closed, and read again [succesfully on unix]
>>>
>>> On Unix, they sare satisfied out of the buffer.
>>>   file->fileset is
>>> -1. On Windows, the destroyed apr_thread_mutex causes a
>>> hang.
>>>
>>> Is reading from the closed file on the extreme bogus end
>>> of the
>>> spectrum as I suspect and just getting lucky on the unix
>>> case?
>>>
>>>
>>> I'd certainly call a successful read from a closed file a
>>> bug.
>>>
>>> Should they blow up in 2.0 during a read if they've been
>>> closed?
>>>
>>>
>>> Dunno ... my gut feeling in cases like this is to just leave
>>> it be.
>>> Developers should have some fun finding heisenbugs, too. :)
>>>
>>>
>>> If we fix this, it needs to be minimal impact.  Zero'ing out the
>>> buffer on close seems like the lowest cpu impact.
>>>
>>>
>>> A minimal impact and IMHO the correct fix is to return an error in
>>> buffered I/O if the file was closed.
>>>
>>> An application should not call a read or write function on a closed
>>> file. If it does its a bug and it should be notified about that fact.
>>>
>>>
>>> I keep telling myself over the years that APR's propensity to crash when
>>> called in situations as wrong as this (quite different from proprietary
>>> libraries with other considerations) is actually very good for code
>>> quality in the long run.
>>>
>>> What's the least we can do for this case that avoids having to check
>>> good calls for validity and yet give unmistakable feedback?  Clear the
>>> buffer pointer during close?
>>>
>>
>> You are absolutly right, after a close the file structure isn't valid
>> anymore thus checking the file descriptor is a shot in the dark...
>>
>> Maybe not clearing the buffer pointer but assigning 0xdeadbeef to force a
>> crash?
>>
>> Regards,
>> Stefan
>>
>>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: buffered files read after apr_file_close()'ed

[Jeff Trawick]

On Tue, Dec 3, 2013 at 3:16 AM, Stefan Ruppert  wrote:

> Am 03.12.2013 00:37, schrieb William A. Rowe Jr.:
>
>  On Mon, 02 Dec 2013 01:34:58 +0100
>> Branko Čibej  wrote:
>>
>>  On 02.12.2013 01:29, Eric Covener wrote:
>>>
 I am looking at a httpd bug that causes a hang on windows but
 succeeds on unix.

 It seems that (short) files are opened w/ buffering, read,
 apr_file_closed, and read again [succesfully on unix]

 On Unix, they sare satisfied out of the buffer.  file->fileset is
 -1. On Windows, the destroyed apr_thread_mutex causes a hang.

 Is reading from the closed file on the extreme bogus end of the
 spectrum as I suspect and just getting lucky on the unix case?

>>>
>>> I'd certainly call a successful read from a closed file a bug.
>>>
>>>  Should they blow up in 2.0 during a read if they've been closed?

>>>
>>> Dunno ... my gut feeling in cases like this is to just leave it be.
>>> Developers should have some fun finding heisenbugs, too. :)
>>>
>>
>> If we fix this, it needs to be minimal impact.  Zero'ing out the
>> buffer on close seems like the lowest cpu impact.
>>
>>
> A minimal impact and IMHO the correct fix is to return an error in
> buffered I/O if the file was closed.
>
> An application should not call a read or write function on a closed file.
> If it does its a bug and it should be notified about that fact.
>

I keep telling myself over the years that APR's propensity to crash when
called in situations as wrong as this (quite different from proprietary
libraries with other considerations) is actually very good for code quality
in the long run.

What's the least we can do for this case that avoids having to check good
calls for validity and yet give unmistakable feedback?  Clear the buffer
pointer during close?



> Thus I would propose the following fix in apr_file_read() and any other
> read/write function which uses buffered I/O:
>
> APR_DECLARE(apr_status_t) apr_file_read(apr_file_t *thefile, void *buf,
> apr_size_t *nbytes)
> {
> apr_ssize_t rv;
> apr_size_t bytes_read;
>
> +if (thefile->filedes < 0) {
> +return APR_EBADF;
> +}
>
> if (*nbytes <= 0) {
> *nbytes = 0;
> return APR_SUCCESS;
> }
>
> Regards,
> Stefan
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Fwd: apr / freebsd

[Jeff Trawick]

Forwarding thread from Greg, whose post bounced...

(There was a related thread on users@httpd earlier.)

-- Forwarded message --
From: Greg Ames 
Date: Sun, Nov 24, 2013 at 7:03 AM
Subject: Re: apr / freebsd
To: Richard Kojedzinszky 
Cc: Jeff Trawick , dev 


Hi Richard,

I retired from IBM last Jan, but still lurk on some of the apr/httpd
mailing lists even though I haven't contributed any code in a long time.

Back when we came up with those lock hints, our priorities were
1. reliability,
2. simplicity for users (i.e. idiot proof), and
3. performance.

I know FreeBSD has matured in the last decade, so I wouldn't be surprised
if the best default is different today.

re mod_fcgid: I haven't contributed anything to it, other than enthusiastic
support of the concept.  I've cc'd people who are more actively involved
with apr and mod_fcgid.

Best regards,
Greg Ames

on a sailboat anchored in the Sea of Abaco, Bahamas :-) looking at a red
sunrise and Barometer Bob's forecast of an approaching cold front plus
25-35 knot winds tonight :(
On Nov 20, 2013 3:50 AM, "Richard Kojedzinszky"  wrote:

> Dear Greg,
>
> I've found your name in a commit in apr sources, specially in
> build/apr_hints.m4. You've set apr_lock_method to FLOCK for FreeBSD
> systems, but that was more than ten years ago. I am courious about that
> hint is still needed or not, but how I get there is a strange way:
> I've set up apache2.2 and mod_fcgid, and as this lock method is forced,
> mod_fcgid creates temp lock files in /tmp, and my regular /tmp cleaning
> process unfortunately removes that files after some days. And this
> effectively stops apache from working.
>
> So please review that decision, is that hint still needed in FreeBSD
> systems or not.
>
> Thanks in advance,
>
> Kojedzinszky Richard
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: rebuild of httpd-2.2.X with apr-1.4.8 and apr-util.1-4-2

[Jeff Trawick]

On Mon, Nov 25, 2013 at 6:28 PM, Michael Felt  wrote:

> Under the assumption that the httpd-2.2.X branch is suppossed to be
> runninf under the apr*-1.4.X branches I am rebuilding all from scratch and
> including make check.
>

httpd 2.2.x works with apr/apr-util 1.4.x or 1.5.x branches (perhaps 1.3.x
branches too)



> With apr-1.4.8 on AIX I am getting an error - testsock returns 1-of 9
> errors.
> More difficult for me is the apr-util make check failure:
> ===
> testxml : SUCCESS
> testxlate   : |/bin/sh[17]: 815296 Segmentation fault(coredump)
> Programs failed: testall
> make[1]: *** [check] Error 139
> make[1]: Leaving directory `/data/prj/apache/apr/apr-util-1.4.2/test'
> make: *** [check] Error 2
> root@x093:[/data/prj/apache/apr/apr-util-1.4.2]
> ===
> 1. Does anyone remember if this is something seen before, and hopefully
> not important.
> 2. What is the simple change to the tests to skip testxlate and run to
> finish, and worry about testxlate later.
>

 Maybe configure apr-util with "--without-iconv" is the easiest?

Or edit test/testxlate.c and disable the call to abts_run_test() in
testxlate()...


> p.s. cross posting (hope that is okay) as I have an embedded question:
> should I even be bothering with the apr*1.4.X versions?
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Issue with apr-1.5.0 on FreeBSD 10beta3

[Jeff Trawick]

Let's move this to dev@httpd and omit dev@apr (after this e-mail)...


On Sun, Nov 24, 2013 at 8:28 AM, olli hauer  wrote:

> On 2013-11-22 00:08, Jeff Trawick wrote:
> > On Thu, Nov 21, 2013 at 5:48 PM, olli hauer  wrote:
> >
> >> Hi,
> >>
> >> sorry for late response to apr-1.5.0 ...
> >>
> >> I've done some tests with apr-1.5.0 on FreeBSD 10 (amd64)
> >> and it seems there is an issue that breaks apache24.
> >>
> >> With apr-1.5.0 apache22 works but apache24 is broken.
> >> apache starts fine, nothing special in the logs or during
> >> start with -X but no response is coming back.
> >>
> >> apr/apr-util test:
> >> 
> >> apr-1.5.0:  all tests passed [1]
> >> apr-util-1.5.3: all tests passed
> >>
> >>
> >> working configurations (FreeBSD beta3 [1]
> >> =
> >> apache22-2.2.26 apr-1.4.8 apr-util-1.5.3
> >> apache22-2.2.26 apr-1.5.0 apr-util-1.5.3
> >> apache24-2.4.6  apr-1.4.8 apr-util-1.5.2
> >> apache24-2.4.7  apr-1.4.8 apr-util-1.5.2
> >> apache24-2.4.6  apr-1.4.8 apr-util-1.5.3
> >> apache24-2.4.7  apr-1.4.8 apr-util-1.5.3
> >>
> >> broken combinations:
> >> =
> >> apache24-2.4.6  apr-1.5.0 apr-util-1.5.3
> >> apache24-2.4.7  apr-1.5.0 apr-util-1.5.3
> >>
> >> All tests where done with MPM worker.
> >>
> >>
> >> FreeBSD 8.4 (amd64) seems OK in all combinations
> >> FreeBSD 9.2 (amd64) seems OK in all combinations
> >>
> >> [1] FreeBSD 10 beta3 with iconv UTF7 patch r258316
> >> (head/lib/libiconv_modules/UTF7/citrus_utf7.c)
> >>
> >> Any hints where to start?
> >>
> >
> > Set LogLevel trace8 and compare good vs. bad.
> > Start with -X then attach with dtruss and compare good vs. bad.
> > Get open fds displayed by lsof and compare good vs. bad.
> > Is connection to client held open?  Get backtraces.
> >
> > I just compared 1.4.8 vs. 1.5.0 and didn't see anything that looked
> > remotely likely.
> >
>
> Comparing trace8 outputs showed the request is processed
> but the following code snippet in server/core_filters.c
> never get TRUE except the client cancels the request.
>
> To get some better log entries I've used server/core_filters.c
> r1510295 from trunk.
>
>
> @@server/core_filters.c (line 510)
> if (APR_BUCKET_IS_FLUSH(bucket)
> || non_file_bytes_in_brigade >= THRESHOLD_MAX_BUFFER
> || morphing_bucket_in_brigade
> || eor_buckets_in_brigade > MAX_REQUESTS_IN_PIPELINE) {
> ...
> }
>
> [http:trace3] http_filters.c(974):[client x.x.x.x:x] Response sent with
> status 200, headers:
> [http:trace5] http_filters.c(983):[client x.x.x.x:x]   Date: Sun, 24 Nov
> 2013 10:28:37 GMT
> [http:trace5] http_filters.c(986):[client x.x.x.x:x]   Server:
> Apache/2.4.7 (FreeBSD)
> [http:trace4] http_filters.c(804):[client x.x.x.x:x]   Last-Modified: Sat,
> 23 Nov 2013 16:51:58 GMT
> [http:trace4] http_filters.c(804):[client x.x.x.x:x]   ETag:
> \\"be-4ebdaf2ef2780\\"
> [http:trace4] http_filters.c(804):[client x.x.x.x:x]   Accept-Ranges: bytes
> [http:trace4] http_filters.c(804):[client x.x.x.x:x]   Content-Length: 190
> [http:trace4] http_filters.c(804):[client x.x.x.x:x]   Keep-Alive:
> timeout=5, max=100
> [http:trace4] http_filters.c(804):[client x.x.x.x:x]   Connection:
> Keep-Alive
> [http:trace4] http_filters.c(804):[client x.x.x.x:x]   Content-Type:
> text/html
> [core:trace8] core_filters.c(576):[client x.x.x.x:x] brigade contains:
> bytes: 284, non-file bytes: 284, eor buckets: 0, morphing buckets: 0
> [core:trace8] core_filters.c(576):[client x.x.x.x:x] brigade contains:
> bytes: 474, non-file bytes: 284, eor buckets: 0, morphing buckets: 0
> [core:trace8] core_filters.c(576):[client x.x.x.x:x] brigade contains:
> bytes: 474, non-file bytes: 284, eor buckets: 1, morphing buckets: 0
>
>
> This following lines are only seen if
>   apr-1-5.0 was build without IPv6 support
>   or apache24 was build with v4-mapping enabled
>   or "Listen $IP:$port" is given in httpd.conf
>
> [core:trace6] core_filters.c(526):[client x.x.x.x:x] will flush because of
> FLUSH bucket
> [core:trace8] core_filters.c(528):[client x.x.x.x:x] seen in brigade so
> far: bytes: 474, non-file bytes: 284, eor buckets: 1, morphing buckets: 0
> [core:trace8] core_filters.c(555):[client x.x.x.x:x] flushing now
> [core:trace8] core_filters.c(568):[client x.x

Re: svn commit: r1410459 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/mpm/event/event.c server/mpm/eventopt/eventopt.c

[Jeff Trawick]

On Sat, Nov 23, 2013 at 3:45 PM, Jim Jagielski  wrote:

> I'm just curious why people never saw this on trunk...
> That code path is almost exactly a year old. No one has
> hit this in 12 months??
>

l rarely try trunk except on

* Windows, which uses a system mechanism regardless of compiler
* Linux or FreeBSD, 64-bit gcc builds

--/--

I'm curious what other scenarios will fail though.  I can try Sun Studio on
Solaris 10 x86_64 (32-bit and 64-bit builds) "soon".  But Sun Studio on
SPARC presumably uses different explicit code in APR and I don't have
access to that.

Right now it looks reasonable to change the ia32.c and os390/atomic.c
implementations in APR as described before, but there's no substitute for
actually trying the other atomic implementations, which look safe to me but
with little certainty.



> On Nov 23, 2013, at 12:45 PM, Rainer Jung  wrote:
>
> > On 23.11.2013 14:15, Jeff Trawick wrote:
> >> On Sat, Nov 23, 2013 at 8:04 AM, Rainer Jung  >> <mailto:rainer.j...@kippdata.de>> wrote:
> >>
> >>On 22.11.2013 23:03, Jim Jagielski wrote:
> >>> Anyone ever try OpenPA?
> >>>
> >>>  https://trac.mcs.anl.gov/projects/openpa/
> >>>
> >>> It's under MIT, fwiw.
> >>
> >>Haven't tried it but the README
> >>
> >>http://git.mcs.anl.gov/radix/openpa.git/blob_plain/HEAD:/README
> >>
> >>indicates only platform support based on gcc plus Windows (but they
> say
> >>they haven't set up a build system for it) plus Solaris (but that
> seems
> >>to be Solaris 10+ only, at least my oldest Solaris 8 doesn't seem to
> >>have the needed implementation).
> >>
> >>Regards,
> >>
> >>Rainer
> >>
> >>
> >> By the way, Rainer, in your l*m*n test combinations, which compiler(s)
> >> did you use on Solaris while confirming that 2.4.7 Event works at least
> >> a little?
> >
> > I'm only building with gcc. On Solaris 8 with gcc 4.1.2, on Solaris 10
> > the latest and greatest (4.8.2).
> >
> > Will post the full 2.4.7 results a bit later (only for the sake of
> > completeness), but the builds are also broken for event on Linux 32 Bits
> > even when using gcc:
> >
> > [Thu Nov 21 11:34:53.149765 2013] [mpm_event:crit] [pid 18492:tid
> > 3080439472] AH02405: atomics not working as expected
> >
> > Sorry for not having checked progress during the tests, but the last
> > combinations just finished right now.
> >
> > Regards,
> >
> > Rainer
> >
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1410459 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/mpm/event/event.c server/mpm/eventopt/eventopt.c

[Jeff Trawick]

On Fri, Nov 22, 2013 at 4:32 PM, Jim Jagielski  wrote:

> The thing is is not only do we worry about the return code
> but also that the values we dec32 and inc32 also behave
> as signed ints. Note below we worry also that queue_info->idlers
> itself is signed, and can be < 0 :
>

Okay gurus, tell me where I'm confused (maybe I'm trainable):

I guess the opportunity for failure is if one of the APR implementations of
apr_atomic_dec32() is setting the return value in C code.  But doing that
(i.e., not having the assembly code set a local variable which is returned)
is uncommon.

Imagine that this existing z/OS code is changed to simply "return new_val".
 Conversion from 32-bit unsigned int to 32-bit signed int is undefined IIUC
and in the unlikely case that the compiler tried to change the bits some
trick would be needed in the code.

int apr_atomic_dec32(volatile apr_uint32_t *mem)
{
apr_uint32_t old, new_val;

old = *mem;   /* old is automatically updated on cs failure */
do {
new_val = old - 1;
} while (__cs(&old, (cs_t *)mem, new_val));

return new_val != 0;
}



> apr_status_t ap_queue_info_try_get_idler(fd_queue_info_t * queue_info)
> {
> int prev_idlers;
> prev_idlers = apr_atomic_dec32((apr_uint32_t *)&(queue_info->idlers));
> if (prev_idlers <= 0) {
> apr_atomic_inc32((apr_uint32_t *)&(queue_info->idlers));/*
> back out dec */
> return APR_EAGAIN;
> }
> return APR_SUCCESS;
> }
>
> apr_status_t ap_queue_info_wait_for_idler(fd_queue_info_t * queue_info,
>   int *had_to_block)
> {
> apr_status_t rv;
> int prev_idlers;
>
> /* Atomically decrement the idle worker count, saving the old value */
> /* See TODO in ap_queue_info_set_idle() */
> prev_idlers = apr_atomic_add32((apr_uint32_t *)&(queue_info->idlers),
> -1);
>
> /* Block if there weren't any idle workers */
> if (prev_idlers <= 0) {
> rv = apr_thread_mutex_lock(queue_info->idlers_mutex);
> if (rv != APR_SUCCESS) {
> AP_DEBUG_ASSERT(0);
> /* See TODO in ap_queue_info_set_idle() */
> apr_atomic_inc32((apr_uint32_t *)&(queue_info->idlers));/*
> back out dec */
> return rv;
> }
> /* Re-check the idle worker count to guard against a
>  * race condition.  Now that we're in the mutex-protected
>  * region, one of two things may have happened:
>  *   - If the idle worker count is still negative, the
>  * workers are all still busy, so it's safe to
>  * block on a condition variable.
>  *   - If the idle worker count is non-negative, then a
>  * worker has become idle since the first check
>  * of queue_info->idlers above.  It's possible
>  * that the worker has also signaled the condition
>  * variable--and if so, the listener missed it
>  * because it wasn't yet blocked on the condition
>  * variable.  But if the idle worker count is
>  * now non-negative, it's safe for this function to
>  * return immediately.
>  *
>  * A negative value in queue_info->idlers tells how many
>  * threads are waiting on an idle worker.
>  */
> if (queue_info->idlers < 0) {
> *had_to_block = 1;
> rv = apr_thread_cond_wait(queue_info->wait_for_idler,
>   queue_info->idlers_mutex);
>
> On Nov 22, 2013, at 3:40 PM, Jeff Trawick  wrote:
>
> > On Fri, Nov 22, 2013 at 3:24 PM, Jeff Trawick  wrote:
> > On Fri, Nov 22, 2013 at 2:52 PM, Jim Jagielski  wrote:
> > Note, the only think changed in event now (via
> https://svn.apache.org/viewvc?view=revision&revision=1542560)
> > is that event *checks* that atomics work as required for
> > event... if the check fails, it means that event has
> > been "broken" on that system, assuming it ever hit
> > blocked idlers, for a *long* time...
> >
> > Got it...  fdqueue.c is asking for trouble...
> >
> > I'm using atomic/unix/ia32.c with icc too.
> >
> > Need to compare generated code...  I hate stuff like "int foo() {
> unsigned char x;  ... return x;  }"
> >
> >
> > APR is documented as returning "zero if the value becomes zero on
> decrement, otherwise non-zero".
> >
> > With gcc we use get __sync_sub_and_fetch(), which returns the new value
> after the decrement.
> >
> > With icc w

Re: svn commit: r1410459 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/mpm/event/event.c server/mpm/eventopt/eventopt.c

[Jeff Trawick]

On Fri, Nov 22, 2013 at 4:27 PM, Jeff Trawick  wrote:

> On Fri, Nov 22, 2013 at 3:57 PM, Jeff Trawick  wrote:
>
>> On Fri, Nov 22, 2013 at 3:40 PM, Jeff Trawick  wrote:
>>
>>> On Fri, Nov 22, 2013 at 3:24 PM, Jeff Trawick  wrote:
>>>
>>>> On Fri, Nov 22, 2013 at 2:52 PM, Jim Jagielski  wrote:
>>>>
>>>>> Note, the only think changed in event now (via
>>>>> https://svn.apache.org/viewvc?view=revision&revision=1542560)
>>>>> is that event *checks* that atomics work as required for
>>>>> event... if the check fails, it means that event has
>>>>> been "broken" on that system, assuming it ever hit
>>>>> blocked idlers, for a *long* time...
>>>>>
>>>>
>>>> Got it...  fdqueue.c is asking for trouble...
>>>>
>>>> I'm using atomic/unix/ia32.c with icc too.
>>>>
>>>> Need to compare generated code...  I hate stuff like "int foo() {
>>>> unsigned char x;  ... return x;  }"
>>>>
>>>>
>>> APR is documented as returning "zero if the value becomes zero on
>>> decrement, otherwise non-zero".
>>>
>>> With gcc we use get __sync_sub_and_fetch(), which returns the new value
>>> after the decrement.
>>>
>>> With icc we use the assembler implementation in APR.  I think that's
>>> returning 1 instead of -1.
>>>
>>
>> It does a decrement long, which sets the zero flag as appropriate.  Then
>> it does set-not-equal to set what becomes the return value to 0 if the
>> result of the decrement was 0 and 1 otherwise.
>>
>> It "should be easy" to make it return the new value like the
>> __sync_sub_and_fetch() version does :)
>>
>
> Any Intel assembly gurus out there?
>
>  --- apr.orig/atomic/unix/ia32.c 2013-04-21 14:28:47.0 -0700
> +++ apr/atomic/unix/ia32.c 2013-11-22 13:16:04.0 -0800
> @@ -57,14 +57,14 @@
>
>  APR_DECLARE(int) apr_atomic_dec32(volatile apr_uint32_t *mem)
>  {
> -unsigned char prev;
> +apr_uint32_t newvalue;
>
> -asm volatile ("lock; decl %0; setnz %1"
> -  : "=m" (*mem), "=qm" (prev)
> +asm volatile ("lock; decl %0; movl %0,%1"
> +  : "=m" (*mem), "=qm" (newvalue)
>: "m" (*mem)
>: "memory");
>
> -return prev;
> +return newvalue;
>  }
>
>  APR_DECLARE(apr_uint32_t) apr_atomic_cas32(volatile apr_uint32_t *mem,
> apr_uint32_t with,
>
> It probably uses a zillion more cycles than the previous version.  I
> wonder what __sync_sub_and_fetch() does exactly.
>
> Also, maybe stdcxx has an implementation somewhere that matches
> __sync_sub_and_fetch() (I see
> http://svn.apache.org/repos/asf/stdcxx/branches/4.2.x/include/rw/_atomic-sync.h,
> but no time to look now.
>

"Most" (I won't swear exactly which ones ;) ) APR implementations of
apr_atomic_dec32() return the new value.  The z/OS code in
atomic/os390/atomic.c needs an obvious fix too.  (IIUC, Event MPM should
work there because of recently added pollset support, though I guess a few
lines in configure and event need to be patched to recognize the new
pollset implementation as usable by event.)


>
>>
>>>
>>> Here is where fdqueue needs to be able to see a negative return code:
>>>
>>> apr_status_t ap_queue_info_try_get_idler(fd_queue_info_t * queue_info)
>>> {
>>> int prev_idlers;
>>> prev_idlers = apr_atomic_dec32((apr_uint32_t
>>> *)&(queue_info->idlers));
>>> if (prev_idlers <= 0) {
>>> apr_atomic_inc32((apr_uint32_t *)&(queue_info->idlers));/*
>>> back out dec */
>>> return APR_EAGAIN;
>>> }
>>> return APR_SUCCESS;
>>> }
>>>
>>> ("prev" in the ia32.c version of apr_atomic_dec32() and "prev_idlers"
>>> here is deceiving.)
>>>
>>>
>>>>
>>>>>
>>>>> You should be seeing it in trunk as well...
>>>>>
>>>>>
>>>>> On Nov 22, 2013, at 2:43 PM, Jeff Trawick  wrote:
>>>>>
>>>>> > On Fri, Nov 22, 2013 at 2:39 PM, Jim Jagielski 
>>>>> wrote:
>>>>> >
>>>>> > On Nov 22, 2013, at 2:22 PM, Jeff Trawick  wrote:
>>>>> >
>>>>> > > On Sa

Re: svn commit: r1410459 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/mpm/event/event.c server/mpm/eventopt/eventopt.c

[Jeff Trawick]

On Fri, Nov 22, 2013 at 3:57 PM, Jeff Trawick  wrote:

> On Fri, Nov 22, 2013 at 3:40 PM, Jeff Trawick  wrote:
>
>> On Fri, Nov 22, 2013 at 3:24 PM, Jeff Trawick  wrote:
>>
>>> On Fri, Nov 22, 2013 at 2:52 PM, Jim Jagielski  wrote:
>>>
>>>> Note, the only think changed in event now (via
>>>> https://svn.apache.org/viewvc?view=revision&revision=1542560)
>>>> is that event *checks* that atomics work as required for
>>>> event... if the check fails, it means that event has
>>>> been "broken" on that system, assuming it ever hit
>>>> blocked idlers, for a *long* time...
>>>>
>>>
>>> Got it...  fdqueue.c is asking for trouble...
>>>
>>> I'm using atomic/unix/ia32.c with icc too.
>>>
>>> Need to compare generated code...  I hate stuff like "int foo() {
>>> unsigned char x;  ... return x;  }"
>>>
>>>
>> APR is documented as returning "zero if the value becomes zero on
>> decrement, otherwise non-zero".
>>
>> With gcc we use get __sync_sub_and_fetch(), which returns the new value
>> after the decrement.
>>
>> With icc we use the assembler implementation in APR.  I think that's
>> returning 1 instead of -1.
>>
>
> It does a decrement long, which sets the zero flag as appropriate.  Then
> it does set-not-equal to set what becomes the return value to 0 if the
> result of the decrement was 0 and 1 otherwise.
>
> It "should be easy" to make it return the new value like the
> __sync_sub_and_fetch() version does :)
>

Any Intel assembly gurus out there?

 --- apr.orig/atomic/unix/ia32.c 2013-04-21 14:28:47.0 -0700
+++ apr/atomic/unix/ia32.c 2013-11-22 13:16:04.0 -0800
@@ -57,14 +57,14 @@

 APR_DECLARE(int) apr_atomic_dec32(volatile apr_uint32_t *mem)
 {
-unsigned char prev;
+apr_uint32_t newvalue;

-asm volatile ("lock; decl %0; setnz %1"
-  : "=m" (*mem), "=qm" (prev)
+asm volatile ("lock; decl %0; movl %0,%1"
+  : "=m" (*mem), "=qm" (newvalue)
   : "m" (*mem)
   : "memory");

-return prev;
+return newvalue;
 }

 APR_DECLARE(apr_uint32_t) apr_atomic_cas32(volatile apr_uint32_t *mem,
apr_uint32_t with,

It probably uses a zillion more cycles than the previous version.  I wonder
what __sync_sub_and_fetch() does exactly.

Also, maybe stdcxx has an implementation somewhere that matches
__sync_sub_and_fetch() (I see
http://svn.apache.org/repos/asf/stdcxx/branches/4.2.x/include/rw/_atomic-sync.h,
but no time to look now.


>
>>
>> Here is where fdqueue needs to be able to see a negative return code:
>>
>> apr_status_t ap_queue_info_try_get_idler(fd_queue_info_t * queue_info)
>> {
>> int prev_idlers;
>> prev_idlers = apr_atomic_dec32((apr_uint32_t *)&(queue_info->idlers));
>> if (prev_idlers <= 0) {
>> apr_atomic_inc32((apr_uint32_t *)&(queue_info->idlers));/*
>> back out dec */
>> return APR_EAGAIN;
>> }
>> return APR_SUCCESS;
>> }
>>
>> ("prev" in the ia32.c version of apr_atomic_dec32() and "prev_idlers"
>> here is deceiving.)
>>
>>
>>>
>>>>
>>>> You should be seeing it in trunk as well...
>>>>
>>>>
>>>> On Nov 22, 2013, at 2:43 PM, Jeff Trawick  wrote:
>>>>
>>>> > On Fri, Nov 22, 2013 at 2:39 PM, Jim Jagielski 
>>>> wrote:
>>>> >
>>>> > On Nov 22, 2013, at 2:22 PM, Jeff Trawick  wrote:
>>>> >
>>>> > > On Sat, Nov 17, 2012 at 6:00 AM, Ruediger Pluem 
>>>> wrote:
>>>> > >
>>>> > >
>>>> > > j...@apache.org wrote:
>>>> > > > +i = apr_atomic_dec32(&foo);
>>>> > > > +if (i >= 0) {
>>>> > >
>>>> > > Why can we expect i < 0? apr_atomic_dec32 returns 0 if the dec
>>>> causes foo to become zero and it returns non zero
>>>> > > otherwise. Shouldn't this behavior the same across all platforms?
>>>> And if not should that be fixed in APR?
>>>> > >
>>>> > > icc (Intel) builds of httpd 2.4.7 event MPM (with apr-1.5.0) bomb
>>>> here.
>>>> > >
>>>> > > --enable-nonportable-atomics is specified for apr, though I haven't
>>>> checked what that does with icc.
>

Re: svn commit: r1410459 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/mpm/event/event.c server/mpm/eventopt/eventopt.c

[Jeff Trawick]

On Fri, Nov 22, 2013 at 3:40 PM, Jeff Trawick  wrote:

> On Fri, Nov 22, 2013 at 3:24 PM, Jeff Trawick  wrote:
>
>> On Fri, Nov 22, 2013 at 2:52 PM, Jim Jagielski  wrote:
>>
>>> Note, the only think changed in event now (via
>>> https://svn.apache.org/viewvc?view=revision&revision=1542560)
>>> is that event *checks* that atomics work as required for
>>> event... if the check fails, it means that event has
>>> been "broken" on that system, assuming it ever hit
>>> blocked idlers, for a *long* time...
>>>
>>
>> Got it...  fdqueue.c is asking for trouble...
>>
>> I'm using atomic/unix/ia32.c with icc too.
>>
>> Need to compare generated code...  I hate stuff like "int foo() {
>> unsigned char x;  ... return x;  }"
>>
>>
> APR is documented as returning "zero if the value becomes zero on
> decrement, otherwise non-zero".
>
> With gcc we use get __sync_sub_and_fetch(), which returns the new value
> after the decrement.
>
> With icc we use the assembler implementation in APR.  I think that's
> returning 1 instead of -1.
>

It does a decrement long, which sets the zero flag as appropriate.  Then it
does set-not-equal to set what becomes the return value to 0 if the result
of the decrement was 0 and 1 otherwise.

It "should be easy" to make it return the new value like the
__sync_sub_and_fetch() version does :)


>
> Here is where fdqueue needs to be able to see a negative return code:
>
> apr_status_t ap_queue_info_try_get_idler(fd_queue_info_t * queue_info)
> {
> int prev_idlers;
> prev_idlers = apr_atomic_dec32((apr_uint32_t *)&(queue_info->idlers));
> if (prev_idlers <= 0) {
> apr_atomic_inc32((apr_uint32_t *)&(queue_info->idlers));/*
> back out dec */
>     return APR_EAGAIN;
> }
> return APR_SUCCESS;
> }
>
> ("prev" in the ia32.c version of apr_atomic_dec32() and "prev_idlers" here
> is deceiving.)
>
>
>>
>>>
>>> You should be seeing it in trunk as well...
>>>
>>>
>>> On Nov 22, 2013, at 2:43 PM, Jeff Trawick  wrote:
>>>
>>> > On Fri, Nov 22, 2013 at 2:39 PM, Jim Jagielski 
>>> wrote:
>>> >
>>> > On Nov 22, 2013, at 2:22 PM, Jeff Trawick  wrote:
>>> >
>>> > > On Sat, Nov 17, 2012 at 6:00 AM, Ruediger Pluem 
>>> wrote:
>>> > >
>>> > >
>>> > > j...@apache.org wrote:
>>> > > > +i = apr_atomic_dec32(&foo);
>>> > > > +if (i >= 0) {
>>> > >
>>> > > Why can we expect i < 0? apr_atomic_dec32 returns 0 if the dec
>>> causes foo to become zero and it returns non zero
>>> > > otherwise. Shouldn't this behavior the same across all platforms?
>>> And if not should that be fixed in APR?
>>> > >
>>> > > icc (Intel) builds of httpd 2.4.7 event MPM (with apr-1.5.0) bomb
>>> here.
>>> > >
>>> > > --enable-nonportable-atomics is specified for apr, though I haven't
>>> checked what that does with icc.
>>> > >
>>> >
>>> > As noted back with the orig update, this test is due to the
>>> > fdqueue code in the new event:
>>> >
>>> > apr_status_t ap_queue_info_set_idle(fd_queue_info_t * queue_info,
>>> > apr_pool_t * pool_to_recycle)
>>> > {
>>> > apr_status_t rv;
>>> > int prev_idlers;
>>> >
>>> > ap_push_pool(queue_info, pool_to_recycle);
>>> >
>>> > /* Atomically increment the count of idle workers */
>>> > /*
>>> >  * TODO: The atomics expect unsigned whereas we're using signed.
>>> >  *   Need to double check that they work as expected or else
>>> >  *   rework how we determine blocked.
>>> >  * UPDATE: Correct operation is performed during open_logs()
>>> >  */
>>> > prev_idlers = apr_atomic_inc32((apr_uint32_t
>>> *)&(queue_info->idlers));
>>> >
>>> > /* If other threads are waiting on a worker, wake one up */
>>> > if (prev_idlers < 0) {
>>> >
>>> >
>>> > See the comments ("The atomics expect unsigned whereas...") for
>>> > the reason, etc.
>>> >
>>> > When you say "icc (Intel) builds of httpd 2.4.7 event MPM (with
>>> apr-1.5.0) bomb here."
>>> > do you mean that you get the 'atomics not working as expected' error
>>> > (and the internal server error) or that it core dumps?
>>> >
>>> >
>>> > "atomics not working as expected"
>>> >
>>> > Let me see what code is used...
>>> >
>>> > --
>>> > Born in Roswell... married an alien...
>>> > http://emptyhammock.com/
>>>
>>>
>>
>>
>> --
>> Born in Roswell... married an alien...
>> http://emptyhammock.com/
>>
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Issue with apr-1.5.0 on FreeBSD 10beta3

[Jeff Trawick]

On Fri, Nov 22, 2013 at 4:21 AM, olli hauer  wrote:

> On 2013-11-22 00:08, Jeff Trawick wrote:
> > On Thu, Nov 21, 2013 at 5:48 PM, olli hauer  wrote:
> >
> >> Hi,
> >>
> >> sorry for late response to apr-1.5.0 ...
> >>
> >> I've done some tests with apr-1.5.0 on FreeBSD 10 (amd64)
> >> and it seems there is an issue that breaks apache24.
> >>
> >> With apr-1.5.0 apache22 works but apache24 is broken.
> >> apache starts fine, nothing special in the logs or during
> >> start with -X but no response is coming back.
> >>
> >> apr/apr-util test:
> >> 
> >> apr-1.5.0:  all tests passed [1]
> >> apr-util-1.5.3: all tests passed
> >>
> >>
> >> working configurations (FreeBSD beta3 [1]
> >> =
> >> apache22-2.2.26 apr-1.4.8 apr-util-1.5.3
> >> apache22-2.2.26 apr-1.5.0 apr-util-1.5.3
> >> apache24-2.4.6  apr-1.4.8 apr-util-1.5.2
> >> apache24-2.4.7  apr-1.4.8 apr-util-1.5.2
> >> apache24-2.4.6  apr-1.4.8 apr-util-1.5.3
> >> apache24-2.4.7  apr-1.4.8 apr-util-1.5.3
> >>
> >> broken combinations:
> >> =
> >> apache24-2.4.6  apr-1.5.0 apr-util-1.5.3
> >> apache24-2.4.7  apr-1.5.0 apr-util-1.5.3
> >>
> >> All tests where done with MPM worker.
> >>
> >>
> >> FreeBSD 8.4 (amd64) seems OK in all combinations
> >> FreeBSD 9.2 (amd64) seems OK in all combinations
> >>
> >> [1] FreeBSD 10 beta3 with iconv UTF7 patch r258316
> >> (head/lib/libiconv_modules/UTF7/citrus_utf7.c)
> >>
> >> Any hints where to start?
> >>
> >
> > Set LogLevel trace8 and compare good vs. bad.
> > Start with -X then attach with dtruss and compare good vs. bad.
> > Get open fds displayed by lsof and compare good vs. bad.
> > Is connection to client held open?  Get backtraces.
> >
> > I just compared 1.4.8 vs. 1.5.0 and didn't see anything that looked
> > remotely likely.
> >
>
> Small update,
>
> The issue is only present if apache24 is build with '--disable-v4-mapped'
> which should be the default for FreeBSD >= 5.x.
>
> Long time ago I've opened a PR since the httpd configure script contains
> an error https://issues.apache.org/bugzilla/show_bug.cgi?id=53824
>
>
> - apache24 build with '--disable-v4-mapped'
>  - Listen 80 -> broken
>

Broken for IPv4 connections I suppose but working for IPv6 connections
(e.g., "telnet ::1")?

If v4-mapped is disabled, then httpd should be getting both an IPv4
listener and an IPv6 listener.


 - Listen IPv4.addr:80 -> OK
>
> - apache24 build with '--enable-v4-mapped'
>  - Listen 80 -> OK
>  - Listen IPv4.addr:80 -> OK
>
>
> I think the issue comes from a wrong assumption in sockaddr.c.
>

Note that httpd doesn't use apr_sockaddr_is_wildcard().  apr doesn't use it
except in a regression test.


>
> --- apr-1.4.8/network_io/unix/sockaddr.c2013-05-03
> 20:39:44.0 +0200
> +++ apr-1.5.0/network_io/unix/sockaddr.c2013-11-12
> 15:26:22.0 +0100
> @@ -839,6 +839,35 @@
>  return 0; /* not equal */
>  }
>
> +APR_DECLARE(int) apr_sockaddr_is_wildcard(const apr_sockaddr_t *addr)
> +{
> +static const char inaddr_any[
> +#if APR_HAVE_IPV6
> +sizeof(struct in6_addr)
> +#else
> +sizeof(struct in_addr)
> +#endif
> +] = {0};
> +
> +if (addr->ipaddr_ptr /* IP address initialized */
> +&& addr->ipaddr_len <= sizeof inaddr_any) { /* else bug
> elsewhere? */
> +if (!memcmp(inaddr_any, addr->ipaddr_ptr, addr->ipaddr_len)) {
> +return 1;
> +}
> +#if APR_HAVE_IPV6
> +if (addr->family == AF_INET6
> +&& IN6_IS_ADDR_V4MAPPED((struct in6_addr *)addr->ipaddr_ptr)) {
> +struct in_addr *v4 = (struct in_addr *)&((apr_uint32_t
> *)addr->ipaddr_ptr)[3];
> +
> +if (!memcmp(inaddr_any, v4, sizeof *v4)) {
> +return 1;
> +}
> +}
> +#endif
> +}
> +return 0;
> +}
>

Is the concern just that there is "V4MAPPED"-related code here, or is there
some specific scenario where it wouldn't classify the address properly?



>
>
> Haven't tested on OpenBSD/NetBSD but I suspect the issue is also present
> on this platforms.
>

I might have time in the next few days to test on FreeBSD 9.  I dunno.

I understand that apr 1.4.8 vs. 1.5.0 is the trigger, but I think this is
going to have to be debugged from the problem symptom in httpd backwards to
find the root cause and the difference between 1.4.8 vs. 1.5.0 that
triggered it (which might be two different things).



> --
> olli
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Issue with apr-1.5.0 on FreeBSD 10beta3

[Jeff Trawick]

On Thu, Nov 21, 2013 at 5:48 PM, olli hauer  wrote:

> Hi,
>
> sorry for late response to apr-1.5.0 ...
>
> I've done some tests with apr-1.5.0 on FreeBSD 10 (amd64)
> and it seems there is an issue that breaks apache24.
>
> With apr-1.5.0 apache22 works but apache24 is broken.
> apache starts fine, nothing special in the logs or during
> start with -X but no response is coming back.
>
> apr/apr-util test:
> 
> apr-1.5.0:  all tests passed [1]
> apr-util-1.5.3: all tests passed
>
>
> working configurations (FreeBSD beta3 [1]
> =
> apache22-2.2.26 apr-1.4.8 apr-util-1.5.3
> apache22-2.2.26 apr-1.5.0 apr-util-1.5.3
> apache24-2.4.6  apr-1.4.8 apr-util-1.5.2
> apache24-2.4.7  apr-1.4.8 apr-util-1.5.2
> apache24-2.4.6  apr-1.4.8 apr-util-1.5.3
> apache24-2.4.7  apr-1.4.8 apr-util-1.5.3
>
> broken combinations:
> =
> apache24-2.4.6  apr-1.5.0 apr-util-1.5.3
> apache24-2.4.7  apr-1.5.0 apr-util-1.5.3
>
> All tests where done with MPM worker.
>
>
> FreeBSD 8.4 (amd64) seems OK in all combinations
> FreeBSD 9.2 (amd64) seems OK in all combinations
>
> [1] FreeBSD 10 beta3 with iconv UTF7 patch r258316
> (head/lib/libiconv_modules/UTF7/citrus_utf7.c)
>
> Any hints where to start?
>

Set LogLevel trace8 and compare good vs. bad.
Start with -X then attach with dtruss and compare good vs. bad.
Get open fds displayed by lsof and compare good vs. bad.
Is connection to client held open?  Get backtraces.

I just compared 1.4.8 vs. 1.5.0 and didn't see anything that looked
remotely likely.


> --
> Regards,
> olli
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Error compiling apr_crypto_openssl using cmake

[Jeff Trawick]

On Tue, Nov 19, 2013 at 5:13 AM, Bert Huijben  wrote:

> Hi,
>
> Continuing my work to switch my build chain to cmake for apr, apr-util and
> httpd I now found the same problem in the optional components of apr-util
> that was just fixed in httpd in r1543149: some defines are not quoted
> correctly to the resource compiler when invoked from Visual Studio project
> files.
>

Thanks!


>
> Can somebody apply the attached patch to apr-util 1.5.x?
>

I actually made the simpler change of removing the extra quotes altogether.
 (Perhaps I had based those rc definitions on earlier code in httpd which
had symbols with blanks?)   This works for me with VS 2010 and nmake
generators.

apr trunk: r1543399
apr-util 1.5.x: r1543401


> [[
> * CMakeLists.txt
>(DEFINE_WITH_BLANKS): New macro.
>(apr_crypto_openssl,
> apr_dbd_odbc,
> apr_ldap): Use DEFINE_WITH_BLANKS to properly generate Visual Studio
> 2005-2013 project files.
> ]]
>
> DEFINE_WITH_BLANKS was copied from trawick's patch on httpd.
>
> Thanks,
> Bert
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Does mod_perl/mod_??? need a hook called when a request/conn leaves the original worker thread?

[Jeff Trawick]

For the mod_perl crash with Event that I posted at the URL below, I would
suspect that there's some affinity with the original worker thread.  Can
anyone in mod_perl land confirm?

http://mail-archives.apache.org/mod_mbox/perl-dev/201311.mbox/%3CCAKUrXK6C3R_F3NdA%2BJUGYOqppvnoQJLTGQ9%2BA916vuMb0g9dig%40mail.gmail.com%3E

I'm also aware of a third-party diagnostic module that could use a hint,
and in general I wonder if anyone knows of specific interface requirements
that would need to be provided by a new hook for indicating when a
connection or request leaves the original thread or is handled by a new one.
-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1543033 - /apr/apr/trunk/network_io/unix/socket_util.c

[Jeff Trawick]

On Mon, Nov 18, 2013 at 9:47 AM, Jim Jagielski  wrote:

>
> On Nov 18, 2013, at 9:36 AM, Jeff Trawick  wrote:
> > and since we have a useful testcase then maybe it is worth abandoning
> the #else path...  but YMMV :)
>
> +1 from me :)


okay, it will be on me :)

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1543033 - /apr/apr/trunk/network_io/unix/socket_util.c

[Jeff Trawick]

On Mon, Nov 18, 2013 at 9:30 AM, Jim Jagielski  wrote:

> The #else part is what's originally in there... afaik, the
> test only fails for OSX because of this issue (rtnevents
> contains both the POLLIN and POLLHUP bits).
>

understood; the original code looks fragile...


>
> This is a long standing OSX issue...


I interpret that as "yes, the testcase failed"...

and since we have a useful testcase then maybe it is worth abandoning the
#else path...  but YMMV :)



> will look to see
> if theres anything in BUGZ
> On Nov 18, 2013, at 9:24 AM, Jeff Trawick  wrote:
>
> > On Mon, Nov 18, 2013 at 9:10 AM,  wrote:
> > Author: jim
> > Date: Mon Nov 18 14:10:58 2013
> > New Revision: 1543033
> >
> > URL: http://svn.apache.org/r1543033
> > Log:
> > OSX (Darwin) returns APR_POLLHUP|APR_POLLIN, so the
> > test for equality fails. Instead, just check for the bit.
> >
> > Modified:
> > apr/apr/trunk/network_io/unix/socket_util.c
> >
> > Modified: apr/apr/trunk/network_io/unix/socket_util.c
> > URL:
> http://svn.apache.org/viewvc/apr/apr/trunk/network_io/unix/socket_util.c?rev=1543033&r1=1543032&r2=1543033&view=diff
> >
> ==
> > --- apr/apr/trunk/network_io/unix/socket_util.c (original)
> > +++ apr/apr/trunk/network_io/unix/socket_util.c Mon Nov 18 14:10:58 2013
> > @@ -46,7 +46,12 @@ APR_DECLARE(apr_status_t) apr_socket_atr
> >  /* Some other error -> unexpected error. */
> >  return rv;
> >  }
> > +#if defined(DARWIN)
> > +/* OSX returns APR_POLLHUP|APR_POLLIN */
> > +else if (nfds == 1 && (pfds[0].rtnevents & APR_POLLIN)  ==
> APR_POLLIN) {
> > +#else
> >  else if (nfds == 1 && pfds[0].rtnevents == APR_POLLIN) {
> > +#endif
> >
> > Trying to read if APR_POLLIN, independent of other flags, seems valid
> for all platforms...
> >
> > BTW, is the testsock testcase failing on OS X, or is this something not
> caught by testsock?
> >
> >
> >  apr_sockaddr_t unused;
> >  apr_size_t len = 1;
> >  char buf;
> >
> >
> >
> >
> >
> > --
> > Born in Roswell... married an alien...
> > http://emptyhammock.com/
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1543033 - /apr/apr/trunk/network_io/unix/socket_util.c

[Jeff Trawick]

On Mon, Nov 18, 2013 at 9:10 AM,  wrote:

> Author: jim
> Date: Mon Nov 18 14:10:58 2013
> New Revision: 1543033
>
> URL: http://svn.apache.org/r1543033
> Log:
> OSX (Darwin) returns APR_POLLHUP|APR_POLLIN, so the
> test for equality fails. Instead, just check for the bit.
>
> Modified:
> apr/apr/trunk/network_io/unix/socket_util.c
>
> Modified: apr/apr/trunk/network_io/unix/socket_util.c
> URL:
> http://svn.apache.org/viewvc/apr/apr/trunk/network_io/unix/socket_util.c?rev=1543033&r1=1543032&r2=1543033&view=diff
>
> ==
> --- apr/apr/trunk/network_io/unix/socket_util.c (original)
> +++ apr/apr/trunk/network_io/unix/socket_util.c Mon Nov 18 14:10:58 2013
> @@ -46,7 +46,12 @@ APR_DECLARE(apr_status_t) apr_socket_atr
>  /* Some other error -> unexpected error. */
>  return rv;
>  }
> +#if defined(DARWIN)
> +/* OSX returns APR_POLLHUP|APR_POLLIN */
> +else if (nfds == 1 && (pfds[0].rtnevents & APR_POLLIN)  ==
> APR_POLLIN) {
> +#else
>  else if (nfds == 1 && pfds[0].rtnevents == APR_POLLIN) {
> +#endif
>

Trying to read if APR_POLLIN, independent of other flags, seems valid for
all platforms...

BTW, is the testsock testcase failing on OS X, or is this something not
caught by testsock?



>  apr_sockaddr_t unused;
>  apr_size_t len = 1;
>  char buf;
>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Apache Portable Runtime 1.5.0 and Apache Portable Runtime Utility 1.5.3 released

[Jeff Trawick]

   The Apache Software Foundation and the Apache Portable Runtime
   Project are proud to announce the General Availability of version
   1.5.0 of the Apache Portable Runtime library and version 1.5.3
   of the Apache Portable Runtime Utility library.

   Additionally, this is notification that the 0.9.x branch of Apache
   Portable Runtime library, Apache Portable Runtime Utility library,
   and the companion APR-iconv library have been retired.  No further
   bug or security fixes will be available for these branches.

   APR 1.5.0 is a feature release.  The primary additions to the API
   are a skiplist implementation and string escaping support.  A number
   of other API additions and bug fixes are also provided.  An
   experimental cmake-based build system for the Windows platform is
   now included.

   See CHANGES-APR-1.5 for more information.  A fix for a regression
   in APR 1.5.0 which affects out of tree builds on Unix is available
   in the patches directory.

   Apache Portable Runtime Utility library 1.5.3 is a bug fix release.
   An experimental cmake-based build system for the Windows platform is
   now included.

   See CHANGES-APR-UTIL-1.5 for more information.

   Version 1.2.1 of the companion APR-iconv library, an alternative
   portable implementation of the 'iconv' library, remains current.

   APR is available for download from:

 http://apr.apache.org/download.cgi

   The mission of the Apache Portable Runtime Project is to create
   and maintain software libraries that provide a predictable and
   consistent interface to underlying platform-specific
   implementations. The primary goal is to provide an API to
   which software developers may code and be assured of predictable
   if not identical behavior regardless of the platform on which
   their software is built, relieving them of the need to code
   special-case conditions to work around or take advantage of
   platform-specific deficiencies or features.

   APR and its companion libraries are implemented entirely in C
   and provide a common programming interface across a wide variety
   of operating system platforms without sacrificing performance.
   Currently supported platforms include:

 UNIX variants
 Windows
 Netware
 Mac OS X
 OS/2

   To give a brief overview, the primary core
   subsystems of APR 1.x include the following:

 Atomic operations
 Dynamic Shared Object loading
 File I/O
 Locks (mutexes, condition variables, etc)
 Memory management (high performance allocators)
 Memory-mapped files
 Multicast Sockets
 Network I/O
 Shared memory
 Thread and Process management
 Various data structures (tables, hashes, priority queues, etc)

   For a more complete list, please refer to the following URLs:

 http://apr.apache.org/docs/apr/modules.html
 http://apr.apache.org/docs/apr-util/modules.html

   Users of APR 0.9 should be aware that migrating to the APR 1.x
   programming interfaces may require some adjustments; APR 1.x is
   neither source nor binary compatible with earlier APR 0.9 releases.
   Users of APR 1.x can expect consistent interfaces and binary backwards
   compatibility throughout the entire APR 1.x release cycle, as defined
   in our versioning rules:

 http://apr.apache.org/versioning.html

   APR is already used extensively by the Apache HTTP Server
   version 2 and the Subversion revision control system, to
   name but a few.  We list all known projects using APR at
   http://apr.apache.org/projects.html -- so please let us know
   if you find our libraries useful in your own projects!

APR binaries

[Jeff Trawick]

See a mirrored directory like http://apache.xfree.com.ar/apr/binaries/ for
the stuff that users normally see.

I'm planning to wipe these out.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [PATCH/RFC] no more 0.9.x releases or patches

[Jeff Trawick]

On Sun, Nov 3, 2013 at 8:09 PM, Jeff Trawick  wrote:

> apr-0.9.x has a few fixes queued up, but I don't see any reason to release
> them since httpd 2.0.x is retired.
>
>
FYI...  Notification of the retirement is in tomorrow's 1.5.0/1.5.3
announcement (in svn).  The changes to the site originally posted to this
thread will be published tomorrow along with other updates related to the
release of 1.5.0/1.5.3.

Re: svn commit: r1541143 - /apr/apr/branches/1.5.x/STATUS

[Jeff Trawick]

On Tue, Nov 12, 2013 at 11:57 AM,  wrote:

> Author: trawick
> Date: Tue Nov 12 16:57:58 2013
> New Revision: 1541143
>
> URL: http://svn.apache.org/r1541143
> Log:
> no showstoppers?
>
> Modified:
> apr/apr/branches/1.5.x/STATUS
>
> Modified: apr/apr/branches/1.5.x/STATUS
> URL:
> http://svn.apache.org/viewvc/apr/apr/branches/1.5.x/STATUS?rev=1541143&r1=1541142&r2=1541143&view=diff
>
> ==
> --- apr/apr/branches/1.5.x/STATUS [utf-8] (original)
> +++ apr/apr/branches/1.5.x/STATUS [utf-8] Tue Nov 12 16:57:58 2013
> @@ -82,12 +82,6 @@ Bundled with httpd:
>
>  RELEASE SHOWSTOPPERS:
>
> -* Verify that new features are:
> -  + documented
> -  + implemented across major platforms (if applicable)
> -  + have at least minimal regression tests in place
>

Yeah, skip list rant :(

Adding this "showstopper" was probably questionable according to
groupthink, but removing it was terrible judgement according to
Jeffthink...  This perhaps unobvious reminder of the practice of
documentation and regression tests didn't gain any visible interest in
resolving the omissions, and the 1.5.0 cycle was going on and on, and I
didn't choose to prioritize resolution of this over other things I might
spend my time on or other issues I might feel the need as RM to nag about,
so I failed.

The seemingly uninteresting acts of writing basic API documentation and
testcases are important opportunities to think about appropriateness of
interfaces and perhaps even notice questions in the code about the
interfaces.  Going forward, I don't think there is any reason for new
features in trunk to remain there any length of time without at least a
rough sketch of documentation and example use in the form of testcases, and
certainly new API features should not be merged to a stable branch without
it.  I don't mean to pretend that every last interface is technically
capable of being tested in the test suite or even that it is appropriate to
require anything testable to be tested, but instead to point out that these
widely accepted goals that are largely met by the existing codebase should
not get a pass on any new features, that we shouldn't be in a position of
providing new features which are barely consumable.



> -
> -* Makefiles for MSVC
>
>  CURRENT VOTES:
>
>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release APR 1.5.0

[Jeff Trawick]

On Sat, Nov 16, 2013 at 11:04 AM, Rainer Jung wrote:

> On 13.11.2013 17:25, Jeff Trawick wrote:
> > Tarballs/zipfiles are at http://apr.apache.org/dev/dist/
> >
> > Shortcut to CHANGES:
> >
> > http://apr.apache.org/dev/dist/CHANGES-APR-1.5
> >
> > autoconf version: 2.69 (same as apr 1.4.8 and apr-util 1.5.2)
> > libtool version: 2.4.2 (same as apr 1.4.8 and apr-util 1.5.2)
> >
> > +/-1
> > [+1] Release APR 1.5.0 as GA
>

Thanks Rainer and everyone else for your test reports and votes.

The vote for APR 1.5.0 passes, and voting is now closed.  I'll summarize
the voting with the commit to the release directory.

Some additional work I hope to handle this weekend is to build and publish
the API docs for APR 1.5.x.

Re: [VOTE] Release APR-util 1.5.3

[Jeff Trawick]

On Sat, Nov 16, 2013 at 11:16 AM, Rainer Jung wrote:

> On 13.11.2013 17:48, Jeff Trawick wrote:
> > Tarballs/zipfiles are at http://apr.apache.org/dev/dist/
> >
> > Shortcut to CHANGES files:
> >
> > http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5
> > <http://apr.apache.org/dev/dist/CHANGES-APR-1.5>
> > http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5
> > <http://apr.apache.org/dev/dist/CHANGES-APR-1.5>.3
> >
> > autoconf version: 2.69 (same as apr 1.4.8/1.5.0 and apr-util 1.5.2)
> > libtool version: 2.4.2 (same as apr 1.4.8/1.5.0 and apr-util 1.5.2)
> >
> > +/-1
> > [+1] Release apr-util 1.5.3 as GA
>

Thanks Rainer and everyone else for your test reports and votes.

The vote for APR-util 1.5.3 passes, and voting is now closed.  I'll
summarize the voting with the commit to the release directory.

Re: [VOTE] Release APR 1.5.0

[Jeff Trawick]

On Wed, Nov 13, 2013 at 11:25 AM, Jeff Trawick  wrote:

> Tarballs/zipfiles are at http://apr.apache.org/dev/dist/
>
> Shortcut to CHANGES:
>
> http://apr.apache.org/dev/dist/CHANGES-APR-1.5
>
> autoconf version: 2.69 (same as apr 1.4.8 and apr-util 1.5.2)
> libtool version: 2.4.2 (same as apr 1.4.8 and apr-util 1.5.2)
>
> +/-1
> [  ] Release APR 1.5.0 as GA
>
> I'll hold the vote open for 72 hours unless something out of the ordinary
> occurs.
>

Start screaming now if you're still testing or know of a regression that
needs to be discussed.  I'll wait a little longer before initiating
mirroring.


>
> Thanks in advance for testing!
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release APR-util 1.5.3

[Jeff Trawick]

On Wed, Nov 13, 2013 at 11:48 AM, Jeff Trawick  wrote:

> Tarballs/zipfiles are at http://apr.apache.org/dev/dist/
>
> Shortcut to CHANGES files:
>
> http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5<http://apr.apache.org/dev/dist/CHANGES-APR-1.5>
> http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5<http://apr.apache.org/dev/dist/CHANGES-APR-1.5>
> .3
>
> autoconf version: 2.69 (same as apr 1.4.8/1.5.0 and apr-util 1.5.2)
> libtool version: 2.4.2 (same as apr 1.4.8/1.5.0 and apr-util 1.5.2)
>
> +/-1
> [  ] Release apr-util 1.5.3 as GA
>
> I'll hold the vote open for 72 hours unless something out of the ordinary
> occurs.
>

Start screaming now if you're still testing or know of a regression that
needs to be discussed.  I'll wait a little longer before initiating
mirroring.



>
> Thanks in advance for testing!
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release APR-util 1.5.3

[Jeff Trawick]

[X] Release apr-util 1.5.3 as GA

My testing notes are in the apr 1.5.0 vote thread.

Re: [VOTE] Release APR 1.5.0

[Jeff Trawick]

[X] Release APR 1.5.0 as GA

(my testing notes elsewhere in this thread)

Re: svn commit: r1541745 - /apr/apr/branches/1.5.x/Makefile.in

[Jeff Trawick]

On Wed, Nov 13, 2013 at 10:41 PM, William A. Rowe Jr.
wrote:

> On Thu, 14 Nov 2013 00:56:58 +0100
> Rainer Jung  wrote:
> >
> > Personally I think people doing out of tree builds are a minority and
> > can cope with a small Makefile patch. Theyshould be OK with it already
> > being fixed for the next release, so for me it wouldn't be a reason to
> > vote -1.
>
> Nor would I, although all of my builds are out of tree, not one isn't
> patched to cure some ail.  So I would work around it, like Ranier, but
> it might be good if all of our builds run out-of-the-box, in parallel.
>
> I'm thinking mostly of 32 vs. 64 bit builds by any casual consumer.
>
> I'll post a patch and mention it in the announcement.

I'm a bit aggravated because I did try an out-of-tree build when I was
trying to get gen_test_char building properly, but out-of-tree is not my
habit on Unix so there was a very small window within a series of changes
for me to catch it.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1541745 - /apr/apr/branches/1.5.x/Makefile.in

[Jeff Trawick]

On Wed, Nov 13, 2013 at 4:51 PM,  wrote:

> Author: rjung
> Date: Wed Nov 13 21:51:02 2013
> New Revision: 1541745
>
> URL: http://svn.apache.org/r1541745
> Log:
> Support out of tree build for traditional make.
>

I guess traditional is any non-GNU make?

This is a regression.

I don't mind another T&R tomorrow if people think it is warranted.


> Backport of r1541744 from trunk plus additional
> include path item already present in trunk.
>
> Modified:
> apr/apr/branches/1.5.x/Makefile.in
>
> Modified: apr/apr/branches/1.5.x/Makefile.in
> URL:
> http://svn.apache.org/viewvc/apr/apr/branches/1.5.x/Makefile.in?rev=1541745&r1=1541744&r2=1541745&view=diff
>
> ==
> --- apr/apr/branches/1.5.x/Makefile.in (original)
> +++ apr/apr/branches/1.5.x/Makefile.in Wed Nov 13 21:51:02 2013
> @@ -18,7 +18,7 @@ APR_MAJOR_VERSION=@APR_MAJOR_VERSION@
>  INCDIR=./include
>  OSDIR=$(top_srcdir)/include/arch/@OSDIR@
>  DEFOSDIR=$(INCDIR)/arch/@DEFAULT_OSDIR@
> -INCLUDES=-I$(INCDIR) -I$(OSDIR) -I$(DEFOSDIR)
> -I$(top_srcdir)/include/arch/@DEFAULT_OSDIR@ -I$(top_srcdir)/include
> -I$(top_srcdir)/include/private
> +INCLUDES=-I$(INCDIR) -I$(OSDIR) -I$(DEFOSDIR)
> -I$(top_srcdir)/include/arch/@DEFAULT_OSDIR@ -I$(top_srcdir)/include
> -I$(top_srcdir)/include/private -I$(top_blddir)/include/private
>
>  #
>  # Macros for target determination
> @@ -134,6 +134,7 @@ tools/gen_test_char@EXEEXT@: $(OBJECTS_g
> $(LINK_PROG) $(OBJECTS_gen_test_char) $(ALL_LIBS)
>
>  include/private/apr_escape_test_char.h: tools/gen_test_char@EXEEXT@
> +   $(APR_MKDIR) include/private
> tools/gen_test_char@EXEEXT@ > $@
>
>  LINK_PROG = $(LIBTOOL) $(LTFLAGS) --mode=link $(COMPILE) $(LT_LDFLAGS) \
>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release APR 1.5.0

[Jeff Trawick]

On Wed, Nov 13, 2013 at 11:25 AM, Jeff Trawick  wrote:

> Tarballs/zipfiles are at http://apr.apache.org/dev/dist/
>
>
Looking good so far...

FreeBSD 9: gcc, 64-bit builds of apr 1.5.0 and apr-util 1.5.3 fine, only
ran their test suites

RHEL 5-ish box: gcc, 64-bit builds of httpd 2.4.6 with proposed releases;
apr/apr-util and httpd test suites fine, various functional tests fine

Win2008 R2: VS2012, 64-bit builds of httpd 2.4.6 with proposed releases;
apr/apr-util test suites fine, various functional tests fine (cmake build
system)

Windows 7: VS2012, 64-bit builds of proposed releases fine, only ran their
test suites (cmake build system)

I'll probably vote +1 to both based just on this testing, unless someone
finds cause for further testing or investigation.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release APR-util 1.5.3

[Jeff Trawick]

On Wed, Nov 13, 2013 at 3:45 PM, Gregg Smith  wrote:

> On 11/13/2013 8:48 AM, Jeff Trawick wrote:
>
>> Tarballs/zipfiles are at http://apr.apache.org/dev/dist/
>>
>> Shortcut to CHANGES files:
>>
>> http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5 <
>> http://apr.apache.org/dev/dist/CHANGES-APR-1.5>
>> http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5 <
>> http://apr.apache.org/dev/dist/CHANGES-APR-1.5>.3
>>
>>
>> autoconf version: 2.69 (same as apr 1.4.8/1.5.0 and apr-util 1.5.2)
>> libtool version: 2.4.2 (same as apr 1.4.8/1.5.0 and apr-util 1.5.2)
>>
>> +/-1
>> [  ] Release apr-util 1.5.3 as GA
>>
>> I'll hold the vote open for 72 hours unless something out of the ordinary
>> occurs.
>>
>> Thanks in advance for testing!
>>
>> --
>> Born in Roswell... married an alien...
>> http://emptyhammock.com/
>>
> non-binding +1
>
> testutillib had a unresolved sybols problem, fixed post-tag in r1541697,
> not a show stopper IMO since I'm not sure anyone ever tests on Windows,
> just build & run with it.
>

this isn't a regression, is it?  (I see only trivial changes in
apr-util-1.5.x/test since apr-util-1.5.2 (r1462849)


>
> dll & lib tests pass except for xlate (non-regression).
>
>
>
much appreciated!

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

[VOTE] Release APR-util 1.5.3

[Jeff Trawick]

Tarballs/zipfiles are at http://apr.apache.org/dev/dist/

Shortcut to CHANGES files:

http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5
http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5
.3

autoconf version: 2.69 (same as apr 1.4.8/1.5.0 and apr-util 1.5.2)
libtool version: 2.4.2 (same as apr 1.4.8/1.5.0 and apr-util 1.5.2)

+/-1
[  ] Release apr-util 1.5.3 as GA

I'll hold the vote open for 72 hours unless something out of the ordinary
occurs.

Thanks in advance for testing!

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

[VOTE] Release APR 1.5.0

[Jeff Trawick]

Tarballs/zipfiles are at http://apr.apache.org/dev/dist/

Shortcut to CHANGES:

http://apr.apache.org/dev/dist/CHANGES-APR-1.5

autoconf version: 2.69 (same as apr 1.4.8 and apr-util 1.5.2)
libtool version: 2.4.2 (same as apr 1.4.8 and apr-util 1.5.2)

+/-1
[  ] Release APR 1.5.0 as GA

I'll hold the vote open for 72 hours unless something out of the ordinary
occurs.

Thanks in advance for testing!

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Timetable for APR 1.5 release?

[Jeff Trawick]

On Wed, Nov 13, 2013 at 6:45 AM, Jeff Trawick  wrote:

> On Wed, Nov 13, 2013 at 3:42 AM, Arfrever Frehtes Taifersar Arahesis <
> arfrever@gmail.com> wrote:
>
>> 2013-11-12 18:02 Jeff Trawick napisał(a):
>> > Are there any known issues?
>>
>> Please fix remaining part of bug #55690 and backport full fix (r1535027,
>> r1535157, rXXX) to 1.5.x branch.
>>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=55690
>
>
> I'm working on that now.  Thanks for the heads-up.
>

Done...  Can you retest from the HEAD of apr 1.5.x?


>
>>
>>
>> --
>> Arfrever Frehtes Taifersar Arahesis
>>
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Timetable for APR 1.5 release?

[Jeff Trawick]

On Wed, Nov 13, 2013 at 3:42 AM, Arfrever Frehtes Taifersar Arahesis <
arfrever@gmail.com> wrote:

> 2013-11-12 18:02 Jeff Trawick napisał(a):
> > Are there any known issues?
>
> Please fix remaining part of bug #55690 and backport full fix (r1535027,
> r1535157, rXXX) to 1.5.x branch.
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=55690


I'm working on that now.  Thanks for the heads-up.


>
>
> --
> Arfrever Frehtes Taifersar Arahesis
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Timetable for APR 1.5 release?

[Jeff Trawick]

On Tue, Oct 1, 2013 at 8:26 AM, Jeff Trawick  wrote:

> On Tue, Oct 1, 2013 at 7:32 AM, Jim Jagielski  wrote:
>
>> Subj sez it all.
>>
>> I've never been RM for APR but am willing to do this one...
>>
>
> I'm happy to take care of the RM work.
>
> Some things I'm interested in checking on for 1.5.x:
>
> * Compare 1.4.x<->1.5.x and see if anything was missed.  (I'm pretty sure
> that there are some .h fixes that skipped 1.5.x; dunno what else.)
> * Add the cmake support.  (I purposefully skipped the 1.5.x branch when
> there was constant activity.)
> * Put in a couple of fixes for Cygwin that somebody opened bugs for in the
> last week or so.
> * Test MinGW static and shared builds in conjunction with APR-util 1.5.x.
>  (Should be okay; some fixes for shared never hit the 1.4.x branch, so it
> would be good to ensure this is finally working.)
> * Check for anything whatsoever that could be merged from trunk and see
> what to do, as presumably there won't be another opportunity for a while.
>
> It would be good for T&R to be no sooner than next Monday.
>

Wow, that was a long time ago.

I suspect that we're ready.  I'd love to  write some [at least skeletal]
docs and testcases for skiplist but I don't have time, and I suppose that
adding another test*.c file is asking for trouble on one platform or
another.

Are there any known issues?  I'll try hard to T&R apr and apr-util tomorrow
otherwise, or help then with any identified issues.


>
> Any other thoughts on what to look at before T&R of the first 1.5.x
> release?
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

[RFC] additional apr_getnameinfo error checking

[Jeff Trawick]

Index: network_io/unix/sockaddr.c
===
--- network_io/unix/sockaddr.c (revision 1541061)
+++ network_io/unix/sockaddr.c (working copy)
@@ -672,6 +672,10 @@ APR_DECLARE(apr_status_t) apr_getnameinfo(char **h
 char tmphostname[256];
 #endif

+if (apr_sockaddr_is_wildcard(sockaddr)) {
+return APR_EINVAL;
+}
+
 /* don't know if it is portable for getnameinfo() to set h_errno;
  * clear it then see if it was set */
 SET_H_ERRNO(0);
@@ -747,6 +751,10 @@ APR_DECLARE(apr_status_t) apr_getnameinfo(char **h
 int hosterror;
 struct hostent hs, *hptr;

+if (apr_sockaddr_is_wildcard(sockaddr)) {
+return APR_EINVAL;
+}
+
 #if defined(GETHOSTBYNAME_R_HOSTENT_DATA)
 /* AIX, HP/UX, D/UX et alia */
 gethostbyaddr_r((char *)&sockaddr->sa.sin.sin_addr,

It seems sort of silly until you debug an app that shows different
representations of a sockaddr on different platforms, because

Linux: getnameinfo(INADDR_ANY) does DNS lookup then fails with not-found*
FreeBSD: getnameinfo(INADDR_ANY) fails immediately with not-found-or-no-arg*
Windows: getnameinfo(INADDR_ANY) succeeds, then returns the hostname of the
system

*didn't capture resolver error codes :(

Of course an app that is discovered to be getting bit is easy to fix with a
call to apr_sockaddr_is_wildcard() or local equivalent, and maybe some app
depends on the current behavior anyway.

Does anyone care either way?

--
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: testdup test fails when compiled in debug mode on Windows

[Jeff Trawick]

On Thu, Nov 7, 2013 at 11:20 AM, William A. Rowe Jr. wrote:

> On Thu, 7 Nov 2013 09:43:07 -0500
> Jeff Trawick  wrote:
>
> > On Thu, Nov 7, 2013 at 12:33 AM, William A. Rowe Jr.
> > wrote:
> >
> > > On Wed, 06 Nov 2013 16:07:37 -0800
> > > Mike Rumph  wrote:
> > >
> > > >
> > > > On 11/6/2013 1:06 PM, Jeff Trawick wrote:
> > > > >
> > > > > I just played with _commit() on stdin a bit.  It turns out that
> > > > > _commit(0) fails if stdin is redirected (main.exe < somefile)
> > > > > but works if stdin is a tty.  That's the opposite of _commit(1
> > > > > or 2). But I don't see how _commit(0) makes sense anyway, so I
> > > > > simply removed the call instead of reversing the corresponding
> > > > > _isatty() check in your patch.
> > > > >
> > > > > trunk: r1539455
> > > > > 1.5.x branch: r1539461
> > > > Okay Jeff,
> > > >
> > > > I just tried both stdout and stdin, and got the same results that
> > > > you did. Strange but true.
> > >
> > > IIRC the choice to _commit ahead of any handling of stdin/out/err
> > > reflected the possibility that bytes were queued/stuck in the FILE
> > > or the msvcrt 'fd' (not really an fd at all) before assuming
> > > ownership of the file handle.  It might have been an overreaction
> > > to a problem that wouldn't exist in practice.  But I'd prefer if
> > > this were left context sensitive to _DEBUG mode builds.
> > >
> >
> > "The *_commit* function forces the operating system to write the file
> > associated with *handle* to disk"
> >
> > _commit(fileno_stdout or fileno_stderr) fails if it refers to the
> > terminal whether or not it is a debug build.  It simply isn't a valid
> > call.  I called out the debug build issue in CHANGES because that is
> > likely the only case where anyone would encounter a problem symptom.
> > (_commit() otherwise continues to return -1/EBADF and nobody notices.)
> >
> > The fileno_stdin issue is even more odd as it took an opposite sense
> > of _isatty(fileno_stdin) to keep it from reporting an error, but I
> > don't see any connection between _commit() and stdin so it seemed
> > most appropriate to simply remove the call for stdin.
> >
> > IOW, I don't see the need to tie this to debug builds because the
> > calls are invalid whether or not the RTL pops up the dialog.
>
> In that case I can see the benefit to dropping the call entirely.
>

Maybe we've lost communication here...  The calls that are invalid are,
essentially, _commit(console), which we've filtered out via a check to
_isatty().  _commit(file) still makes sense AFAIK and still is used.


>
> On Thu, 07 Nov 2013 07:09:18 -0800
> Mike Rumph  wrote:
>
> > Do you remember if the reasons for using _commit() would distinguish
> > between input and output?
>
> No, not offhand.  In any case, they were in inverted order to clean up
> any lingering input ahead of dup'ing or creating an apr file_t from an
> apr_os_file_t.
>
> Let's axe it.
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: testdup test fails when compiled in debug mode on Windows

[Jeff Trawick]

On Thu, Nov 7, 2013 at 12:33 AM, William A. Rowe Jr. wrote:

> On Wed, 06 Nov 2013 16:07:37 -0800
> Mike Rumph  wrote:
>
> >
> > On 11/6/2013 1:06 PM, Jeff Trawick wrote:
> > >
> > > I just played with _commit() on stdin a bit.  It turns out that
> > > _commit(0) fails if stdin is redirected (main.exe < somefile) but
> > > works if stdin is a tty.  That's the opposite of _commit(1 or 2).
> > > But I don't see how _commit(0) makes sense anyway, so I simply
> > > removed the call instead of reversing the corresponding _isatty()
> > > check in your patch.
> > >
> > > trunk: r1539455
> > > 1.5.x branch: r1539461
> > Okay Jeff,
> >
> > I just tried both stdout and stdin, and got the same results that you
> > did. Strange but true.
>
> IIRC the choice to _commit ahead of any handling of stdin/out/err
> reflected the possibility that bytes were queued/stuck in the FILE or
> the msvcrt 'fd' (not really an fd at all) before assuming ownership of
> the file handle.  It might have been an overreaction to a problem that
> wouldn't exist in practice.  But I'd prefer if this were left context
> sensitive to _DEBUG mode builds.
>

"The *_commit* function forces the operating system to write the file
associated with *handle* to disk"

_commit(fileno_stdout or fileno_stderr) fails if it refers to the terminal
whether or not it is a debug build.  It simply isn't a valid call.  I
called out the debug build issue in CHANGES because that is likely the only
case where anyone would encounter a problem symptom.  (_commit() otherwise
continues to return -1/EBADF and nobody notices.)

The fileno_stdin issue is even more odd as it took an opposite sense of
_isatty(fileno_stdin) to keep it from reporting an error, but I don't see
any connection between _commit() and stdin so it seemed most appropriate to
simply remove the call for stdin.

IOW, I don't see the need to tie this to debug builds because the calls are
invalid whether or not the RTL pops up the dialog.


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Link errors in apr_atomic with VS2013

[Jeff Trawick]

On Thu, Nov 7, 2013 at 12:29 AM, William A. Rowe Jr. wrote:

> On Tue, 5 Nov 2013 17:49:22 -0800 (PST)
> Arsen Chaloyan  wrote:
> >
> > These errors are caused by the use of the new Platform Toolset v120
> > which gets installed with VS2013. More specifically, the problem is
> > in the function cast wrappers defined in apr_atomic.c and used only
> > for Win32 (x86) platform. Taking out the function casts helps resolve
> > the link errors with a penalty of having warning messages instead.
>
> Each time I've seen such issues, there is some -Define flag to
> circumvent the silly MSVC design team's choices.  Please look into
> the headers to see if there is a more straightforward workaround to
> revert to the 'classic' behavior first.
>

Also, they probably have a support forum for early VS2013 adopters.  They
might be able to provide the right solution to work across releases.  (With
no more warnings; there are enough of those already to make it tedious to
spot when new ones arrive.)

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Which of y'all are working on un-APR-izing gen_test_char, and how will the rest of us know if it is stalled and needs help?

[Jeff Trawick]

On Thu, Nov 7, 2013 at 12:27 AM, William A. Rowe Jr. wrote:

> On Wed, 06 Nov 2013 02:20:00 +0100
> Guenter Knauf  wrote:
>
> > Hi,
> > On 05.11.2013 22:51, Graham Leggett wrote:
> > > On 05 Nov 2013, at 11:04 PM, Jeff Trawick  wrote:
> > >
> > >> TIA! (ping)
> > >>
> > >> If nobody in the gen_test_char-with-traditional-Windows-build
> > >> sub-thread knows what I'm talking about, please let me know.
> > >> Maybe I am confusedabout the planned work.
> > >
> > > (Am on holiday and travelling, so have limited time, but this was
> > > reasonably straightforward)
> > >
> > > This patch removes the APR specific stuff (and therefore the
> > > chicken-and-egg problem) and Works for Me(™) on MacOSX 10.8. Is
> > > this good enough to work on Windows and other platforms (Linux,
> > > etc)?
> > I would prefer to keep the unsigned char casts ...
>
> If the iterator is an unsigned int the promotion should be identical in
> behavior according to K&R v2, the oldest reference I can find.
>


Graham's patch is now in trunk and 1.5.x.  I guess that's what Gregg
tested.  It works for me on Linux and with the cmake-based build on Windows.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: testdup test fails when compiled in debug mode on Windows

[Jeff Trawick]

On Wed, Nov 6, 2013 at 2:13 PM, Jeff Trawick  wrote:

> On Wed, Nov 6, 2013 at 2:06 PM, Mike Rumph  wrote:
>
>> The apr_file_dup2() function in apr/file_io/win32/filedup.c calls
>> _commit() for standard file handles 0, 1 and 2.
>> The _commit() function will assert with the message "Invalid file
>> descriptor. File possibly closed by a different thread" or return a value
>> of -1 if the file handle refers to a device.
>> The assert will appear if APR is compiled in debug mode.
>>
>> This can be seen by running "testall.exe testdup".
>> But if file redirection is used (such as "testall.exe testdup > outfile
>> 2>&1"), then the test completes successfully.
>>
>> I have attached a patch that corrects this problem by checking _isatty().
>>
>> Credit goes to Jeff Trawick for catching this problem in the first place.
>>
>
> Well, there's a lot of unhappiness when you have to answer the
> abort/retry/ignore dialog when you run httpd with a debug flavor of apr ;)
>
>
>> Thanks,
>>
>> Mike Rumph
>>
>
> The existing flush-stdin path sure looks funny now that it is highlighted
> by the format of the patch, but that's not related to this bug and google
> seems to think that it is acceptable on Windows.
>
> I hope to commit shortly.  Thanks!
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>

I just played with _commit() on stdin a bit.  It turns out that _commit(0)
fails if stdin is redirected (main.exe < somefile) but works if stdin is a
tty.  That's the opposite of _commit(1 or 2).  But I don't see how
_commit(0) makes sense anyway, so I simply removed the call instead of
reversing the corresponding _isatty() check in your patch.

trunk: r1539455
1.5.x branch: r1539461

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: testdup test fails when compiled in debug mode on Windows

[Jeff Trawick]

On Wed, Nov 6, 2013 at 2:06 PM, Mike Rumph  wrote:

> The apr_file_dup2() function in apr/file_io/win32/filedup.c calls
> _commit() for standard file handles 0, 1 and 2.
> The _commit() function will assert with the message "Invalid file
> descriptor. File possibly closed by a different thread" or return a value
> of -1 if the file handle refers to a device.
> The assert will appear if APR is compiled in debug mode.
>
> This can be seen by running "testall.exe testdup".
> But if file redirection is used (such as "testall.exe testdup > outfile
> 2>&1"), then the test completes successfully.
>
> I have attached a patch that corrects this problem by checking _isatty().
>
> Credit goes to Jeff Trawick for catching this problem in the first place.
>

Well, there's a lot of unhappiness when you have to answer the
abort/retry/ignore dialog when you run httpd with a debug flavor of apr ;)


> Thanks,
>
> Mike Rumph
>

The existing flush-stdin path sure looks funny now that it is highlighted
by the format of the patch, but that's not related to this bug and google
seems to think that it is acceptable on Windows.

I hope to commit shortly.  Thanks!

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Which of y'all are working on un-APR-izing gen_test_char, and how will the rest of us know if it is stalled and needs help?

[Jeff Trawick]

On Fri, Nov 1, 2013 at 10:05 AM, Jeff Trawick  wrote:

> TIA!
>

TIA! (ping)

If nobody in the gen_test_char-with-traditional-Windows-build sub-thread
knows what I'm talking about, please let me know.  Maybe I am confused
about the planned work.


>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [PATCH/RFC] no more 0.9.x releases or patches

[Jeff Trawick]

On Sun, Nov 3, 2013 at 8:43 PM, Eric Covener  wrote:

> On Sun, Nov 3, 2013 at 8:09 PM, Jeff Trawick  wrote:
> > apr-0.9.x has a few fixes queued up, but I don't see any reason to
> release
> > them since httpd 2.0.x is retired.
>
> +1
>

Not much concern here ;)  I can't evaluate any consumers besides httpd 2.0.
 I'll make the site update soon-ish and see what wording to tweak on the
download page.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

[PATCH/RFC] no more 0.9.x releases or patches

[Jeff Trawick]

apr-0.9.x has a few fixes queued up, but I don't see any reason to release
them since httpd 2.0.x is retired.

Index: xdocs/index.xml
===
--- xdocs/index.xml (revision 1538482)
+++ xdocs/index.xml (working copy)
@@ -29,15 +29,6 @@
   APR-iconv 1.2.1, released November 26, 2007
 

-The current legacy releases in support of older applications such
-as Apache HTTP Server 2.0.x are
-
-
-  APR 0.9.20, released September 16, 2011
-  APR-util 0.9.19, released October 17, 2010
-  APR-iconv 0.9.7, released October 11, 2005
-
-
 

 
@@ -95,24 +86,21 @@
 

 
-Apache Portable Runtime 0.9.20
+Legacy 0.9.x Releases

-The Apache Software Foundation and the Apache Portable Runtime
-Project are proud to announce the General Availability of
-version 0.9.20 of the APR Apache Portable Runtime library.
+Legacy releases in support of older applications such
+as Apache HTTP Server 2.0.x are

-The corresponding version 0.9.19 of the companion APR-util
-Apache Portable Utility library and version 0.9.7 of the companion
-APR-iconv library, an alternative portable implementation of the
-'iconv' library, remain current.
+
+  APR 0.9.20, released September 16, 2011
+  APR-util 0.9.19, released October 17, 2010
+  APR-iconv 0.9.7, released October 11, 2005
+

-This version of APR is a security and bug fix release, and is
-provided only for users requiring APR 0.9 compatibility.  Most
-developers are encouraged to adopt the latest APR 1.x version
-to ensure the most comprehensive support and access to the latest
-features and enhancements.
+These branches are retired, with no additional 0.9 releases
+planned.  Security patches will not be provided.

-For further details of this legacy release, see the
+For further details of the last legacy releases, see the
 http://www.apache.org/dist/apr/Announcement0.9.html";
  >official announcement, as well as the
 http://www.apache.org/dist/apr/CHANGES-APR-0.9";
>CHANGES-APR-0.9,

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

I'm planning to T&R apr-util 1.5.3 at same time as apr 1.5.0

[Jeff Trawick]

There is a need to consume the cmake support downstream, and I see a few
other fixes as well.

(Please no apr-util 1.6 and corresponding rush to cram a bunch of stuff in
there like I and others did with apr 1.5 ;)  That can wait.)

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

shouldn't APR_FOPEN_NONBLOCK trigger APR_ENOTIMPL where not supported?

[Jeff Trawick]

It doesn't seem like a hint...


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Which of y'all are working on un-APR-izing gen_test_char, and how will the rest of us know if it is stalled and needs help?

[Jeff Trawick]

TIA!

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1536785 - /apr/apr/branches/1.5.x/include/private/apr_escape_test_char.h

[Jeff Trawick]

On Wed, Oct 30, 2013 at 11:12 AM, William A. Rowe Jr.
wrote:

> On Tue, 29 Oct 2013 14:17:24 -0400
> Jeff Trawick  wrote:
>
> > On Tue, Oct 29, 2013 at 12:08 PM,  wrote:
> >
> > > Author: wrowe
> > > Date: Tue Oct 29 16:08:31 2013
> > > New Revision: 1536785
> > >
> > > URL: http://svn.apache.org/r1536785
> > > Log:
> > > Remove generated file from branches/1.5.x, as it is not present in
> > > trunk
> > >
> > >
> > the entire revision is needed; I thought somebody else might have
> > time to play in trunk, but I'll merge it now
>
> Saw the commit, thanks!
>
> Gregg, Guenter, Stephan and I are all in favor of dropping inclusion
> of any apr.h includes from gen_test_char.c source, and relying on
> standard C.  This 1.5.0 release seems like a good a time as any for
> that transition (and the build is simplified).  What are your thoughts?
>
>
If it works for gen_test_char it works for me...  T&R is not imminent...

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1536785 - /apr/apr/branches/1.5.x/include/private/apr_escape_test_char.h

[Jeff Trawick]

On Tue, Oct 29, 2013 at 12:08 PM,  wrote:

> Author: wrowe
> Date: Tue Oct 29 16:08:31 2013
> New Revision: 1536785
>
> URL: http://svn.apache.org/r1536785
> Log:
> Remove generated file from branches/1.5.x, as it is not present in trunk
>
>
the entire revision is needed; I thought somebody else might have time to
play in trunk, but I'll merge it now




> Removed:
> apr/apr/branches/1.5.x/include/private/apr_escape_test_char.h
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: gen_test_char build needs some help in the autoconf-based build

[Jeff Trawick]

On Tue, Oct 29, 2013 at 9:33 AM, Jeff Trawick  wrote:

> On Tue, Oct 29, 2013 at 7:44 AM, Jeff Trawick  wrote:
>
>> On Tue, Oct 29, 2013 at 12:22 AM, William A. Rowe Jr. 
>> wrote:
>>
>>> No... the entire dependency is on excluding it from svn.  Please
>>> remember that default timestamps in svn are worthless and whatever you
>>> checked in is platform specific.
>>>  On Oct 28, 2013 7:02 PM, "Jeff Trawick"  wrote:
>>>
>>>> On Mon, Oct 28, 2013 at 7:51 PM, Graham Leggett wrote:
>>>>
>>>>> On 28 Oct 2013, at 11:01 PM, Jeff Trawick  wrote:
>>>>>
>>>>> > apr trunk on Unix:
>>>>> >
>>>>> > It gets built then run only after all .o files are generated, so it
>>>>> doesn't have the expected impact.
>>>>> >
>>>>> > .o/.lo/.libs (for gen_test_char) in tools don't get cleaned, so you
>>>>> may just see the link invocation when you think you're building from
>>>>> scratch.
>>>>>
>>>>> What happens if you delete include/private/apr_escape_test_char.h
>>>>> before starting the build? Right now the file is checked in, but given 
>>>>> that
>>>>> Windows builds produce different output to Unix builds we may be forced to
>>>>> rebuild this header each time from scratch.
>>>>>
>>>>> Regards,
>>>>> Graham
>>>>> --
>>>>>
>>>>>
>>>> The build bombs if apr_escape_test_char.h is first removed.  I guess
>>>> there's no dependency on generating it first.
>>>>
>>>> --
>>>> Born in Roswell... married an alien...
>>>> http://emptyhammock.com/
>>>>
>>>
>> 1st pass:
>>
>> remove .h from svn, get it ignored, add this small patch:
>>
>> Index: Makefile.in
>> ===
>> --- Makefile.in (revision 1536672)
>> +++ Makefile.in (working copy)
>> @@ -123,6 +123,8 @@
>>  $(TARGET_LIB): $(OBJECTS) $(EXTRA_OBJECTS)
>> $(LINK) @lib_target@ $(EXTRA_OBJECTS) $(ALL_LIBS)
>> $(APRUTIL_EXPORT_LIBS)
>>
>> +$(OBJECTS): include/private/apr_escape_test_char.h
>> +
>>  install-modules: install-modules-@APR_HAVE_MODULES@
>>
>>  install-modules-no:
>>
>>
> Another fix is to get it cleaned:
>
>  CLEAN_TARGETS = apr-config.out apr.exp exports.c export_vars.c .make.dirs
> \
> - build/apr_rules.out tools/gen_test_char@EXEEXT@
> + build/apr_rules.out tools/gen_test_char@EXEEXT@ \
> + include/private/apr_escape_test_char.h
>
>
>> --/--
>>
>> But perhaps this doesn't do the right thing with out of tree builds (not
>> tested there).
>>
>
> gen_test_cahr fails with out of tree builds independent of this ordering
> issue.  The first failure noticed is that the tools directory doesn't get
> created in the build tree.  (Otherwise the build tree mimics the source
> tree structure.)
>
>
r1536744 seems to work; hopefully others can try in their workflow and
validate that it cleans what should be cleaned and [re]builds at the right
time

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: gen_test_char build needs some help in the autoconf-based build

[Jeff Trawick]

On Tue, Oct 29, 2013 at 7:44 AM, Jeff Trawick  wrote:

> On Tue, Oct 29, 2013 at 12:22 AM, William A. Rowe Jr. wrote:
>
>> No... the entire dependency is on excluding it from svn.  Please remember
>> that default timestamps in svn are worthless and whatever you checked in is
>> platform specific.
>>  On Oct 28, 2013 7:02 PM, "Jeff Trawick"  wrote:
>>
>>> On Mon, Oct 28, 2013 at 7:51 PM, Graham Leggett wrote:
>>>
>>>> On 28 Oct 2013, at 11:01 PM, Jeff Trawick  wrote:
>>>>
>>>> > apr trunk on Unix:
>>>> >
>>>> > It gets built then run only after all .o files are generated, so it
>>>> doesn't have the expected impact.
>>>> >
>>>> > .o/.lo/.libs (for gen_test_char) in tools don't get cleaned, so you
>>>> may just see the link invocation when you think you're building from
>>>> scratch.
>>>>
>>>> What happens if you delete include/private/apr_escape_test_char.h
>>>> before starting the build? Right now the file is checked in, but given that
>>>> Windows builds produce different output to Unix builds we may be forced to
>>>> rebuild this header each time from scratch.
>>>>
>>>> Regards,
>>>> Graham
>>>> --
>>>>
>>>>
>>> The build bombs if apr_escape_test_char.h is first removed.  I guess
>>> there's no dependency on generating it first.
>>>
>>> --
>>> Born in Roswell... married an alien...
>>> http://emptyhammock.com/
>>>
>>
> 1st pass:
>
> remove .h from svn, get it ignored, add this small patch:
>
> Index: Makefile.in
> ===
> --- Makefile.in (revision 1536672)
> +++ Makefile.in (working copy)
> @@ -123,6 +123,8 @@
>  $(TARGET_LIB): $(OBJECTS) $(EXTRA_OBJECTS)
> $(LINK) @lib_target@ $(EXTRA_OBJECTS) $(ALL_LIBS)
> $(APRUTIL_EXPORT_LIBS)
>
> +$(OBJECTS): include/private/apr_escape_test_char.h
> +
>  install-modules: install-modules-@APR_HAVE_MODULES@
>
>  install-modules-no:
>
>
Another fix is to get it cleaned:

 CLEAN_TARGETS = apr-config.out apr.exp exports.c export_vars.c .make.dirs \
- build/apr_rules.out tools/gen_test_char@EXEEXT@
+ build/apr_rules.out tools/gen_test_char@EXEEXT@ \
+ include/private/apr_escape_test_char.h


> --/--
>
> But perhaps this doesn't do the right thing with out of tree builds (not
> tested there).
>

gen_test_cahr fails with out of tree builds independent of this ordering
issue.  The first failure noticed is that the tools directory doesn't get
created in the build tree.  (Otherwise the build tree mimics the source
tree structure.)



>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Any thoughts on appropriate use of Windows VERSIONINFO for bundled ASF projects?

[Jeff Trawick]

I'd like to see how to tweak the .rc files/build to make it easy to
identify the files properly -- what is the underlying open source
project/version, where did you get them.  IOW, route the credit and
liability to the appropriate, different places.  That's a good thing for
everybody.

E.g., bundler uses

CompanyName=Internet Widgits Pty Ltd
ProductName=WidgetStack
ProductVersion=1.0.3
ProductVersionNumber=1.0.3.0

and leaves the rest alone

e.g.,

FileVersion=2.4.6
FileVersionNumber=2.4.6.0
FileDescription=Apache HTTP Server Core

or

FileVersion=1.5.2
FileVersionNumber=1.5.2.0
FileDescription=Apache Portable Runtime Utility Library

LegalCopyright and Comments such as "Licensed under the Apache License..."
are also interesting; IANAL ;)

A bundler may want the comments to have a statement clarifying that the
file is a component of &product;, originally obtained from &ossproject; and
possibly including fixes and enhancements not originally in that oss
version, and supported through &product; support channels.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: gen_test_char build needs some help in the autoconf-based build

[Jeff Trawick]

On Tue, Oct 29, 2013 at 12:22 AM, William A. Rowe Jr. wrote:

> No... the entire dependency is on excluding it from svn.  Please remember
> that default timestamps in svn are worthless and whatever you checked in is
> platform specific.
> On Oct 28, 2013 7:02 PM, "Jeff Trawick"  wrote:
>
>> On Mon, Oct 28, 2013 at 7:51 PM, Graham Leggett  wrote:
>>
>>> On 28 Oct 2013, at 11:01 PM, Jeff Trawick  wrote:
>>>
>>> > apr trunk on Unix:
>>> >
>>> > It gets built then run only after all .o files are generated, so it
>>> doesn't have the expected impact.
>>> >
>>> > .o/.lo/.libs (for gen_test_char) in tools don't get cleaned, so you
>>> may just see the link invocation when you think you're building from
>>> scratch.
>>>
>>> What happens if you delete include/private/apr_escape_test_char.h before
>>> starting the build? Right now the file is checked in, but given that
>>> Windows builds produce different output to Unix builds we may be forced to
>>> rebuild this header each time from scratch.
>>>
>>> Regards,
>>> Graham
>>> --
>>>
>>>
>> The build bombs if apr_escape_test_char.h is first removed.  I guess
>> there's no dependency on generating it first.
>>
>> --
>> Born in Roswell... married an alien...
>> http://emptyhammock.com/
>>
>
1st pass:

remove .h from svn, get it ignored, add this small patch:

Index: Makefile.in
===
--- Makefile.in (revision 1536672)
+++ Makefile.in (working copy)
@@ -123,6 +123,8 @@
 $(TARGET_LIB): $(OBJECTS) $(EXTRA_OBJECTS)
$(LINK) @lib_target@ $(EXTRA_OBJECTS) $(ALL_LIBS)
$(APRUTIL_EXPORT_LIBS)

+$(OBJECTS): include/private/apr_escape_test_char.h
+
 install-modules: install-modules-@APR_HAVE_MODULES@

 install-modules-no:

--/--

But perhaps this doesn't do the right thing with out of tree builds (not
tested there).

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Timetable for APR 1.5 release?

[Jeff Trawick]

On Tue, Oct 29, 2013 at 5:21 AM, Michael Felt  wrote:

> Just to verify what I should be testing - and - is it too late to get
> something added for packaging?
>
> I assume that for httpd-2.4.X that should build with only apr-1.5.X
> (preferred), or with apr-1.4.some-minimum + apr-util-1.5.X
>

httpd 2.4.next will require apr-1.5.x only if using the event MPM (I doubt
that works on AIX anyway).

But many if not most will be using the latest apr and apr-util.


>
> What I would like to add is the buildaix scripts - similar to what I did
> for httpd, or at a minimum, the layout.AIX.
>
> As apr has compiler dependancies (if you change complier you must rebuild
> apr) I would prefer to have the build script that changes the package name
> dependent on the compiler.
>
> A nice start would be the AIX layout.
>
> michael@x054:[/data/prj/apache/apr/apr-1.5.x-save]jsvn diff config.layout
> Index: config.layout
> ===
>

Does this work with apr trunk?  It needs to be committed there first, then
to 1.5.x.


> --- config.layout   (revision 1536612)
> +++ config.layout   (working copy)
> @@ -229,3 +229,26 @@
>  infodir:   ${exec_prefix}/share/info
>  libsuffix:-${APR_MAJOR_VERSION}
>  
> +
> +# AIX layout
> +
> +prefix:/opt
> +exec_prefix:   /opt
> +datadir:   /var/apr
> +localstatedir: /var
> +sysconfdir:${localstatedir}/apr/etc
> +mandir:/usr/share/man
> +bindir:${exec_prefix}/bin
> +sbindir:   ${exec_prefix}/sbin
> +includedir:${exec_prefix}/include
> +libdir:${exec_prefix}/lib
> +libexecdir:${exec_prefix}/libexec
> +errordir:  ${datadir}/error
> +iconsdir:  ${datadir}/icons
> +htdocsdir: ${datadir}/htdocs
> +manualdir: ${datadir}/manual
> +runtimedir:${localstatedir}/run
> +logfiledir:${localstatedir}/logs
> +proxycachedir: ${localstatedir}/proxy
> +installbuilddir: ${localstatedir}/build
> +
>
> Is it necessary to control all of these from the layout?  There are
significantly more settings, generally httpd-specific, than the other
layouts have.

proxycachedir?  That sounds like Apache 1.3 to me.  What uses that?


>
>
>
> On Mon, Oct 28, 2013 at 10:37 PM, William A. Rowe Jr.  > wrote:
>
>> On Mon, 28 Oct 2013 16:58:45 -0400
>> Jeff Trawick  wrote:
>>
>> > On Mon, Oct 28, 2013 at 4:54 PM, William A. Rowe Jr.
>> > wrote:
>> >
>> > > On Mon, 28 Oct 2013 13:01:09 -0400
>> > > Jeff Trawick  wrote:
>> > >
>> > > > On Mon, Oct 28, 2013 at 12:50 PM, Gregg Smith 
>> > > > wrote:
>> > > >
>> > > > > Just a note,
>> > > > >
>> > > > >
>> > > > > On 10/19/2013 10:32 AM, Gregg Smith wrote:
>> > > > >
>> > > > >> On 10/19/2013 7:26 AM, Jeff Trawick wrote:
>> > > > >>
>> > > > >>> On Thu, Oct 17, 2013 at 11:08 PM, Gregg Smith > > > > >>> > wrote:
>> > > > >>>
>> > > > >>> I'd like to first rid the 1.5 traditional Windows build
>> > > > >>> of the Release9x & Debug9x targets. Anyone against this?
>> > > > >>>
>> > > > >>>
>> > > > >>> no concerns here; is there code that can get deleted too?
>> > > > >>>
>> > > > >>
>> > > > >> probably, I would assume so, I haven't ran it down that far
>> > > > >> yet.
>> > > > >>
>> > > > >
>> > > > > I did not do this after all nor do I think I am brave enough to.
>> > > > >
>> > > > > apr_escape, testescape and gen_test_char were added into the
>> > > > > build with r1534053.
>> > > > > .mak/.dep files were added in r1534516.
>> > > > >
>> > > > > We should be ready to go on the Windows side now.
>> > >
>> > > So, given that 1.5 remains compatible with 1.4... but projects which
>> > > build APR themselves will have to adapt to the new gen_test_char or
>> > > we need to make the suggested change, let's just take the httpd
>> > > example.
>> > >
>> > > Does it make more sense for httpd 2.2 Makefile.win to detect the
>> > > presence of gen_test_char and build it when encountered, or 

Re: gen_test_char build needs some help in the autoconf-based build

[Jeff Trawick]

On Mon, Oct 28, 2013 at 7:51 PM, Graham Leggett  wrote:

> On 28 Oct 2013, at 11:01 PM, Jeff Trawick  wrote:
>
> > apr trunk on Unix:
> >
> > It gets built then run only after all .o files are generated, so it
> doesn't have the expected impact.
> >
> > .o/.lo/.libs (for gen_test_char) in tools don't get cleaned, so you may
> just see the link invocation when you think you're building from scratch.
>
> What happens if you delete include/private/apr_escape_test_char.h before
> starting the build? Right now the file is checked in, but given that
> Windows builds produce different output to Unix builds we may be forced to
> rebuild this header each time from scratch.
>
> Regards,
> Graham
> --
>
>
The build bombs if apr_escape_test_char.h is first removed.  I guess
there's no dependency on generating it first.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

gen_test_char build needs some help in the autoconf-based build

[Jeff Trawick]

apr trunk on Unix:

It gets built then run only after all .o files are generated, so it doesn't
have the expected impact.

.o/.lo/.libs (for gen_test_char) in tools don't get cleaned, so you may
just see the link invocation when you think you're building from scratch.

(I see something else with the apr-1.5.x branch build on MinGW, but I'll
worry about that.)

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Timetable for APR 1.5 release?

[Jeff Trawick]

On Mon, Oct 28, 2013 at 4:54 PM, William A. Rowe Jr. wrote:

> On Mon, 28 Oct 2013 13:01:09 -0400
> Jeff Trawick  wrote:
>
> > On Mon, Oct 28, 2013 at 12:50 PM, Gregg Smith  wrote:
> >
> > > Just a note,
> > >
> > >
> > > On 10/19/2013 10:32 AM, Gregg Smith wrote:
> > >
> > >> On 10/19/2013 7:26 AM, Jeff Trawick wrote:
> > >>
> > >>> On Thu, Oct 17, 2013 at 11:08 PM, Gregg Smith  > >>> > wrote:
> > >>>
> > >>> I'd like to first rid the 1.5 traditional Windows build of the
> > >>> Release9x & Debug9x targets. Anyone against this?
> > >>>
> > >>>
> > >>> no concerns here; is there code that can get deleted too?
> > >>>
> > >>
> > >> probably, I would assume so, I haven't ran it down that far yet.
> > >>
> > >
> > > I did not do this after all nor do I think I am brave enough to.
> > >
> > > apr_escape, testescape and gen_test_char were added into the build
> > > with r1534053.
> > > .mak/.dep files were added in r1534516.
> > >
> > > We should be ready to go on the Windows side now.
>
> So, given that 1.5 remains compatible with 1.4... but projects which
> build APR themselves will have to adapt to the new gen_test_char or
> we need to make the suggested change, let's just take the httpd example.
>
> Does it make more sense for httpd 2.2 Makefile.win to detect the
> presence of gen_test_char and build it when encountered, or does it make
> more sense to compile-link-invoke gen_test_char.c?  I'm happy to make
> the respective change later tonight or tomorrow, based on consensus.
>
>
Is the Windows build interface of apr 1.5.x different such that httpd's
Makefile.win would care?

httpd itself doesn't use apr escape and shouldn't care that apr happens to
have a build utility of the same name as one of its own  (or something is
borked).

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Timetable for APR 1.5 release?

[Jeff Trawick]

On Mon, Oct 28, 2013 at 12:50 PM, Gregg Smith  wrote:

> Just a note,
>
>
> On 10/19/2013 10:32 AM, Gregg Smith wrote:
>
>> On 10/19/2013 7:26 AM, Jeff Trawick wrote:
>>
>>> On Thu, Oct 17, 2013 at 11:08 PM, Gregg Smith >> g...@gknw.net>> wrote:
>>>
>>> I'd like to first rid the 1.5 traditional Windows build of the
>>> Release9x & Debug9x targets. Anyone against this?
>>>
>>>
>>> no concerns here; is there code that can get deleted too?
>>>
>>
>> probably, I would assume so, I haven't ran it down that far yet.
>>
>
> I did not do this after all nor do I think I am brave enough to.
>
> apr_escape, testescape and gen_test_char were added into the build with
> r1534053.
> .mak/.dep files were added in r1534516.
>
> We should be ready to go on the Windows side now.
>

Thanks a bunch.

I found a MinGW build failure this a.m. which I'll fix in the next day or
so.  Other than that, I don't know what else needs to be solved.  It would
be appropriate to have documentation and at least a minimal testcase for
skiplist, but I guess that isn't absolutely necessary.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [PATCH] "Global" vs. "Local" prefix on named mutexes and named shm on Windows

[Jeff Trawick]

On Tue, Oct 22, 2013 at 9:31 PM, William A. Rowe Jr. wrote:

> On Tue, 15 Oct 2013 06:47:35 -0400
> Jeff Trawick  wrote:
>
> > On Tue, Oct 15, 2013 at 1:01 AM, Mladen Turk  wrote:
> > >>
> > > Replacing Global with Local would basically limit the apr_shm API
> > > and it won't
> > > allow IPC using shm across sessions. With services running in
> > > Session0 shm is one
> > > of the effective IPC mechanisms. Using _ex() api and making
> > > _create() and _attach()
> > > as macros should do the trick. Although not sure what should be
> > > default (global or local)
> > > I'd go for backward compatibility (no sudden surprises when changing
> > > version)
> > >
> >
> > Yeah (backward compatibility); specifying APR_SHM_NS_LOCAL or _GLOBAL
> > would bypass the current logic in trunk.  I still like the heuristic
> > that allows non-privileged processes to collaborate via shared memory
> > without adding any platform-specific flags.  The flag would be needed
> > if an app wants to use Local even if the process might be privileged,
> > or an app must use Global to operate (and fail if it is not
> > privileged).
>
> I'm not a fan of causing tests to succeed when they mask a failure.
>
> IIRC the non-anonymous apr_shm code was for sharing data between threads
> and processes.  Moving this to \\Local\ on Win32 hides such flaws, but
> doesn't serve to accomplish the goals of apr_shm, IMHO.
>
> Can you offer a reason to support the \\Local\ shm space on win32?  I'm
> all for functionality, but not to simply pass failing test cases.
>
>
>
There's no technical reason why unprivileged callers can't use
non-anonymous shared memory segments on Windows, just as on Unix.  Some apr
programs (more specifically, some modules for httpd) developed and tested
on Unix assume that you can do so, and I don't see the benefit of chasing
after that for no real benefit other than avoiding an APR limitation.  It
isn't hard at all to conceive of a multi-process application which would
require non-anonymous shared memory segments to operate, with no necessity
(and thus no good reason) to create them in the global namespace,
irrespective of privilege.  And lastly there is testshm, which could be
quieted by other means, though without exercising the non-anonymous path
nearly so often.

--/--

Irrespective of the original thought around non-anonymous, it looks like
the Global NS use was a pragmatic solution for the change in Win2K SPn
which necessarily introduced surprising semantics into this corner of APR,
and while the change worked for some common scenarios it left others in the
dust.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: exclusive file access under Windows (Was Re: svn commit: r1534139 - in /apr/apr/branches/1.5.x: ./ CHANGES file_io/win32/readwrite.c)

[Jeff Trawick]

On Tue, Oct 22, 2013 at 6:04 AM, Stefan Ruppert  wrote:

> Am 21.10.2013 20:39, schrieb Jeff Trawick:
>
>> On Mon, Oct 21, 2013 at 12:41 PM, Stefan Ruppert > <mailto:s...@myarm.com>> wrote:
>>
>>     Am 21.10.2013 16:22, schrieb Jeff Trawick:
>>
>> On Mon, Oct 21, 2013 at 8:57 AM, > <mailto:traw...@apache.org>
>> <mailto:traw...@apache.org <mailto:traw...@apache.org>>> wrote:
>>
>>  Author: trawick
>>  Date: Mon Oct 21 12:57:05 2013
>>  New Revision: 1534139
>>
>>  URL: http://svn.apache.org/r1534139
>>  Log:
>>  Merge r960671 from trunk:
>>
>>  Only deal with the mutex when XTHREAD is enabled. This
>> increases the
>>  performance of buffered reads/writes tremendously.
>>
>>  * file_io/win32/readwrite.c:
>> (apr_file_read, apr_file_write): only manipulate mutex
>> when XTHREAD
>>
>>  Submitted by: Ivan Zhakov > <http://visualsvn.com> <http://visualsvn.com>>
>>
>>
>>
>> Trunk continues to allocate a mutex if buffered, even if the
>> XTHREAD
>> flag is on (a minor detail I suppose).  That presumably is a
>> simple fix
>> after double checking all the references to mutex or buffered in
>> the
>> code used on Windows.  ISTR other concerns about the mutex or
>> XTHREAD,
>> but I think this is an orthogonal issue.
>>
>>
>> Regarding exclusive access to a file under windows I filed a bug in
>> 2010: 
>> https://issues.apache.org/__**bugzilla/show_bug.cgi?id=50058<https://issues.apache.org/__bugzilla/show_bug.cgi?id=50058>
>> 
>> <https://issues.apache.org/**bugzilla/show_bug.cgi?id=50058<https://issues.apache.org/bugzilla/show_bug.cgi?id=50058>
>> **>
>>
>> Using the apr_file_lock()/apr_file___**unlock() under Windows in
>>
>> append mode will deadlock the current thread! In the time of 2010 I
>> just removed the apr_file_lock()/apr_file___**unlock() code within
>> the
>>
>> readwrite.c module. But a better solution is to support nesting
>> within apr_file_lock()/apr_file___**unlock() API calls!
>>
>>
>> Any comments?
>>
>> Stefan
>>
>>
>> I thought it was this simple for append:
>>
>> On Unix a lock isn't needed because the APR implementation there uses
>> O_APPEND, which is atomic (subject to the size of the write I suppose)*;
>> on Windows there's no such feature and APR has to use a lock to make it
>> equivalent.  So the app shouldn't be getting a lock.
>>
>> Is that consistent with what you see?
>>
>
> The problem arise when you want to use the apr_file_lock()/apr_file_**unlock()
> calls to protected multiple calls to apr_file_write():
>
> 1) apr_file_open(FOPEN_APPEND);
> 2) apr_file_lock();
> 3) apr_file_write();
> 4) apr_file_write();
> 5) apr_file_write();
> 6) apr_file_unlock();
> 7) apr_file_close();
>
> Under Unix all works perfect. But under Windows the step 3) call to
> apr_file_write() will deadlock, because the LockFileEx() should not be
> called recursively...
>
> However, in the APR API docs there is nothing said about an atomic write
> within apr_file_write(), thus from my point of view its up to the
> application to make it atomic with the apr_file_lock()/apr_file_**unlock()
> calls. On Unix its a nice side effect that each call to apr_file_write() is
> atomic
>

An alternate interpretation ;)  Access to the O_APPEND semantics is a
critical feature, and the lock on Windows was the best known way to map
that feature.


> The easist way to make it conistent is to support a nesting counter within
> apr_file_lock()/apr_file_**unlock() which will also reflect the APR API
> docs for that calls which are documented to be used recursively!
>

I generally agree, though I think the behavior of apr_file_lock() on Unix
needs examination too so we understand more widely what is broken w.r.t.
the documentation.  I guess testflock.c would be modified to verify that
part of the documentation and then tested on a couple of Unix variations
using the alternate low-level implementations.


>
> Regards,
> Stefan
>
>
-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: exclusive file access under Windows (Was Re: svn commit: r1534139 - in /apr/apr/branches/1.5.x: ./ CHANGES file_io/win32/readwrite.c)

[Jeff Trawick]

On Mon, Oct 21, 2013 at 12:41 PM, Stefan Ruppert  wrote:

> Am 21.10.2013 16:22, schrieb Jeff Trawick:
>
>> On Mon, Oct 21, 2013 at 8:57 AM, > <mailto:traw...@apache.org>> wrote:
>>
>> Author: trawick
>> Date: Mon Oct 21 12:57:05 2013
>> New Revision: 1534139
>>
>> URL: http://svn.apache.org/r1534139
>> Log:
>> Merge r960671 from trunk:
>>
>> Only deal with the mutex when XTHREAD is enabled. This increases the
>> performance of buffered reads/writes tremendously.
>>
>> * file_io/win32/readwrite.c:
>>(apr_file_read, apr_file_write): only manipulate mutex when XTHREAD
>>
>> Submitted by: Ivan Zhakov http://visualsvn.com>>
>>
>>
>> Trunk continues to allocate a mutex if buffered, even if the XTHREAD
>> flag is on (a minor detail I suppose).  That presumably is a simple fix
>> after double checking all the references to mutex or buffered in the
>> code used on Windows.  ISTR other concerns about the mutex or XTHREAD,
>> but I think this is an orthogonal issue.
>>
>
> Regarding exclusive access to a file under windows I filed a bug in 2010:
> https://issues.apache.org/**bugzilla/show_bug.cgi?id=50058<https://issues.apache.org/bugzilla/show_bug.cgi?id=50058>
>
> Using the apr_file_lock()/apr_file_**unlock() under Windows in append
> mode will deadlock the current thread! In the time of 2010 I just removed
> the apr_file_lock()/apr_file_**unlock() code within the readwrite.c
> module. But a better solution is to support nesting within
> apr_file_lock()/apr_file_**unlock() API calls!
>
> Any comments?
>
> Stefan
>
>
I thought it was this simple for append:

On Unix a lock isn't needed because the APR implementation there uses
O_APPEND, which is atomic (subject to the size of the write I suppose)*; on
Windows there's no such feature and APR has to use a lock to make it
equivalent.  So the app shouldn't be getting a lock.

Is that consistent with what you see?

*IIUC this isn't true for NFS

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1534139 - in /apr/apr/branches/1.5.x: ./ CHANGES file_io/win32/readwrite.c

[Jeff Trawick]

On Mon, Oct 21, 2013 at 8:57 AM,  wrote:

> Author: trawick
> Date: Mon Oct 21 12:57:05 2013
> New Revision: 1534139
>
> URL: http://svn.apache.org/r1534139
> Log:
> Merge r960671 from trunk:
>
> Only deal with the mutex when XTHREAD is enabled. This increases the
> performance of buffered reads/writes tremendously.
>
> * file_io/win32/readwrite.c:
>   (apr_file_read, apr_file_write): only manipulate mutex when XTHREAD
>
> Submitted by: Ivan Zhakov 
>

Trunk continues to allocate a mutex if buffered, even if the XTHREAD flag
is on (a minor detail I suppose).  That presumably is a simple fix after
double checking all the references to mutex or buffered in the code used on
Windows.  ISTR other concerns about the mutex or XTHREAD, but I think this
is an orthogonal issue.




>
> Modified:
> apr/apr/branches/1.5.x/   (props changed)
> apr/apr/branches/1.5.x/CHANGES
> apr/apr/branches/1.5.x/file_io/win32/readwrite.c
>
> Propchange: apr/apr/branches/1.5.x/
>
> --
>   Merged /apr/apr/trunk:r960671
>
> Modified: apr/apr/branches/1.5.x/CHANGES
> URL:
> http://svn.apache.org/viewvc/apr/apr/branches/1.5.x/CHANGES?rev=1534139&r1=1534138&r2=1534139&view=diff
>
> ==
> --- apr/apr/branches/1.5.x/CHANGES [utf-8] (original)
> +++ apr/apr/branches/1.5.x/CHANGES [utf-8] Mon Oct 21 12:57:05 2013
> @@ -1,6 +1,10 @@
>   -*- coding: utf-8 -*-
>  Changes for APR 1.5.0
>
> +  *) Windows:  Don't obtain a mutex for buffered file I/O unless the
> + file was opened with the APR_FOPEN_XTHREAD flag.  [Ivan Zhakov
> + ]
> +
>*) Windows:  Create named shared memory segments under the "Local"
>   namespace if the caller is unprivileged, fixing an inability of
>   unprivileged callers to use apr_shm_create() with named shared
>
> Modified: apr/apr/branches/1.5.x/file_io/win32/readwrite.c
> URL:
> http://svn.apache.org/viewvc/apr/apr/branches/1.5.x/file_io/win32/readwrite.c?rev=1534139&r1=1534138&r2=1534139&view=diff
>
> ==
> --- apr/apr/branches/1.5.x/file_io/win32/readwrite.c (original)
> +++ apr/apr/branches/1.5.x/file_io/win32/readwrite.c Mon Oct 21 12:57:05
> 2013
> @@ -181,12 +181,16 @@ APR_DECLARE(apr_status_t) apr_file_read(
>  apr_size_t blocksize;
>  apr_size_t size = *len;
>
> -apr_thread_mutex_lock(thefile->mutex);
> +if (thefile->flags & APR_FOPEN_XTHREAD) {
> +apr_thread_mutex_lock(thefile->mutex);
> +}
>
>  if (thefile->direction == 1) {
>  rv = apr_file_flush(thefile);
>  if (rv != APR_SUCCESS) {
> -apr_thread_mutex_unlock(thefile->mutex);
> +if (thefile->flags & APR_FOPEN_XTHREAD) {
> +apr_thread_mutex_unlock(thefile->mutex);
> +}
>  return rv;
>  }
>  thefile->bufpos = 0;
> @@ -223,7 +227,10 @@ APR_DECLARE(apr_status_t) apr_file_read(
>  if (*len) {
>  rv = APR_SUCCESS;
>  }
> -apr_thread_mutex_unlock(thefile->mutex);
> +
> +if (thefile->flags & APR_FOPEN_XTHREAD) {
> +apr_thread_mutex_unlock(thefile->mutex);
> +}
>  } else {
>  /* Unbuffered i/o */
>  apr_size_t nbytes;
> @@ -260,7 +267,9 @@ APR_DECLARE(apr_status_t) apr_file_write
>  apr_size_t blocksize;
>  apr_size_t size = *nbytes;
>
> -apr_thread_mutex_lock(thefile->mutex);
> +if (thefile->flags & APR_FOPEN_XTHREAD) {
> +apr_thread_mutex_lock(thefile->mutex);
> +}
>
>  if (thefile->direction == 0) {
>  /* Position file pointer for writing at the offset we are
> logically reading from */
> @@ -286,7 +295,9 @@ APR_DECLARE(apr_status_t) apr_file_write
>  size -= blocksize;
>  }
>
> -apr_thread_mutex_unlock(thefile->mutex);
> +if (thefile->flags & APR_FOPEN_XTHREAD) {
> +apr_thread_mutex_unlock(thefile->mutex);
> +}
>  return rv;
>  } else {
>  if (!thefile->pipe) {
>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Timetable for APR 1.5 release?

[Jeff Trawick]

On Thu, Oct 17, 2013 at 11:08 PM, Gregg Smith  wrote:

> On 10/17/2013 7:49 AM, Jeff Trawick wrote:
>
>> On Wed, Oct 16, 2013 at 9:22 AM, Jeff Trawick > traw...@gmail.com>> wrote:
>>
>> On Tue, Oct 1, 2013 at 8:26 AM, Jeff Trawick > <mailto:traw...@gmail.com>> wrote:
>>
>> On Tue, Oct 1, 2013 at 7:32 AM, Jim Jagielski > <mailto:j...@jagunet.com>> wrote:
>>
>> Subj sez it all.
>>
>> I've never been RM for APR but am willing to do this one...
>>
>>
>> I'm happy to take care of the RM work.
>>
>> Some things I'm interested in checking on for 1.5.x:
>>
>> * Compare 1.4.x<->1.5.x and see if anything was missed.  (I'm
>> pretty sure that there are some .h fixes that skipped 1.5.x;
>> dunno what else.)
>> * Add the cmake support.  (I purposefully skipped the 1.5.x
>> branch when there was constant activity.)
>> * Put in a couple of fixes for Cygwin that somebody opened
>> bugs for in the last week or so.
>> * Test MinGW static and shared builds in conjunction with
>> APR-util 1.5.x.  (Should be okay; some fixes for shared never
>> hit the 1.4.x branch, so it would be good to ensure this is
>> finally working.)
>> * Check for anything whatsoever that could be merged from
>> trunk and see what to do, as presumably there won't be another
>> opportunity for a while.
>>
>> It would be good for T&R to be no sooner than next Monday.
>>
>> Any other thoughts on what to look at before T&R of the first
>> 1.5.x release?
>>
>> -- Born in Roswell... married an alien...
>> http://emptyhammock.com/
>>
>>
>> I haven't forgotten :)  I want to wrap up the apr_shm stuff on
>> Windows and finish working through appropriate fixes that aren't
>> in 1.5.x.  Additionally, the traditional Windows build system is
>> not ready in the 1.5.x branch but maybe some kind soul will be
>> able to take care of that.
>>
>>
>> BTW, the stuff that seems to be missing from the traditional Windows
>> build system in the 1.5.x branch is
>>
>> * apr_escape stuff including gen_test_char (I think trunk has this in the
>> Windows build system)
>>
>
> No, I see nothing in trunk for either.


oops, sorry :(


> I'd like to first rid the 1.5 traditional Windows build of the Release9x &
> Debug9x targets. Anyone against this?
>

no concerns here; is there code that can get deleted too?


>
> gen_test_char is straight forward enough, generates apr_escape_test_char.h
> which is included in apr_escape.c.  I am however compelled to think of
> httpd and this gets tricky when building httpd in it's traditional build
> (since apr is built during the httpd build) if I need to first build
> gen_test_char so I can generate the header before compiling the libs. Since
> this is not needed in APR < 1.5, to do this in httpd may create a
> requirement for APR 1.5 in httpd. Not sure that's a bad thing.
>

I'm confused.  httpd still has its own gen_test_char when generates a
certain .h, and apr now has one that generates a different .h.  Why
wouldn't the build continue to run both programs when building httpd 2.4 in
conjunction with apr 1.5?  (I assume that in the future httpd trunk will
consume apr_escape and not need both, but we're not there yet.)



> There is a existing pre-generated apr_escape_test_char.h in
> apr/include/private but if differs slightly from the output I get when I
> run gen_test_char on Windows. What I do get is consistent over the 3
> different Windows versions on three different computers and two different
> versions of MSVC.  The difference between them is;
> -32,30,30,30,30,30,30,30,30,30,**31,30,30,30,30,30,30,30,30,30,
> -30,30,30,30,30,30,30,30,30,30,**30,30,6,16,63,22,17,22,49,17,
> +32,30,30,30,30,30,30,30,30,30,**31,30,30,31,30,30,30,30,30,30,
> +30,30,30,30,30,30,30,30,30,30,**30,30,6,16,63,22,17,23,49,17,
>

What this means is that \r and % are escaped on Windows and OS/2 when
performing shell escaping, but are not on other platforms.

>
> Regardless of which I compile with (existing or freshly generated),
> testescape succeeds. So I seem to have a few options and not sure which way
> to turn.
>
> 1. build and run gen_test_char before compiling APR. This would need to be
> duplicated in httpd which would create the requirement for APR 1.5.
>

help me out h

Re: Timetable for APR 1.5 release?

[Jeff Trawick]

On Wed, Oct 16, 2013 at 9:22 AM, Jeff Trawick  wrote:

> On Tue, Oct 1, 2013 at 8:26 AM, Jeff Trawick  wrote:
>
>> On Tue, Oct 1, 2013 at 7:32 AM, Jim Jagielski  wrote:
>>
>>> Subj sez it all.
>>>
>>> I've never been RM for APR but am willing to do this one...
>>>
>>
>> I'm happy to take care of the RM work.
>>
>> Some things I'm interested in checking on for 1.5.x:
>>
>> * Compare 1.4.x<->1.5.x and see if anything was missed.  (I'm pretty sure
>> that there are some .h fixes that skipped 1.5.x; dunno what else.)
>> * Add the cmake support.  (I purposefully skipped the 1.5.x branch when
>> there was constant activity.)
>> * Put in a couple of fixes for Cygwin that somebody opened bugs for in
>> the last week or so.
>> * Test MinGW static and shared builds in conjunction with APR-util 1.5.x.
>>  (Should be okay; some fixes for shared never hit the 1.4.x branch, so it
>> would be good to ensure this is finally working.)
>> * Check for anything whatsoever that could be merged from trunk and see
>> what to do, as presumably there won't be another opportunity for a while.
>>
>> It would be good for T&R to be no sooner than next Monday.
>>
>> Any other thoughts on what to look at before T&R of the first 1.5.x
>> release?
>>
>> --
>> Born in Roswell... married an alien...
>> http://emptyhammock.com/
>>
>
> I haven't forgotten :)  I want to wrap up the apr_shm stuff on Windows and
> finish working through appropriate fixes that aren't in 1.5.x.
>  Additionally, the traditional Windows build system is not ready in the
> 1.5.x branch but maybe some kind soul will be able to take care of that.
>

BTW, the stuff that seems to be missing from the traditional Windows build
system in the 1.5.x branch is

* apr_escape stuff including gen_test_char (I think trunk has this in the
Windows build system)
* generated makefiles


>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: SHA2 in APR

[Jeff Trawick]

On Thu, Oct 10, 2013 at 4:49 PM, Dirkjan Ochtman  wrote:

> Hi,
>
> (Sending again from the right mail address, please ignore the other one.)
>
> I've been hanging out in #apr on Freenode recently, but it appears the
> intersection of people hanging out there and active APR committers is
> pretty much the empty set.
>
> I recently filed
> https://issues.apache.org/bugzilla/show_bug.cgi?id=55520 and I wonder
> if people had actually seen that. There seems to have been a lot of
> talk about an 1.5 release, so I might be late with this, but since the
> implementation has already been there, maybe exposing this isn't so
> hard? In any case, this seems like a no-brainer to me.
>
> The reason I've recently gotten interested in APR (and SHA support) is
> my work on https://github.com/mozilla/mod_authn_persona.
>
> Cheers,
>
> Dirkjan
>

(Only since nobody responded yet...)

Somebody in APR-land with an interest in hashes needs to take a bite.  What
it looks like to my very untrained eye is an implementation of one of a
handful of the SHA2 hashes* (i.e., incomplete) which was taken in 10 years
ago from another source and maintained independently and never used in a
way that would expose implementation defects beyond what various compilers
and static analysis tools complained about over the years.

*Maybe it is more complete in the 1.x branches; I just noticed that some
unused hashes were ripped out of trunk 10 months ago.

Surely there's a more appropriate place to pick up SHA2?

(But really, somebody with a real interest will hopefully respond.)

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Timetable for APR 1.5 release?

[Jeff Trawick]

On Wed, Oct 16, 2013 at 9:27 AM, Dirkjan Ochtman  wrote:

> On Wed, Oct 16, 2013 at 3:22 PM, Jeff Trawick  wrote:
> > I haven't forgotten :)  I want to wrap up the apr_shm stuff on Windows
> and
> > finish working through appropriate fixes that aren't in 1.5.x.
> > Additionally, the traditional Windows build system is not ready in the
> 1.5.x
> > branch but maybe some kind soul will be able to take care of that.
>
> Sorry if I'm nagging, but did you see my message on SHA2 from last
> week? If sending such a message is the wrong way about getting this
> done, please let me know what the right way might be.
>
> Cheers,
>
> Dirkjan
>

I'll respond on the other thread.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Timetable for APR 1.5 release?

[Jeff Trawick]

On Tue, Oct 1, 2013 at 8:26 AM, Jeff Trawick  wrote:

> On Tue, Oct 1, 2013 at 7:32 AM, Jim Jagielski  wrote:
>
>> Subj sez it all.
>>
>> I've never been RM for APR but am willing to do this one...
>>
>
> I'm happy to take care of the RM work.
>
> Some things I'm interested in checking on for 1.5.x:
>
> * Compare 1.4.x<->1.5.x and see if anything was missed.  (I'm pretty sure
> that there are some .h fixes that skipped 1.5.x; dunno what else.)
> * Add the cmake support.  (I purposefully skipped the 1.5.x branch when
> there was constant activity.)
> * Put in a couple of fixes for Cygwin that somebody opened bugs for in the
> last week or so.
> * Test MinGW static and shared builds in conjunction with APR-util 1.5.x.
>  (Should be okay; some fixes for shared never hit the 1.4.x branch, so it
> would be good to ensure this is finally working.)
> * Check for anything whatsoever that could be merged from trunk and see
> what to do, as presumably there won't be another opportunity for a while.
>
> It would be good for T&R to be no sooner than next Monday.
>
> Any other thoughts on what to look at before T&R of the first 1.5.x
> release?
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>

I haven't forgotten :)  I want to wrap up the apr_shm stuff on Windows and
finish working through appropriate fixes that aren't in 1.5.x.
 Additionally, the traditional Windows build system is not ready in the
1.5.x branch but maybe some kind soul will be able to take care of that.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [PATCH] "Global" vs. "Local" prefix on named mutexes and named shm on Windows

[Jeff Trawick]

On Tue, Oct 15, 2013 at 1:01 AM, Mladen Turk  wrote:

> On 10/15/2013 02:27 AM, Jeff Trawick wrote:
>
>
>> Or in a more APR-like fashion, add apr_shm_create_ex() and
>> apr_shm_attach_ex() which have a special processing flag (bitmap).  For
>> Windows,  APR_SHM_NS_LOCAL and APR_SHM_NS_GLOBAL would be respected.  That
>> could be used by an app that can't with with APR's
>> imperfect attempts to manage global vs. local.  I don't think there is a
>> perfect anyway.
>>
>> As 1.5.x hasn't been released yet, the _ex() functions could be in it.
>>
>>
>>
> Replacing Global with Local would basically limit the apr_shm API and it
> won't
> allow IPC using shm across sessions. With services running in Session0 shm
> is one
> of the effective IPC mechanisms. Using _ex() api and making _create() and
> _attach()
> as macros should do the trick. Although not sure what should be default
> (global or local)
> I'd go for backward compatibility (no sudden surprises when changing
> version)
>

Yeah (backward compatibility); specifying APR_SHM_NS_LOCAL or _GLOBAL would
bypass the current logic in trunk.  I still like the heuristic that allows
non-privileged processes to collaborate via shared memory without adding
any platform-specific flags.  The flag would be needed if an app wants to
use Local even if the process might be privileged, or an app must use
Global to operate (and fail if it is not privileged).



>
>
> Regards
> --
> ^TM
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [PATCH] "Global" vs. "Local" prefix on named mutexes and named shm on Windows

[Jeff Trawick]

On Mon, Oct 14, 2013 at 10:59 AM, Ivan Zhakov  wrote:

> On 14 October 2013 15:31, Jeff Trawick  wrote:
> > On Mon, Oct 14, 2013 at 4:34 AM, Ivan Zhakov  wrote:
> >>
> >> On 12 October 2013 18:48, Jeff Trawick  wrote:
> >> > With APR on Windows, creating shared memory or a cross-process mutex
> >> > with a
> >> > "file" name parameter results in a resource being created with a
> >> > "Global"
> >> > prefix, which in turn restricts the call to Administrator (or more
> >> > accurately, a thread with the specific privilege
> >> > to make that call; let's just call that "Administrator" for
> simplicity).
> >> > (I
> >> > think this is just for shared memory???)
> >> >
> >> > A typical way to encounter this is that some dude in httpd-land
> decides
> >> > that
> >> > mod_lua should start creating APR shared memory at startup and a
> >> > filename
> >> > should always be specified, and suddenly httpd running as you on
> Windows
> >> > can
> >> > no longer use mod_lua.  Any number of other httpd modules try do
> >> > something
> >> > similar (though I haven't investigated if there's a way to configure
> >> > around
> >> > it); additionally, APR's testshm won't work as a regular user.
> >> >
> >> > The attached patch uses "Local" as the prefix if the calling thread
> >> > doesn't
> >> > have the necessary privilege to create one under the global namespace.
> >> > But
> >> > this function is also used for attach-type operations,
> >> >
> >> > Has anyone investigated this before?
> >> >
> >> Jeff,
> >>
> >> It looks like very dangerous change. Local and Global namespaces are
> >> completely separate, thus priviliged process could not access
> >> shm/mutex created by unprivileged process. Objects in local kernel
> >> namespace are per session, while objects in global kernel namespace
> >> are shared across all sessions, that's why process need additional
> >> privilege to create them.
> >
> >
> > First, make sure you're looking at what was committed
> > (http://svn.apache.org/viewvc?view=revision&revision=r1531768), which is
> > slightly different and may have some different considerations.
> >
> Yes, I've used final commit for my review.
>
> > For analysis as a security concern, I think it comes down to this:
> >
> > * no elevation of privileges
> > * no change to ACL/permissions of shared memory segments
> >
> > The code ends up acting the same as if the apr app had access to the
> global
> > parameter to res_name_from_filename() and could make the adjustments
> itself.
> >
> > Some of your comments lead me to believe you thought there was a
> privilege
> > escalation. (The name of the API keyword "PRIVILEGE_SET_ALL_NECESSARY" is
> > disturbing, but it means everything-in-privilege-set-is-necessary, not
> > set-all-privileges-I-need.)  How is the privilege escalation occurring?
> >
> > Or, do you agree there is no privilege escalation?
> Oh, sorry. I missed that you are using PrivilegeCheck(), not
> AdjustTokenPrivileges() which is used to enable privileges that
> assigned, but not enabled. There is no privilege escalation. It's my
> fault.
>
> >> Services are started in separate "session 0", while interactive
> >> processes uses dedicated session for every user/rdp connection.
> >
> >
> > understood
> >
> >>
> >>
> >> Your patch may also break atomic "create or open" code:
> >> [[
> >> rv == apr_shm_create();
> >> if (rv == ALREADY_EXIST)
> >>rv = apr_shm_attach()
> >> ]]
> >
> >
> > The patch doesn't break this AFAICT, but it doesn't make this work in all
> > circumstances either.
> >
> > Assume old code (e.g., 1.5.x branch), and a privileged process
> successfully
> > creates a shm segment with a particular name under Global.  If an
> > unprivileged client tries the code sequence above, it gets access-denied
> > from apr_shm_create(), not already-exist.
> >
> > (Is that the testcase you're referring to?)
> >
> Yes, that's test I'm referring. That code should be corrected to
> handle access denied error also:
> [[[
>  rv == apr_shm_create();
>  if (rv =

Re: [PATCH] "Global" vs. "Local" prefix on named mutexes and named shm on Windows

[Jeff Trawick]

On Mon, Oct 14, 2013 at 4:34 AM, Ivan Zhakov  wrote:

> On 12 October 2013 18:48, Jeff Trawick  wrote:
> > With APR on Windows, creating shared memory or a cross-process mutex
> with a
> > "file" name parameter results in a resource being created with a "Global"
> > prefix, which in turn restricts the call to Administrator (or more
> > accurately, a thread with the specific privilege
> > to make that call; let's just call that "Administrator" for simplicity).
>  (I
> > think this is just for shared memory???)
> >
> > A typical way to encounter this is that some dude in httpd-land decides
> that
> > mod_lua should start creating APR shared memory at startup and a filename
> > should always be specified, and suddenly httpd running as you on Windows
> can
> > no longer use mod_lua.  Any number of other httpd modules try do
> something
> > similar (though I haven't investigated if there's a way to configure
> around
> > it); additionally, APR's testshm won't work as a regular user.
> >
> > The attached patch uses "Local" as the prefix if the calling thread
> doesn't
> > have the necessary privilege to create one under the global namespace.
>  But
> > this function is also used for attach-type operations,
> >
> > Has anyone investigated this before?
> >
> Jeff,
>
> It looks like very dangerous change. Local and Global namespaces are
> completely separate, thus priviliged process could not access
> shm/mutex created by unprivileged process. Objects in local kernel
> namespace are per session, while objects in global kernel namespace
> are shared across all sessions, that's why process need additional
> privilege to create them.
>

First, make sure you're looking at what was committed (
http://svn.apache.org/viewvc?view=revision&revision=r1531768), which is
slightly different and may have some different considerations.

For analysis as a security concern, I think it comes down to this:

* no elevation of privileges
* no change to ACL/permissions of shared memory segments

The code ends up acting the same as if the apr app had access to the global
parameter to res_name_from_filename() and could make the adjustments itself.

Some of your comments lead me to believe you thought there was a privilege
escalation. (The name of the API keyword "PRIVILEGE_SET_ALL_NECESSARY" is
disturbing, but it means everything-in-privilege-set-is-necessary, not
set-all-privileges-I-need.)  How is the privilege escalation occurring?

Or, do you agree there is no privilege escalation?


>
> Services are started in separate "session 0", while interactive
> processes uses dedicated session for every user/rdp connection.
>

understood


>
> Your patch may also break atomic "create or open" code:
> [[
> rv == apr_shm_create();
> if (rv == ALREADY_EXIST)
>rv = apr_shm_attach()
> ]]
>

The patch doesn't break this AFAICT, but it doesn't make this work in all
circumstances either.

Assume old code (e.g., 1.5.x branch), and a privileged process successfully
creates a shm segment with a particular name under Global.  If an
unprivileged client tries the code sequence above, it gets access-denied
from apr_shm_create(), not already-exist.

(Is that the testcase you're referring to?)

If the second process to run is also privileged, it gets the already-exists
feedback and can then attach.



>
> Suppose Windows services created shm object in global namespace,
> interactive process wanted to access it using code above.
> apr_shm_create() detects that process is not privileged and creates
> shm object in local namespace, which is wrong IMHO.
>

It doesn't work now either.  (See above.)

Is there a way to make it work within the constraints of the current API?
 I guess apr_shm_create() for unprivileged processes would need to check
via some other API to see if it already exists, in order to allow that
idiom to work for unprivileged processes that need to attach to a shm
segment created by privileged processes.



>
> Change process privileges as side effect of apr_shm_attach() is also
> nasty behavior imho.
>

I assert that this is not happening ;)

--/--

Thanks for looking at this in detail/please let me know where we
agree/disagree at this point.



>
> --
> Ivan Zhakov
>

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Fwd: buildbot failure in ASF Buildbot on apr-trunk-fbsd

[Jeff Trawick]

"Blame" is funny.  Changing win32 code breaks a test on FreeBSD and
changing CHANGES can fix it.

I think the issue is in the sendfile test program...  Periodically the
server isn't ready yet when the client tries to connect, and some retry
logic that works on Linux (try just the connect again instead of getting a
new socket) fails with EINVAL on FreeBSD.  I'll try to reproduce on FreeBSD
and fix it.

-- Forwarded message --
From: 
Date: Sun, Oct 13, 2013 at 7:04 PM
Subject: buildbot failure in ASF Buildbot on apr-trunk-fbsd
To: dev@apr.apache.org


The Buildbot has detected a new failure on builder apr-trunk-fbsd while
building ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/apr-trunk-fbsd/builds/269

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: bb-fbsd2_64bit

Build Reason: scheduler
Build Source Stamp: [branch apr/apr/trunk] 1531768
Blamelist: trawick

BUILD FAILED: failed compile_3

sincerely,
 -The Buildbot






-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

[PATCH] "Global" vs. "Local" prefix on named mutexes and named shm on Windows

[Jeff Trawick]

With APR on Windows, creating shared memory or a cross-process mutex with a
"file" name parameter results in a resource being created with a "Global"
prefix, which in turn restricts the call to Administrator (or more
accurately, a thread with the specific privilege
to make that call; let's just call that "Administrator" for simplicity).
 (I think this is just for shared memory???)

A typical way to encounter this is that some dude in httpd-land decides
that mod_lua should start creating APR shared memory at startup and a
filename should always be specified, and suddenly httpd running as you on
Windows can no longer use mod_lua.  Any number of other httpd modules try
do something similar (though I haven't investigated if there's a way to
configure around it); additionally, APR's testshm won't work as a regular
user.

The attached patch uses "Local" as the prefix if the calling thread doesn't
have the necessary privilege to create one under the global namespace.  But
this function is also used for attach-type operations,

Has anyone investigated this before?

I suspect that the internal support routine res_name_from_file() (affected
by the patch) and callers need to be refactored so that

a. proc mutexes aren't affected
b. when trying to attach to shared memory from a caller without the
privilege, first try with the Local prefix (which is probably where it is)
and then try with the Global prefix (in case the shm was created by a
process with the privilege)

Unless someone has hints, I'll proceed in that manner.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/
Index: file_io/win32/open.c
===
--- file_io/win32/open.c(revision 1531529)
+++ file_io/win32/open.c(working copy)
@@ -147,6 +147,41 @@
 apr_size_t r, d;
 
 if (apr_os_level >= APR_WIN_2000) {
+#ifdef SE_CREATE_GLOBAL_NAME
+if (global && apr_os_level >= APR_WIN_2003) {
+/* We'll see if the caller is able to create an object in the 
global
+ * namespace and, if not, create it in the local namespace 
instead.
+ *
+ * NOTE: This utility function is used for both creating 
objects and
+ * accessing them; use of the Global prefix will be based 
purely on
+ * whether the user could create them.
+ */
+BOOL ok, has_priv;
+LUID priv_id;
+PRIVILEGE_SET privs;
+HANDLE hToken;
+
+ok = OpenThreadToken(GetCurrentThread(), TOKEN_QUERY, TRUE, 
&hToken);
+if (!ok && GetLastError() == ERROR_NO_TOKEN) {
+/* no thread-specific access token, so try to get process 
access token
+ */
+ok = OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, 
&hToken);
+}
+if (ok) {
+ok = LookupPrivilegeValue(NULL, SE_CREATE_GLOBAL_NAME, 
&priv_id);
+}
+if (ok) {
+privs.PrivilegeCount = 1;
+privs.Control = PRIVILEGE_SET_ALL_NECESSARY;
+privs.Privilege[0].Luid = priv_id;
+privs.Privilege[0].Attributes = SE_PRIVILEGE_ENABLED;
+ok = PrivilegeCheck(hToken, &privs, &has_priv);
+}
+if (ok && !has_priv) {
+global = 0;
+}
+}
+#endif /* SE_CREATE_GLOBAL_NAME */
 if (global)
 wpre = L"Global\\";
 else

Re: [PATCH] apr escape API, portability issues seen on Windows

[Jeff Trawick]

On Wed, Oct 9, 2013 at 5:28 PM, Graham Leggett  wrote:

> On 09 Oct 2013, at 10:34 PM, Jeff Trawick  wrote:
>
> > The function is trying to escape any binary values that could
> conceivably cause problems when printed to the terminal, whether or not
> those values happen to have a C escape sequence "shortcut".  The escaping
> is done regardless IIUC.  It looks like the code which uses \e is just
> trying to use well-known shortcuts for certain escape sequences, and if the
> \e code is removed then it will use the hex equivalent.
>
> This is true.
>
> I have backported the API in r1530799, would it be possible to take a look
> for me?
>

Work fine for me with the cmake-based build on Windows (MSVC).

Thanks!


>
> Regards,
> Graham
> --
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [PATCH] apr escape API, portability issues seen on Windows

[Jeff Trawick]

On Wed, Oct 9, 2013 at 4:25 PM, Graham Leggett  wrote:

> On 03 Oct 2013, at 1:51 AM, Jeff Trawick  wrote:
>
> > I dug into the glitches seen on Windows...   \e is a non-portable escape
> (GNU extension), and shell escaping treats \n differently on Windows and
> OS/2, which the testcase didn't account for.
> >
> > I guess the code that used \e doesn't match anything in httpd?
>
> Looking back at the code it originated from ap_escape_logitem() and
> ap_escape_errorlog_item() which are almost identical but for additional
> escape sequences.
>
> If \e is non-portable in C it can be removed, an escape character is
> unlikely to cause harm.
>

The function is trying to escape any binary values that could conceivably
cause problems when printed to the terminal, whether or not those values
happen to have a C escape sequence "shortcut".  The escaping is done
regardless IIUC.  It looks like the code which uses \e is just trying to
use well-known shortcuts for certain escape sequences, and if the \e code
is removed then it will use the hex equivalent.


> Regards,
> Graham
> --
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Timetable for APR 1.5 release?

[Jeff Trawick]

(whoops, meant to respond to both places; I hate this list setup)

On Wed, Oct 9, 2013 at 3:33 PM, Jeff Trawick  wrote:

> On Wed, Oct 9, 2013 at 3:17 PM, Graham Leggett  wrote:
>
>> On 02 Oct 2013, at 3:40 PM, Jeff Trawick  wrote:
>>
>> There is also the apr_escape API from v2.0 which has not been backported
>>> yet.
>>>
>>
>> That doesn't work on Windows; relies (or just uses?) some non-portable
>> escape sequence...  I see the warnings roll by during compile and the
>> testcase fails but I haven't taken the time to investigate.
>>
>>
>> Another ping on those details.
>>
>
> I posted a patch to dev@apr with subject "[PATCH] apr escape API,
> portability issues seen on Windows".
>
>
>>
>> The apr_escape API consists simply of code that has been historically
>> scattered around the httpd codebase, none of the code is new. If there are
>> warnings on Windows it could be caused by #ifdef's not correctly specified
>> or something similar, without seeing any of the warnings though I cannot
>> comment.
>>
>> In the mean time I will backport the API to get the ball rolling.
>>
>
> Please don't put the gcc extension escape sequence into a stable branch
> without protecting the code from other compilers.  Really, all of the code
> affected by the patch needs to be considered first.
>
>
>>
>> Regards,
>> Graham
>> --
>>
>>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Timetable for APR 1.5 release?

[Jeff Trawick]

On Thu, Oct 3, 2013 at 12:31 PM, Mike Rumph  wrote:

> Thanks Rainer,
>
> The backport looks good!
>
> Perhaps you could also consider applying my doc patch for apr_buckets.h in
> bug 55115.
> - 
> https://issues.apache.org/**bugzilla/show_bug.cgi?id=55115
>
> It is a small doc change, but corrects a misconception that could mislead
> a module writer.
>

On my list in case nobody else takes care of it first.  Thanks!


>
> Take care,
>
> Mike Rumph
>
>
>
>
>
> On 10/3/2013 6:42 AM, Rainer Jung wrote:
>
>> On 02.10.2013 16:19, Mike Rumph wrote:
>>
>>> Hello Jeff,
>>>
>>> Since you are considering a release of APR 1.5.
>>> This might be a good time to backport the APR documentation patch from
>>> revision 1496407.
>>> The second patch in bug 55133 will apply to the APR 1.5.x branch.
>>> - 
>>> https://issues.apache.org/**bugzilla/show_bug.cgi?id=55133
>>> This contains about 30 documentation corrections.
>>>
>> I've merged r1496407 to apr/apu. Please double check. Thanks!
>>
>> Rainer
>>
>>
>>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Timetable for APR 1.5 release?

[Jeff Trawick]

On Thu, Oct 3, 2013 at 12:53 PM, Jim Jagielski  wrote:

>
> On Oct 1, 2013, at 8:26 AM, Jeff Trawick  wrote:
>
> > * Check for anything whatsoever that could be merged from trunk and see
> what to do, as presumably there won't be another opportunity for a while.
> >
>
> The diff between 1.5 and trunk is pretty large, but here is a diff file
> with the apr0util stuff deleted from it...
>
> Some things (like the shm stuff) looks ez, but this is QUITE a large
> list to go thru by Monday.
>

Monday was the earliest possible I could imagine...  A bit later is better
:)



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

[PATCH] apr escape API, portability issues seen on Windows

[Jeff Trawick]

I dug into the glitches seen on Windows...   \e is a non-portable escape
(GNU extension), and shell escaping treats \n differently on Windows and
OS/2, which the testcase didn't account for.

I guess the code that used \e doesn't match anything in httpd?

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/
Index: encoding/apr_escape.c
===
--- encoding/apr_escape.c   (revision 1528671)
+++ encoding/apr_escape.c   (working copy)
@@ -862,11 +862,6 @@
 size++;
 found = 1;
 break;
-case '\e':
-*d++ = 'e';
-size++;
-found = 1;
-break;
 case '\f':
 *d++ = 'f';
 size++;
@@ -931,7 +926,6 @@
 switch (c) {
 case '\a':
 case '\b':
-case '\e':
 case '\f':
 case '\n':
 case '\r':
Index: test/testescape.c
===
--- test/testescape.c   (revision 1528671)
+++ test/testescape.c   (working copy)
@@ -34,15 +34,33 @@
 
 apr_pool_create(&pool, NULL);
 
+src = "Hello World &;`'\"|*?~<>^()[]{}$\\";
+target = "Hello World 
\\&\\;\\`\\'\\\"\\|\\*\\?\\~\\<\\>\\^\\(\\)\\[\\]\\{\\}\\$";
+dest = apr_pescape_shell(pool, src);
+ABTS_ASSERT(tc,
+apr_psprintf(pool, "shell escaped (%s) does not match expected 
output (%s)",
+ dest, target),
+(strcmp(dest, target) == 0));
+apr_escape_shell(NULL, src, APR_ESCAPE_STRING, &len);
+ABTS_ASSERT(tc,
+apr_psprintf(pool, "size mismatch (%" APR_SIZE_T_FMT "!=%" 
APR_SIZE_T_FMT ")", len, strlen(dest) + 1),
+(len == strlen(dest) + 1));
+
+#if !(defined(OS2) || defined(WIN32))
+/* Now try with newline, which is converted to a space on OS/2 and Windows.
+ */
 src = "Hello World &;`'\"|*?~<>^()[]{}$\\\n";
 target = "Hello World 
\\&\\;\\`\\'\\\"\\|\\*\\?\\~\\<\\>\\^\\(\\)\\[\\]\\{\\}\\$\\\n";
 dest = apr_pescape_shell(pool, src);
-ABTS_ASSERT(tc, "shell escaped matches expected output",
+ABTS_ASSERT(tc,
+apr_psprintf(pool, "shell escaped (%s) does not match expected 
output (%s)",
+ dest, target),
 (strcmp(dest, target) == 0));
 apr_escape_shell(NULL, src, APR_ESCAPE_STRING, &len);
 ABTS_ASSERT(tc,
 apr_psprintf(pool, "size mismatch (%" APR_SIZE_T_FMT "!=%" 
APR_SIZE_T_FMT ")", len, strlen(dest) + 1),
 (len == strlen(dest) + 1));
+#endif
 
 src = "Hello";
 dest = apr_punescape_url(pool, src, NULL, NULL, 0);
@@ -196,8 +214,8 @@
 dest = apr_pescape_echo(pool, src, 0);
 ABTS_PTR_EQUAL(tc, src, dest);
 
-src = "\a\b\e\f\\n\r\t\v\"Hello World\"";
-target = "\\a\\b\\e\\fn\\r\\t\\v\"Hello World\"";
+src = "\a\b\f\\n\r\t\v\"Hello World\"";
+target = "\\a\\b\\fn\\r\\t\\v\"Hello World\"";
 dest = apr_pescape_echo(pool, src, 0);
 ABTS_STR_EQUAL(tc, target, dest);
 apr_escape_echo(NULL, src, APR_ESCAPE_STRING, 0, &len);
@@ -205,8 +223,8 @@
 apr_psprintf(pool, "size mismatch (%" APR_SIZE_T_FMT "!=%" 
APR_SIZE_T_FMT ")", len, strlen(dest) + 1),
 (len == strlen(dest) + 1));
 
-src = "\a\b\e\f\\n\r\t\v\"Hello World\"";
-target = "\\a\\b\\e\\fn\\r\\t\\v\\\"Hello World\\\"";
+src = "\a\b\f\\n\r\t\v\"Hello World\"";
+target = "\\a\\b\\fn\\r\\t\\v\\\"Hello World\\\"";
 dest = apr_pescape_echo(pool, src, 1);
 ABTS_STR_EQUAL(tc, target, dest);
 apr_escape_echo(NULL, src, APR_ESCAPE_STRING, 1, &len);

Re: Timetable for APR 1.5 release?

[Jeff Trawick]

On Wed, Oct 2, 2013 at 9:37 AM, Graham Leggett  wrote:

> On 01 Oct 2013, at 2:26 PM, Jeff Trawick  wrote:
>
> > I'm happy to take care of the RM work.
> >
> > Some things I'm interested in checking on for 1.5.x:
> >
> > * Compare 1.4.x<->1.5.x and see if anything was missed.  (I'm pretty
> sure that there are some .h fixes that skipped 1.5.x; dunno what else.)
>
> There is also the apr_escape API from v2.0 which has not been backported
> yet.
>

That doesn't work on Windows; relies (or just uses?) some non-portable
escape sequence...  I see the warnings roll by during compile and the
testcase fails but I haven't taken the time to investigate.



>
> Regards,
> Graham
> --
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Timetable for APR 1.5 release?

[Jeff Trawick]

On Tue, Oct 1, 2013 at 7:32 AM, Jim Jagielski  wrote:

> Subj sez it all.
>
> I've never been RM for APR but am willing to do this one...
>

I'm happy to take care of the RM work.

Some things I'm interested in checking on for 1.5.x:

* Compare 1.4.x<->1.5.x and see if anything was missed.  (I'm pretty sure
that there are some .h fixes that skipped 1.5.x; dunno what else.)
* Add the cmake support.  (I purposefully skipped the 1.5.x branch when
there was constant activity.)
* Put in a couple of fixes for Cygwin that somebody opened bugs for in the
last week or so.
* Test MinGW static and shared builds in conjunction with APR-util 1.5.x.
 (Should be okay; some fixes for shared never hit the 1.4.x branch, so it
would be good to ensure this is finally working.)
* Check for anything whatsoever that could be merged from trunk and see
what to do, as presumably there won't be another opportunity for a while.

It would be good for T&R to be no sooner than next Monday.

Any other thoughts on what to look at before T&R of the first 1.5.x release?

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1518760 - in /apr/apr/branches/1.4.x: CMakeLists.txt README.cmake include/apr.hwc

[Jeff Trawick]

On Thu, Sep 5, 2013 at 8:53 AM, Bert Huijben  wrote:

>
>
> > -Original Message-
> > From: traw...@apache.org [mailto:traw...@apache.org]
> > Sent: donderdag 29 augustus 2013 20:49
> > To: comm...@apr.apache.org
> > Subject: svn commit: r1518760 - in /apr/apr/branches/1.4.x:
> CMakeLists.txt
> > README.cmake include/apr.hwc
> >
> > Author: trawick
> > Date: Thu Aug 29 18:48:38 2013
> > New Revision: 1518760
> >
> > URL: http://svn.apache.org/r1518760
> > Log:
> > Add cmake build for APR 1.4.x.
> >
> > apr.hwc is the same as apr.hw other than making the APR_HAVE_IPV6
> > setting a variable.
> >
> > This is not currently in the 1.5.x branch, which sees little
> > use.
> >
> > Added:
> > apr/apr/branches/1.4.x/CMakeLists.txt   (with props)
> > apr/apr/branches/1.4.x/README.cmake   (with props)
> > apr/apr/branches/1.4.x/include/apr.hwc   (with props)
> >
> > Added: apr/apr/branches/1.4.x/CMakeLists.txt
> > URL:
> > http://svn.apache.org/viewvc/apr/apr/branches/1.4.x/CMakeLists.txt?rev=1
> > 518760&view=auto
> > ==
> > 
> > --- apr/apr/branches/1.4.x/CMakeLists.txt (added)
> > +++ apr/apr/branches/1.4.x/CMakeLists.txt Thu Aug 29 18:48:38 2013
> > @@ -0,0 +1,317 @@
> > +PROJECT(APR C)
> > +
> > +# Licensed to the Apache Software Foundation (ASF) under one or more
> > +# contributor license agreements.  See the NOTICE file distributed with
> > +# this work for additional information regarding copyright ownership.
> > +# The ASF licenses this file to You under the Apache License, Version
> 2.0
> > +# (the "License"); you may not use this file except in compliance with
> > +# the License.  You may obtain a copy of the License at
> > +#
> > +# http://www.apache.org/licenses/LICENSE-2.0
> > +#
> > +# Unless required by applicable law or agreed to in writing, software
> > +# distributed under the License is distributed on an "AS IS" BASIS,
> > +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> > implied.
> > +# See the License for the specific language governing permissions and
> > +# limitations under the License.
> > +#
> > +# Read README.cmake before using this.
> > +
> > +CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
> > +
> > +OPTION(APR_INSTALL_PRIVATE_H  "Install selected private .h files (for
> > httpd)"  OFF)
> > +OPTION(APR_HAVE_IPV6"IPv6 support" ON)
> > +OPTION(APR_SHOW_SETTINGS"Show the build configuration" ON)
> > +OPTION(APR_BUILD_TESTAPR"Build the test suite" OFF)
> 
>
> You also need these APR_INSTALL_PRIVATE_H private .h files to build
> Subversion.
>
> With Subversion <= 1.8 we assumed that you always have the APR sources
> available, but on Subversion trunk just having these headers available with
> your APR allows you to build against a pre-compiled APR.
>
> So it might be useful to note this somewhere.
>
> Bert
>
> Thanks!

r1520293 (trunk)
r1520295 (1.4.x)


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: will anyone build httpd/apr with cmake on Windows?

[Jeff Trawick]

On Mon, Sep 2, 2013 at 8:38 AM, Mario Brandt  wrote:

> Hi Jeff,
>
> thanks for your effort on the windows build. You may take a look at
> https://github.com/winlibs/apache
>


Thanks for the pointer; that's a concise representation of the current
Windows build with modern tools.  (Too bad about the requirement for
keyboard presses in the middle.)  Also, it is a good source of hints for
building the other projects.



>
> Cheers
> Mario
>
>
> On 2 September 2013 14:31, Jeff Trawick  wrote:
>
>> Here's a simple build script that uses an existing OpenSSL installation
>> and builds pcre, zlib, libxml2, apr, apr-util, and httpd.  Unfortunately it
>> has a number of dependencies on my own machine, but it should be relatively
>> easy to see all the configure parameters in one place.
>>
>> http://people.apache.org/~trawick/bldall.cmd.r1
>>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: will anyone build httpd/apr with cmake on Windows?

[Jeff Trawick]

Here's a simple build script that uses an existing OpenSSL installation and
builds pcre, zlib, libxml2, apr, apr-util, and httpd.  Unfortunately it has
a number of dependencies on my own machine, but it should be relatively
easy to see all the configure parameters in one place.

http://people.apache.org/~trawick/bldall.cmd.r1

will anyone build httpd/apr with cmake on Windows?

[Jeff Trawick]

I will be throwing a bit more time at the cmake effort in the short term,
starting with comparing the installed artifacts with those of existing
Windows builds and adding missing pieces to the todo lists.  I might not do
much else proactively until my own use of the builds catches up and starts
to exceed what is implemented.

Please let me know if you

* are waiting for some certain feature (other than near perfection) before
you use it
* attempt to use it but are slowed down by tool requirements or bad
documentation or anything else
* attempt to use it but it fails so badly that you leave it in disgust with
no desire to report or try to fix anything
* try it and it works for you (what cmake backend, what other build
characteristics)
* etc.

Thanks!

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/