search

JMRI / JMRI

JMRI model railroad digital command & control software
https://www.jmri.org
Other
235 stars 330 forks source link

Jenkins "Build" task failing #4962

Closed bobjacobsen closed 6 years ago

bobjacobsen commented 6 years ago

The Jenkins "Build" task seems to have started failing with jobs 2337 and 2338.

The console log doesn't show much:

headlesstest:
[jacoco:coverage] Enhancing junit with coverage
    [junit] Running jmri.HeadLessTest
    [junit] fork(): Cannot allocate memory
    [junit] AL lib: (WW) alc_initconfig: Failed to initialize backend "pulse"
    [junit] AL lib: (WW) alc_initconfig: Failed to initialize backend "alsa"
    [junit] AL lib: (EE) ALCplaybackOSS_open: Could not open /dev/dsp: No such file or directory
Build step 'Invoke Ant' marked build as failure
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files were found. Configuration error?
Sending e-mails to: jmri-builds@lists.sourceforge.net rgj1927@pacbell.net
[BFA] Scanning build for known causes...
[BFA] No failure causes found
[BFA] Done. 0s
Finished: FAILURE

The key aspect seems to be the "Cannot allocate memory" message.

The cucumber-results.xml file is empty (zero length). JUnit doesn't seem to have written its output file, as the crash occurred while it was running.

pabender commented 6 years ago

I have a feeling this is one of the audio tests I added to the package test in #4956. I just noticed one of those was actually a duplicate, so I submitted #4963 to pull the duplicate out.

In any event, the test that remains had been running in the maven builds, but not in the ant builds, because the maven builds actually ignore the PackageTest files.

pabender commented 6 years ago

Build job 2339 seems to have succeeded.

bobjacobsen commented 6 years ago

Restarting Jenkins fixed this. It was using a huge amount of memory. Maybe we're leaving something running?

pabender commented 6 years ago

Yes, there are a huge number of threads left open by tests (see #4818) and they consume a huge about of memory. I made a dent in the problem, but I defintely didn't resolve this completely.

The root cause is actually with the OpenLCB tests but until https://github.com/openlcb/OpenLCB_Java/issues/119 is resolved, there isn't much we can do about that. Due to the day job, I haven't had time to look into this other than to identify the problem. Perhaps @balazsracz or @KenC57 might be able to work on the OpenLCB issue more quickly than I will be able to.