Thanks, Kirk. Any expert on the OS images and pipeline could jump in to answer Kirk's questions and help?
Thanks, Alberto ________________________________ From: Kirk Lund <kl...@apache.org> Sent: Tuesday, October 26, 2021 7:26 PM To: dev@geode.apache.org <dev@geode.apache.org> Subject: Re: Test failures on Windows with insufficient memory for the JRE while running distributed tests PS: I should also mention that the *windows-gfsh-distributed* test target is only run on Windows (never on Linux). It might be useful to try getting windows-gfsh-distributed running on LInux to see if it hits the same issue on that OS. This would also require some help from a pipeline expert. On Tue, Oct 26, 2021 at 10:22 AM Kirk Lund <kl...@apache.org> wrote: > Hi Alberto, > > 32 kb is a very small amount of memory, so I don't think it's related to > Java Heap. Based on what little I've read today, I think a failure in > ChunkPool::allocate is probably related to either *running out of swap > space or running out of address space in a 32 bit JVM*. Since the > failures are OS specific, I would suspect the machine image we use for > Windows to be involved. > > I also notice that this ChunkPool::allocate failure is only occurring for > the Gfsh distributed tests which is the only job run on Windows that uses > Gradle support for *JUnit Categories*. The Gradle target is > distributedTest which we have configured with "*forkEvery 1*" which > causes every test class to launch in a new JVM. Gradle implements JUnit > 4 Category filtering by launching every test class to check the Categories > and then either executes the tests or terminates without running any > depending on the Categories. > > Some things I would check (or ask others about): > > *Is the harddrive space much smaller than what's available to the JVM(s) > on Linux?* > > *Do the Gfsh distributed tests on Windows leave behind more artifacts on > the harddrive than other test targets?* > > *Is it possible that the tests are using a 32-bit JVM on Windows? Or maybe > the tests are spawning Gfsh process(es) using a 32-bit JVM instead of > 64-bit?* > > *Are we running the Gfsh distributed tests in parallel (which might > exacerbate harddrive swapping or memory consumption)?* > > Unfortunately, I don't know what most of the options in > jinja.variables.yml are about. I think it would be best to get help from an > expert in the OS images and pipeline details. > > Cheers, > Kirk > > On Tue, Oct 26, 2021 at 12:59 AM Alberto Gomez <alberto.go...@est.tech> > wrote: > >> Hi, >> >> I am having issues with insufficient memory for the Java Runtime >> Environment when running some tests on the CI under Windows from the >> following PR : >> https://github.com/apache/geode/pull/7006 >> >> The tests never fail under Linux. >> >> This is the error I get for some VMs: >> >> [vm4] # There is insufficient memory for the Java Runtime Environment to >> continue. >> [vm4] # Native memory allocation (malloc) failed to allocate 32744 bytes >> for ChunkPool::allocate >> >> I have reduced the amount of resources used originally by the tests but >> still I am not able to get a clean execution. >> >> I do not know if it is a matter of changing the parameters for the >> windows execution in ci/pipelines/shared/jinja.variables.yml or if there is >> anything else to consider. >> >> I would appreciate if someone from the community could help me >> troubleshoot this issue. >> >> Thanks in advance, >> >> Alberto >> >> >>
