This message was deleted.
# community-support
s
This message was deleted.
t
my only idea right now is that the command line is huge. This is a CI job and we collect many dozens of fully qualified paths to test tasks and invoke them all at once. Could it be too long? Is there a max length? Another fact: this is happening with AGP 7.1, but wasn't happening with 7.0
d
I usually see these error when the test executor crashed on CI. The configuration hint is misleading in those scenario. I get a lot more of those on Windows than macOS/Linux/FreeBSD. I haven’t looked too deeply in what is causing the crash but most likely a memory leak/out of memory issue causing the test executor to cash. That is just an assumption as it’s flaky 😞 I can’t say for AGP but if the situation is flaky, it may be a similar issue as I’m experiencing. In some of my research, some systems will abort non-essential/memory hungry process under memory pressure. That could also be a reason. The next step in debugging this, if the situation is flaky (hinting toward memory issues), would be to look at the total memory consumption on the CI agent (not Gradle) to see if the system is under pressure which could result in a global out of memory scenario for all process. Of course, there should be swapping happening but some CI setup recommend disabling swapping to avoid crawling the system to a halt.
e
exit code 134 = killed by signal 6 = SIGABRT = JVM itself is in a bad state. if it left behind
hs_err_pid*.log
file, that may provide hints as to what went wrong
t
thanks y'all, that's very helpful
I ran the same job locally and it succeeded. Unfortunately, the build scan was too large to even finish uploading, apparently