Wrong exit code 11 ('No errors found') on projects with large vendor autoload (caused by an issue from php-src)

[alies-dev]

Description

Psalm returns exit code 11 even when reporting "No errors found!" on a project with a large vendor/ dependency tree. This affects both regular analysis and taint analysis. A fresh Laravel 12 project with the same Psalm version returns exit 0 correctly.

This is NOT taint-specific — regular psalm (without --taint-analysis) also returns exit 11 on the same project.

Psalm version

Psalm 6.15.1 (28dc127af1b5aecd52314f6f645bafc10d0e11f9)
PHP 8.4.18 (tested with and without JIT — same result)

Reproduction

Fresh Laravel 12 — exit 0 (correct):

composer create-project laravel/laravel psalm-test
cd psalm-test
composer require --dev vimeo/psalm:^6.15
vendor/bin/psalm --init
vendor/bin/psalm --taint-analysis --no-cache --no-progress
# No errors found!
# EXIT: 0 ✅

Large Laravel project — exit 11 (incorrect):

Using a minimal psalm-taint.xml that scans a single trivial file:

<?xml version="1.0"?>
<psalm
    xmlns="https://getpsalm.org/schema/config"
    errorLevel="1"
    resolveFromConfigFile="true"
>
    <projectFiles>
        <file name="psalm-taint-empty.php"/>
        <ignoreFiles>
            <directory name="vendor"/>
        </ignoreFiles>
    </projectFiles>
</psalm>

The scanned file is trivial:

<?php

declare(strict_types=1);

function psalmTaintTest(): string
{
    return 'hello';
}

php -d memory_limit=-1 vendor/bin/psalm --config=psalm-taint.xml --no-cache --no-progress
# No errors found!
# Psalm was able to infer types for 100% of the codebase
# EXIT: 11 ❌

Same result without --taint-analysis:

php -d memory_limit=-1 vendor/bin/psalm --config=psalm-taint.xml --no-cache --no-progress
# No errors found!
# EXIT: 11 ❌

Key differences between the two projects

	Fresh Laravel	Large project
Exit code	0 ✅	11 ❌
Memory usage	316 MB	672 MB
Composer packages	~60	~200+
Errors shown	"No errors found!"	"No errors found!"

Additional observations

• Exit code 11 is not a signal (not 139/128+11) — Psalm returns it intentionally
• Tested with JIT disabled — same result
• With --debug flag: sometimes shows exit 0 and "No errors found!" (inconsistent)
• The error is consistent regardless of which project file is scanned (tested with controllers, services, routes, and a trivial standalone file)
• The bug appears to be triggered by the size/complexity of the Composer autoloader, not the scanned files themselves

Expected behavior

Exit code 0 when "No errors found!" is reported.

Actual behavior

Exit code 11 with "No errors found!" on projects with large vendor dependency trees.

[alies-dev]

Additional confirmation: This affects all Psalm modes on this project, not just taint analysis:

# Regular analysis (with baseline, plugins, stubs)
$ php -d memory_limit=-1 vendor/bin/psalm --config=psalm.xml --no-suggestions
# Scanning files... 3387 / 3387...
# exit code 11

# Taint analysis (separate minimal config — no baseline, no plugins, no stubs)
$ php -d memory_limit=-1 vendor/bin/psalm --show-snippet --config=psalm-taint.xml --taint-analysis
# Scanning files... 3387 / 3387...
# exit code 11

Both show no error output but return exit code 11. The psalm.xml config includes an errorBaseline, plugins, and stubs, while psalm-taint.xml is a minimal config with none of those.

[alies-dev]

Root cause found: JIT segfault masked by PsalmRestarter

The exit code 11 is actually a segfault (SIGSEGV = signal 11) in the child process, masked by PsalmRestarter.

Proof

When all required opcache settings are pre-set via CLI flags (so PsalmRestarter does NOT restart):

$ php -d memory_limit=-1 \
  -dopcache.enable=1 -dopcache.enable_cli=1 -dopcache.jit=1205 \
  -dopcache.validate_timestamps=0 -dopcache.file_update_protection=0 \
  -dopcache.jit_buffer_size=128M -dopcache.max_accelerated_files=1000000 \
  -dopcache.interned_strings_buffer=64 -dopcache.jit_max_root_traces=100000 \
  -dopcache.jit_max_side_traces=100000 -dopcache.jit_max_exit_counters=100000 \
  -dopcache.jit_hot_loop=1 -dopcache.jit_hot_func=1 -dopcache.jit_hot_return=1 \
  -dopcache.jit_hot_side_exit=1 -dopcache.jit_blacklist_root_trace=255 \
  -dopcache.jit_blacklist_side_trace=255 -dopcache.optimization_level=0x7FFEBFFF \
  -dopcache.preload= -dopcache.log_verbosity_level=0 -dopcache.save_comments=1 \
  -dopcache.restrict_api= -dopcache.memory_consumption=448 \
  vendor/bin/psalm --config=psalm-taint.xml --taint-analysis --no-cache --no-progress
# EXIT: 139 (= 128 + SIGSEGV)

When Psalm's default behavior kicks in (restart with JIT settings):

$ php -d memory_limit=-1 vendor/bin/psalm --config=psalm-taint.xml --taint-analysis --no-cache --no-progress
# "No errors found!"
# EXIT: 11 (= raw SIGSEGV signal number from child process)

What's happening

1. PsalmRestarter detects opcache settings mismatch → restarts child process with JIT-optimized settings
2. Child process runs Psalm, prints "No errors found!", then segfaults during cleanup/shutdown
3. Parent process captures exit code as 11 (the raw signal number, not 128+11)
4. The output from the child ("No errors found!") gets printed, but the exit code is wrong

Environment

• PHP 8.4.18 (Apple Silicon / arm64)
• Psalm 6.15.1
• Xdebug fully disabled (not loaded)
• Large Laravel project (~200+ composer packages)

Related

This is related to #11434 — the JIT settings forced by PsalmRestarter are causing a JIT segfault on this codebase. The segfault likely happens during PHP shutdown after Psalm completes, which is why the analysis output appears correct.

This may also be a PHP JIT bug (on arm64) rather than a Psalm bug per se, but Psalm's PsalmRestarter both triggers it (by forcing JIT settings) and masks it (by returning raw signal number instead of 128+signal).

[weirdan]

You may want to reduce the testcase and report it to the upstream project: https://github.com/composer/xdebug-handler. The code that causes this is very likely proc_close(), which is known to produce unreliable output when the child process ends with a signal.

[alies-dev]

Thanks @weirdan -- great point. I'll report this upstream to composer/xdebug-handler and open a PR there so all consumers benefit.

[alies-dev]

UPD: composer/xdebug-handler#161 composer/xdebug-handler#162 (It seems like I need help to make this PR merged 😂 - or should I fixed it in PHP sources? 🤣)

[alies-dev]

UPD: http://composer/xdebug-handler#161 changed rejected: composer/xdebug-handler#162 (comment)