Github Actions workflow fails with exit code 139 on Dependabot PR

[GabrielCC]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

General

Discussion Details

• we have fairly straight forward CI workflow, that runs unit tests with phpunit, in a docker container
• it's deployed on multiple internal repositories, it was working fine until recently, even for Dependabot generated PR (proper secrets set, etc)

Currently on one of the repo the CI workflow started failing only on Dependabot generated PR's with message:

.....................::error::PHPUnit failed with exit code: 139
Error: Process completed with exit code 139.

If I do a simple change on that specific branch/PR (only one line in the Readme file), the CI workflow passes without issues.

Any hints? Are there undocumented limits regarding Dependabot triggered PR's?

Thanks,
Gabriel

[Suhaib3100]

Exit code 139 indicates a segmentation fault (SIGSEGV) - the process was killed by signal 11 (128 + 11 = 139). This is a memory access violation, not a GitHub Actions limit.

Why This Happens on Dependabot PRs

Dependabot PRs have restricted secret access by default. If your PHPUnit tests or Docker container rely on secrets (database credentials, API keys, etc.), they may fail or behave unexpectedly when those secrets are unavailable.

Common Causes & Solutions

1. Memory-related segfault in PHP

PHP can segfault due to:

• Circular references causing memory exhaustion
• Incompatible extension versions after a dependency update
• OPcache issues in containerized environments

Try adding to your workflow:

env:
  PHP_MEMORY_LIMIT: 512M
  OPCACHE_ENABLE: 0

2. Dependabot updated a dependency that causes the crash

Check what Dependabot changed. If it updated:

• A PHP extension wrapper (like ext-* packages)
• PHPUnit itself
• A database driver

The new version may have a bug or incompatibility.

3. Docker image caching issue

Dependabot PRs may pull a different Docker image layer. Try:

steps:
  - name: Pull fresh image
    run: docker pull your-image:tag --no-cache

4. Secret-dependent code path

If your tests check for env vars and take different code paths:

// This might crash if SECRET is missing and code assumes it exists
$config = getenv('SECRET') ?: throw new Exception('Missing');

Quick Debug

Add this step before PHPUnit to check the environment:

- name: Debug environment
  run: |
    php -v
    php -m
    php -i | grep memory
    echo "Secrets available: \${{ secrets.GITHUB_TOKEN != '' }}"

Why Your Readme Change Fixed It

When you pushed a change, GitHub re-ran the workflow with your push event context instead of Dependabot's context. Your pushes have full secret access, which is why it passed.

To confirm this is the issue, check if your workflow uses pull_request_target instead of pull_request - that would give Dependabot PRs access to secrets.

[LuizAlbar]

Exit code 139 = segmentation fault inside the container, not a GitHub/Dependabot limit.

The key clue is:
✔ Fails only on Dependabot PRs
✔ Passes when you push a normal commit

That almost always points to environment differences, not PHPUnit itself.

Dependabot PR workflows run with a more restricted security context:

Secrets may not be available the same way (especially if coming from forks or certain org settings)

Different dependency versions (because Dependabot is literally changing them)

Cache differences (Composer/npm/docker layer cache)

Native PHP extensions or system libs inside the container crashing due to the upgraded dependency

So what’s likely happening is:
👉 A dependency update from Dependabot is triggering a crash in a PHP extension (xdebug, intl, imagick, etc.) or a native lib inside the container.

Things to check

Which dependency did Dependabot change?
Look at composer.lock diff. Native-related packages are prime suspects.

Disable extensions temporarily
Try running tests with:

php -n vendor/bin/phpunit

or disable xdebug/imagick/etc in the container to see if it stops crashing.

Run the same container locally
Checkout the Dependabot branch and run the exact Docker test command. If it segfaults locally too → 100% dependency/native issue.

Clear caches
Dependabot runs might be missing a cache layer your normal branch has.

Bottom line

This isn’t a hidden GitHub/Dependabot limit. Exit 139 means something in PHP/native land is crashing, and the Dependabot update just exposed it.

Focus on the dependency diff + PHP extensions inside the container. That’s where the bug is.

[ghchen99]

What you’re seeing—PHPUnit failing with exit code 139 only on Dependabot PRs—is almost always a segmentation fault. It’s not a test failure, it’s PHP or an extension crashing. The weird part is that a trivial commit fixes it, which points to something subtle with cached dependencies or the CI environment.

Dependabot PRs can behave a little differently in GitHub Actions: even if they’re internal, the way caches, checkouts, or Docker layers are restored can differ. Often what happens is:

A cached vendor directory (or PHP opcache) from a previous build is restored.

Something about the dependencies on that Dependabot branch—maybe a slightly different package version—doesn’t play nicely with the cached PHP environment.

A tiny new commit forces a rebuild or cache refresh, and suddenly PHP stops segfaulting.

The usual fix is to avoid using old caches for Dependabot PRs, or force a fresh install of dependencies when a Dependabot PR runs. That eliminates the weird segfaults without touching your workflow for normal PRs.