paratest: Occasional "This worker has crashed." errors

I am having the same issue on gitlab… works perfectly fine locally =`[ Any idea of what could this be?

Seems like I finally found a setup to reproduce the issue:

I created 5 classes with the following content:

class CrashTest extends \PHPUnit\Framework\TestCase
{
    /**
     * @dataProvider repeat_dataProvider
     */
    public function test_repeat(): void
    {
        $dir = "/tmp/foo";
        if (!file_exists($dir)) {
            mkdir($dir);
        }

        // all processes write to the _same_ file
        $file = $dir."/bar.php";

        file_put_contents($file, "<?php return []; ?>");

        // all processes include that file - increasing the likelyhood of "reading while being written"
        include $file;

        $this->assertTrue(true);
    }

    public function repeat_dataProvider(): \Generator
    {
        for ($i = 0; $i < 100; $i++) {
            yield "Test $i" => [];
        }
    }
}

Crash/
├── CrashTest.php
├── CrashATest.php
├── CrashBTest.php
├── CrashCTest.php
└── CrashDTest.php

And then ran paratest on the Crash directory with 5 parallel processes:

www-data:/var/www/atmo# vendor/bin/paratest -p 5 --runner=WrapperRunner Crash/
Running phpunit in 5 processes with /var/www/atmo/vendor/phpunit/phpunit/phpunit

Configuration read from /var/www/atmo/phpunit.xml


In WorkerCrashedException.php line 36:

  The command "'/var/www/atmo/vendor/phpunit/phpunit/phpunit' '--configuration' '/var/www/atmo/phpunit.xml' '--no-logging' '--no-coverage' '--printer' 'ParaTest\Runners\PHPUnit\Worker\NullPhpunitPrinter' '--log-junit' '/tmp/PT_djAoHa' '/var/www/atmo/Crash/CrashCTest.php'" failed.

  Exit Code: 135(Bus error: "access to undefined portion of memory object")

  Working directory: /var/www/atmo

  Output:
  ================


  Error Output:
  ================


paratest [--bootstrap BOOTSTRAP] [--colors] [-c|--configuration CONFIGURATION] [--coverage-clover COVERAGE-CLOVER] [--coverage-cobertura COVERAGE-COBERTURA] [--coverage-crap4j COVERAGE-CRAP4J] [--coverage-html COVERAGE-HTML] [--coverage-php COVERAGE-PHP] [--coverage-test
-limit COVERAGE-TEST-LIMIT] [--coverage-text [COVERAGE-TEXT]] [--coverage-xml COVERAGE-XML] [--exclude-group EXCLUDE-GROUP] [--filter FILTER] [-f|--functional] [-g|--group GROUP] [-h|--help] [--log-junit LOG-JUNIT] [--log-teamcity LOG-TEAMCITY] [-m|--max-batch-size MAX-B
ATCH-SIZE] [--no-coverage] [--no-test-tokens] [--order-by [ORDER-BY]] [--parallel-suite] [--passthru PASSTHRU] [--passthru-php PASSTHRU-PHP] [--path PATH] [-p|--processes PROCESSES] [--random-order-seed [RANDOM-ORDER-SEED]] [--repeat [REPEAT]] [--runner RUNNER] [--stop-o
n-failure] [--testsuite TESTSUITE] [--tmp-dir TMP-DIR] [-v|vv|--verbose] [--whitelist WHITELIST] [--] [<path>]

In my specific case it’s indeed the views that are problematic. I solved the issue by appending the paratest token to the compiled directory, i.e.

// config/view.php

<?php

$token = getenv("TEST_TOKEN") ?: null;
$dir = storage_path('framework/views');
if($token){
    $dir .= "_$token";
}

return [

    /*
    |--------------------------------------------------------------------------
    | View CloudStorage Paths
    |--------------------------------------------------------------------------
    |
    | Most templating systems load templates from disk. Here you may specify
    | an array of paths that should be checked for your views. Of course
    | the usual Laravel view path has already been registered for you.
    |
    */

    'paths' => [
        realpath(base_path('resources/views')),
    ],

    /*
    |--------------------------------------------------------------------------
    | Compiled View Path
    |--------------------------------------------------------------------------
    |
    | This option determines where all the compiled Blade templates will be
    | stored for your application. Typically, this is within the storage
    | directory. However, as usual, you are free to change this value.
    |
    */

    'compiled' => $dir,
];