Dan allen says:
A quick google search led me to conclude that this is a bug in libzip when the application runs out of memory.
"What happend I think is application has run out memory (machine memory not JVM max size) and looks like method of libzip does not check return value of malloc and receive signal 11."
That could indicate that you are hitting a memory issue in Arquillian. Try increasing your memory and see if the test runs to completion. Then reduce again. If that confirms the error, the next step is trying to figure out what is eating the memory.
There's another point to consider. Arquillian integrates with containers, and unfortunately inherits their classloader leaks. If you are using an embedded container, there is a very good chance that the constant stopping and starting of the container or deploying and undeploying is chewing up memory.
There are two known solutions to this problem atm (that I'm aware of):
- Fork the test process (surefire setting)
- Restart the container every n deployments (arquillian.xml setting)
There are a few open issues regarding memory constraints. Here's one related to Tomcat: https://issues.jboss.org/browse/ARQ-629
Btw, what container are you using?