When i try to run tests in parallel using
xcodebuild build-for-testing & xcodebuild test-without-buildingdpe.qa,
We've been experiencing very similar issues as well since moving up to Xcode 11 (both on Mojave and Catalina).
We are seeing deep DVTFramework and other CoreFoundation memory exceptions that are so far removed from user level code, I'm getting the funny feeling that the runtime environment is experiencing both memory and thread exhaustion. SInce we never *ever* saw any crashes this sever prior, I suspect the new iOS 13 APIs are expecting a less constrained environment. I have no formal proof for this assertion, but this pattern matches previous behavior I have seen on other *NIX based environments.
Now, with that being said, for S&Gs we temporarily moved our large amount of XCTest Classes to run serially and they all run just fine. Even on a poky little Mac Mini. Unfortunately an integration takes hours, not minutes. So this isn't a long term solution for us. We can run in parallel on our new spiffy Mac Book Pros just fine. However, even there we're seeing unexpected behavior of a Simulator Clone "failing" to start and thus gives us a false negative report at the end of the integration.
My suggestion is to dig into the run logs and see if you can find the actuall crash. Through the Bot system, I can navigate into the failed integration and actually download the entire .tgz of build/test logs. There should be 1+ .crash logs in that bundle that will immediatly give you the stack dump for the crash.
Yes, Tested with Xcode 11.3 and Xcode 11.4 beta. It is very much reproducible when building apps with a build-for-testing option.