Bug 193905 - Upgrade of devel/apr1 to apr-1.5.1.1.5.4 causes devel/subversion to break
Summary: Upgrade of devel/apr1 to apr-1.5.1.1.5.4 causes devel/subversion to break
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-24 19:26 UTC by Kevin Thompson
Modified: 2014-11-27 00:40 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Thompson 2014-09-24 19:26:02 UTC
I upgraded devel/apr1 from apr-1.5.1.1.5.3_4 to apr-1.5.1.1.5.4 and then rebuilt devel/subversion.

Now, subversion always prints this:

> angst(/usr/ports) # svn up
> svn: E070008: Can't check path '/usr/ports': Partial results are valid but processing is incomplete

Googleing, it sounds like it has to do with apr_stat or apr_file_open returning APR_INCOMPLETE, but I have no idea why.

Here's a dump of what I have installed at the moment:
> angst(/usr/ports) # pkg info -d subversion
> subversion-1.8.10_3:
>         serf-1.3.7_1
>         expat-2.1.0_1
>         gettext-0.18.3.1_1
>         apr-1.5.1.1.5.4
>         sqlite3-3.8.6
> angst(/usr/ports) # pkg info -d apr
> apr-1.5.1.1.5.4:
>         expat-2.1.0_1
>         openssl-1.0.1_15
>         sqlite3-3.8.6
>         gdbm-1.11_2
>         db5-5.3.28_2
One thing I did notice that apr1 picked up a dependency to db5; I believe it was db48 previously. This seems to be an apr1 bug with file paths, but maybe the db5 change has affected something.
Comment 1 Bugzilla Automation freebsd_committer 2014-09-24 19:26:02 UTC
Maintainers CC'd
Comment 2 Kevin Thompson 2014-09-29 16:30:25 UTC
Well, when I first found this problem, I tried to make it go away - completely removing apr1 and subversion, and doing a full, clean reinstall, which didn't help anything. When I gave up I installed the previous SVN build from the package server which got me back up and running for the meantime.

In that time I updated and rebuilt the base install kernel/world, updating to `10.1-BETA3 FreeBSD 10.1-BETA3 #10 r272180`. 

Today I tried upgrading subversion back to the new build, and everything worked. I checked svn logs, and neither the devel/apr1 port or the devel/subversion port has had commits.

Previously I was running FreeBSD 10.0-STABLE-p9 r269194.

So it would seem that some combination of those versions of base, apr1, and subversion all combined to make svn break.

I haven't got a clue why.

I started to try to debug the apr calls in subversion but quickly got lost in trying to build LLDB, at which point I updated my src and rebuilt, getting to where I am now.

Take that for what it's worth. I'm fine with closing this if we want to write it off as an odd coincidence.
Comment 3 Olli Hauer freebsd_committer 2014-09-30 21:46:02 UTC
I don't think the issue was related to db48-> db5.

subversion uses dbX only on the server part and only if the repo was created with `svnadmin --fs-type bdb'.

For the database on the client side sqlite3 is used (.svn/wc.db).

At the moment I don't have an idea why svn update was failing.

In case this happens again, try to run `svn cleanup' from the root checkout (/usr/ports) to cleanup possible failures, if this does not work a quick cross check can be done with svnlite (stripped down svn 1.8 in FreeBSD 10 base).
Comment 4 Kevin Thompson 2014-09-30 21:53:39 UTC
> I don't think the issue was related to db48-> db5.
I agree, after thinking about it, I don't think the db5 change had anything to do with it, just coincidental I guess.

> In case this happens again, try to run `svn cleanup' from the root checkout (/usr/ports) to cleanup possible failures

As an FYI, I got that error no matter where I was in the file hierarchy - /, /usr/ports, /tmp, /root. I think the failure was during the process that svn does to figure out where it is and to find the closest .svn folder. 

svnlite is a good idea, if I get stuck there again I'll probably use that instead of svn from packages.

If anybody cares to attempt to repro, I guess my only advice would be to downgrade to FreeBSD 10.0-STABLE-p9 rev r269194 and build the indicated apr1 and subversion versions.

I'd close this for now; if someone else sees it again, hopefully one of us will remember or google will find this.
Comment 5 Olli Hauer freebsd_committer 2014-10-26 17:23:55 UTC
Seems the issue was not direct related to the apr update.
Close PR as requested by submitter.
Comment 6 Jan Beich freebsd_committer 2014-11-17 02:05:02 UTC
I'm having similar issue with devel/apr1 built by lang/clang35. It appears any optimization level above -O0 breaks apr_stat() in file_io/unix/filestat.c. Here's a workaround:

--- apr-1.5.1/file_io/unix/filestat.c~
+++ apr-1.5.1/file_io/unix/filestat.c
@@ -297,7 +297,6 @@ APR_DECLARE(apr_status_t) apr_stat(apr_f
         finfo->pool = pool;
         finfo->fname = fname;
         fill_out_finfo(finfo, &info, wanted);
-        if (wanted & APR_FINFO_LINK)
             wanted &= ~APR_FINFO_LINK;
         return (wanted & ~finfo->valid) ? APR_INCOMPLETE : APR_SUCCESS;
     }

Will try again after 11.0-CURRENT imports clang 3.5.x if the issue persists.
Comment 7 Dimitry Andric freebsd_committer 2014-11-27 00:40:55 UTC
(In reply to Jan Beich from comment #6)
> I'm having similar issue with devel/apr1 built by lang/clang35. It appears
> any optimization level above -O0 breaks apr_stat() in
> file_io/unix/filestat.c.

It's a bug in one of the llvm optimizers, introduced in llvm r210006.  I reported this upstream, and they have reverted the change for now:

http://llvm.org/viewvc/llvm-project?rev=222856&view=rev

I will ensure this is fixed in the upcoming clang 3.5.0 import in base, and I hope upstream will accept it for 3.5.1 too.