Date: Fri, 7 Jul 2017 00:13:57 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Li-Wen Hsu <lwhsu@freebsd.org> Cc: "freebsd-java@freebsd.org" <freebsd-java@freebsd.org> Subject: Re: Some weird errors in Jenkins on post-ino64 -CURRENT Message-ID: <20170706211357.GJ1935@kib.kiev.ua> In-Reply-To: <CAKBkRUzJpM9Dta8C9nUEjE4bq7Cc9TAqb8Dt__YH1n2F1LhJTA@mail.gmail.com> References: <CAKBkRUzJpM9Dta8C9nUEjE4bq7Cc9TAqb8Dt__YH1n2F1LhJTA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 06, 2017 at 01:09:01PM +0100, Li-Wen Hsu wrote: > Hi -java, > > With FreeBSD cluster update, we migrated several Jenkins builders to > post-ino64 -CURRENT, but since then, we encountered several mysterious > errors. > > What happens here is Jenkins (which uses SVNKit, subversion client library > written in Java) refuses checkout codes from svn.freebsd.org. Some logs > like these: > > https://ci.freebsd.org/job/FreeBSD-head-amd64-build/3674/console > > 00:00:10.759 ERROR: Failed to check out svn://svn.freebsd.org/base/head > 00:00:10.760 org.tmatesoft.svn.core.SVNException: svn: E200030: BUSY > > https://ci.freebsd.org/job/FreeBSD-head-amd64-build/3676/console > > 00:00:00.104 ERROR: Failed to check out svn://svn.freebsd.org/base/head > 00:00:00.104 org.tmatesoft.svn.core.SVNException: svn: E155018: > '/jenkins/workspace/FreeBSD-head-amd64-build/src' already exists and is not > a directory > > I've talked this with Ed at BSDCan, and we suspect this is related to > ino64. Normally, recompiling the binaries should solve the problem. But I > have tried to recompile everything that Jenkins depends on but it still > doesn't work. I also tried to use openjdk7 to build a new openjdk7-version > bootstrap-openjdk but it still doesn't help. > > This is reproducible with latest -CURRENT snapshot, installing Jenkins and > checking out codes from svn.freebsd.org. > > Any ideas, suggest what to test next? There is no way around it other than debug the problem. In other words, trace the error back to the point of occurence, using sources and reasoning about the code paths. Sometimes you might cheat by looking for the known problematic usages in the source, like locally redefining struct stat. I do not expect that JVM/JDK code does that, but who knows. Also, it might be useful to look around in ktrace, watching for the syscalls preceeding the failure. But all such measures are secondary to normal debugging process.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170706211357.GJ1935>