Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug]: bundled Xdebug for PHP 8.4 — coverage memory leak

Open
  • Is something wrong?
#1,753 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
64/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
php
Domain
tooling

Research direction

No repository file, test, or entry point is named. Start by locating the packaging configuration for the PHP 8.4 Xdebug extension and verify which bundled version Herd 1.30.1 uses. Done means the managed PHP 8.4 bundle uses a stable Xdebug version containing the cited fixes, with coverage memory behavior checked against the reported case.

Written by the indexing model from the issue text.

Description

macOS
Platform

macOS

Operating system version

macOS 26.6.2 (25G83)

System architecture

ARM64 (M1, M2, etc)

Herd Version

1.30.1 (Build 67)

PHP Version

8.4.23

Bug description

Herd 1.30.1 on Apple Silicon still bundles Xdebug 3.4.0alpha2-dev for PHP 8.4.

Xdebug fixed a known code coverage memory leak in version 3.4.2:

I observed substantial memory growth during Pest coverage runs. In a controlled comparison using the same PHP 8.4.23 binary and two parallel workers, the bundled Xdebug reached approximately 1,740 MiB physical footprint per worker after 43 seconds. With a separately compiled Xdebug 3.4.2, the workers used approximately 348 and 249 MiB at the same point.

This suggests an issue with the older bundled Xdebug, although I have not established that the specific upstream bug above explains the entire difference.

Could you update the bundled PHP 8.4 Xdebug extension to a stable version containing these fixes? I would prefer to keep using Herd’s managed extension.

Steps to reproduce

No response

Relevant log output
Dominant language
No language data
Stars
123
Forks
1
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from beyondcode/herd-community

All issues in beyondcode/herd-community

Similar issues

More DevTools issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.