Re: buildbot failure in on apr-x64-macosx-trunk
On 25.06.2018 23:16, Graham Leggett wrote: > On 25 Jun 2018, at 11:09 PM, build...@apache.org wrote: >> The Buildbot has detected a new failure on builder apr-x64-macosx-trunk >> while building . Full details are available at: >>https://ci.apache.org/builders/apr-x64-macosx-trunk/builds/109 >> >> Buildbot URL: https://ci.apache.org/ >> >> Buildslave for this Build: svn-x64-macosx-dgvrs >> >> Build Reason: The AnyBranchScheduler scheduler named 'on-apr-commit' >> triggered this build >> Build Source Stamp: [branch apr/apr/trunk] 1834376 >> Blamelist: minfrin >> >> BUILD FAILED: failed Test > The failure reported is at the end of this URL, does this make sense to > anybody? It is possible that there's a race somewhere in the tests. The sources are built, and tests run, on an HFS+ ramdisk, which is both fast and has subsecond time resolution. Notice that a subsequent test run succeeded. -- Brane
buildbot success in on apr-x64-macosx-trunk
The Buildbot has detected a restored build on builder apr-x64-macosx-trunk while building . Full details are available at: https://ci.apache.org/builders/apr-x64-macosx-trunk/builds/111 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: svn-x64-macosx-dgvrs Build Reason: The AnyBranchScheduler scheduler named 'on-apr-commit' triggered this build Build Source Stamp: [branch apr/apr/trunk] 1834541 Blamelist: ylavic Build succeeded! Sincerely, -The Buildbot
Re: svn commit: r1834513 - in /apr/apr/branches/1.6.x: STATUS file_io/win32/buffer.c
Any reason this is absent from development branch 1.7.x? I think all such
1.x-only issues should be started there. (Similarly with apr-util.)
On Wed, Jun 27, 2018 at 10:21 AM, wrote:
> Author: jfclere
> Date: Wed Jun 27 15:21:19 2018
> New Revision: 1834513
>
> URL: http://svn.apache.org/viewvc?rev=1834513=rev
> Log:
> remove the wrong proposal in STATUS and commit a fix for my crash problems.
>
> Modified:
> apr/apr/branches/1.6.x/STATUS
> apr/apr/branches/1.6.x/file_io/win32/buffer.c
>
> Modified: apr/apr/branches/1.6.x/STATUS
> URL: http://svn.apache.org/viewvc/apr/apr/branches/1.6.x/STATUS?
> rev=1834513=1834512=1834513=diff
>
> ==
> --- apr/apr/branches/1.6.x/STATUS [utf-8] (original)
> +++ apr/apr/branches/1.6.x/STATUS [utf-8] Wed Jun 27 15:21:19 2018
> @@ -98,10 +98,6 @@ CURRENT VOTES:
>1.5.x patch: http://people.apache.org/~jim/
> patches/apr-1.5-permset.patch
>+1:
>
> -* make sure we don't unlock mutex when we haven't locked it.
> - 1.6.x patch: http://people.apache.org/~jfclere/patch.180618.txt
> - +1 jfclere
> -
> CURRENT test/testall -v EXCEPTIONS:
>
> Please add any platform anomilies to the following exception list.
>
> Modified: apr/apr/branches/1.6.x/file_io/win32/buffer.c
> URL: http://svn.apache.org/viewvc/apr/apr/branches/1.6.x/file_
> io/win32/buffer.c?rev=1834513=1834512=1834513=diff
>
> ==
> --- apr/apr/branches/1.6.x/file_io/win32/buffer.c (original)
> +++ apr/apr/branches/1.6.x/file_io/win32/buffer.c Wed Jun 27 15:21:19 2018
> @@ -23,13 +23,17 @@ APR_DECLARE(apr_status_t) apr_file_buffe
> {
> apr_status_t rv;
>
> -apr_thread_mutex_lock(file->mutex);
> +if (file->mutex) {
> +apr_thread_mutex_lock(file->mutex);
> +}
>
> if(file->buffered) {
> /* Flush the existing buffer */
> rv = apr_file_flush(file);
> if (rv != APR_SUCCESS) {
> -apr_thread_mutex_unlock(file->mutex);
> +if (file->mutex) {
> +apr_thread_mutex_unlock(file->mutex);
> +}
> return rv;
> }
> }
> @@ -48,7 +52,9 @@ APR_DECLARE(apr_status_t) apr_file_buffe
> file->buffered = 0;
> }
>
> -apr_thread_mutex_unlock(file->mutex);
> +if (file->mutex) {
> +apr_thread_mutex_unlock(file->mutex);
> +}
>
> return APR_SUCCESS;
> }
>
>
>
Re: svn commit: r1833786 - /apr/apr/branches/1.6.x/STATUS
On 21/06/18 10:36, Rainer Jung wrote:
> Am 21.06.2018 um 10:24 schrieb jean-frederic clere:
>> On 21/06/18 10:04, Yann Ylavic wrote:
>>> On Thu, Jun 21, 2018 at 8:00 AM, jean-frederic clere
>>> wrote:
OK if everyone agrees I will just commit my small fix and don't
backport
the 2 other revisions.
>>>
>>> Are we looking at the same 1.6.x code?
>>> For me apr_file_buffer_set() locks the mutex unconditionally so it
>>> must unlock it likewise, I don't understand what your patch solves.
>>
>> that is what my patch is doing ;-)
>
> Please be more explicit. I agree with Yann. From current unpatched APR
> 1.6.x file_io/win32/buffer.c:
>
> APR_DECLARE(apr_status_t) apr_file_buffer_set(apr_file_t *file,
> char * buffer,
> apr_size_t bufsize)
> {
> ...
> apr_thread_mutex_lock(file->mutex);
>
> if(file->buffered) {
> ...
> if (rv != APR_SUCCESS) {
> apr_thread_mutex_unlock(file->mutex);
> return rv;
> }
> }
>
> ... (no return)
>
> apr_thread_mutex_unlock(file->mutex);
>
> return APR_SUCCESS;
> }
>
> So where's the problem? Unconditional "apr_thread_mutex_lock" and
> unconditional "apr_thread_mutex_unlock" on every path before return.
>
> Looking at your patch
> "http://people.apache.org/~jfclere/patches/patch.180618.txt; (STATUS
> still contains a broken link, so we need to guess):
>
> Index: file_io/win32/buffer.c
> ===
> --- file_io/win32/buffer.c (revision 1833783)
> +++ file_io/win32/buffer.c (working copy)
> @@ -47,8 +47,10 @@
> */
> file->buffered = 0;
> }
> -
> - apr_thread_mutex_unlock(file->mutex);
> +
> + if (file->buffered) {
> + apr_thread_mutex_unlock(file->mutex);
> + }
>
> return APR_SUCCESS;
> }
>
>
> any call to "apr_file_buffer_set" for a file with "buffered" not set
> will end with not giving back the lock.
Correct... My problem is that file->mutex is NULL not that the file is
buffered or not...
>
> Regards,
>
> Rainer
>
--
Cheers
Jean-Frederic
