Would this be correct? I want to run it as part of presubmit. I updated libjffi-jni as well, with apt-get. Still encountering the same issue. https://gradle.com/s/wlaql5cxpb3lk
./gradlew :javaPreCommit --stacktrace --scan -Dcom.datastax.driver.USE_NATIVE_CLOCK=false On Mon, Nov 5, 2018 at 9:37 AM Alexey Romanenko <[email protected]> wrote: > Alex, could you check and update (if necessary) the package "libjffi-jni” > on your system? > Other potential workaround could be to try to run it with > “ -Dcom.datastax.driver.USE_NATIVE_CLOCK=false" > > On 31 Oct 2018, at 23:40, Kenneth Knowles <[email protected]> wrote: > > If I am reading it right, the segfault is not in the Java compiler, but in > the method > https://docs.datastax.com/en/drivers/java/2.1/com/datastax/driver/core/Native.html#isGettimeofdayAvailable-- > called when HIFIO is testing with embedded Cassandra. > > Kenn > > On Wed, Oct 31, 2018 at 2:59 PM Alex Amato <[email protected]> wrote: > >> Personally, I don't care too much if there is a test which fails often. I >> would just like to track these tests and have some test target I can run >> locally which will run most of the tests. >> >> So if this can't be easily fixed, If we could have a separate gradle >> target where we blacklist a few problem tests, that would help productivity >> a lot. Then you could rely on that target for running locally, and rely >> jenkins to run the rest in your PR. >> >> On Wed, Oct 31, 2018 at 1:07 PM Ruoyun Huang <[email protected]> wrote: >> >>> +1 to have inputs regarding this failure Alex raised. >>> >>> javaPreCommit never worked on my local machine in past a few weeks. >>> This hadoop build target has been the main issue. >>> >>> On Tue, Oct 30, 2018 at 5:31 PM Alex Amato <[email protected]> wrote: >>> >>>> Hello, >>>> >>>> I keep encountering issues with the precommit process, and this >>>> particular test seems to keep failing. >>>> >>>> :beam-sdks-java-io-hadoop-input-format:test >>>> >>>> Sometimes it fails with SIGSEGV errors in the java compiler (attached >>>> log). >>>> >>>> I disabled the gradle daemon, which got me past some OOMing issues. I >>>> was wondering if there is some other steps that I need to do in order to >>>> get a more consistent testing experience. Any other advice? >>>> >>>> I also had a very different failure another run. build_scan >>>> <https://scans.gradle.com/s/iw6twrkb7llmu/failure?openFailures=WzBd&openStackTraces=WzEse31d#top=0> >>>> link. This was more vague, mentioning just a possible "test process >>>> configuration" issue. >>>> >>>> *./gradlew --version* >>>> ------------------------------------------------------------ >>>> Gradle 4.10.2 >>>> ------------------------------------------------------------ >>>> >>>> Build time: 2018-09-19 18:10:15 UTC >>>> Revision: b4d8d5d170bb4ba516e88d7fe5647e2323d791dd >>>> >>>> Kotlin DSL: 1.0-rc-6 >>>> Kotlin: 1.2.61 >>>> Groovy: 2.4.15 >>>> Ant: Apache Ant(TM) version 1.9.11 compiled on March 23 2018 >>>> JVM: 1.8.0_161-google-v7 (Oracle Corporation 25.161-b01) >>>> OS: Linux 4.17.0-3rodete2-amd64 amd64 >>>> >>>> >>>> Thanks for taking a look, >>>> Alex >>>> >>>> >>> >>> -- >>> ================ >>> Ruoyun Huang >>> >>> >
