Debug build image collaboration with PHP internals

[ramsey]

This has been discussed several times already (#530, #709, #879, and #1364), and I think it's worth discussing again in light of a recent request posted to the PHP internals mailing list.

I can't speak for the entire PHP internals community, but I can say that PHP internals resources are stretched thin, and so we (speaking primarily for myself, though I'm sure others share this sentiment) are incredibly grateful to the community here at docker-library/php for providing and maintaining these images. This is an incredibly valuable resource for the greater PHP community. Thank you!

Since internals has limited resources and expertise in this area, I'd like to gauge this community's (i.e., docker-library/php) interest in collaborating with PHP internals to provide images with debug symbols. These images will be extremely helpful for those testing, performing QA, reporting bugs, reproducing bugs, etc. Since you already have the infrastructure and expertise in creating and maintaining these images, it would significantly reduce the burden on PHP internals to maintain.

The full discussion thread for this is available here: https://news-web.php.net/php.internals/125386

Instructions for joining and posting to the mailing list are available here, if you'd like to chime in: https://www.php.net/mailing-lists.php

Thanks for considering this!

[faizanakram99]

You can also view the whole thread here https://externals.io/message/125386

[morrisonlevi]

For those who are not aware, there are two kinds of "debug" things for PHP.

1. There are PHP debug builds which aren't optimized, do extra runtime checks, and have a different ABI than non-debug builds. These are meant for development, or sometimes for figuring out the root causes of bugs when you hit them.
2. There are optimized builds but with debug symbols. The dbgsym version should be the same core build as the optimized one. Roughly, it's the state of the optimized build just before symbols are stripped out.

Both are valuable to the community.

If I had to prioritize one myself, I'd pick #2. You should be able to take a crash dump from php:8.3-fpm and put it into an image that stems from php:8.3-fpm-dbgsym (or something) and inspecting the dump and such should generally Just Work.

[danog]

A third kind of "debug" build would be an ASAN/MSAN build, which is a debug build (1) compiled with clang and MSAN or ASAN (so actually two more types of builds).

Generally I'd agree that a simple php:8.3-fpm-dbgsym debug build with the symbols would be enough to simplify debugging, a reproducer can then be obtained OOB with a custom ASAN build, with the info extracted from the coredump and the debug symbols.

[dunglas]

Having something like php:8.3-zts-dbgsym would help track issues reported to the FrankenPHP repository (which are often upstream PHP or extensions bugs) a lot too!

[tianon]

Interesting, thanks for raising this ❤️

We'd love to support an even larger matrix of builds, but our current harsh reality is that the combination of supported PHP major versions (8.1, 8.2, 8.3, 8.4-rc) × supported variations (apache, cli, fpm, zts) × supported distribution versions (Debian Bookworm + Bullseye, Alpine 3.20 + 3.19) is already extremely heavy, and that's not even considering the number of supported architectures. 😬

In other words, we effectively currently build PHP no less than 84 times when we flesh out that matrix (and if we include the architectures, that's 654 individual PHP builds). 😭

What this means is that we tend to be extremely cautious about supporting more variations. 🙈

With all that as background, I think the only way we can constructively support what's being requested here is by somehow shrinking that matrix at the same time -- for example, if there were some way we could build all of apache, cli, fpm, and zts into a single "fat" image (even if it takes a little bit longer to build such that the total build time is still less than the build time of all four individually) and get some help on exactly what files to copy into each of the variants we currently support (so that we could build our variations more similar to how distributions do, cherry-picking files into specific "packages"/images), then adding an explicit variant above those that just adds the debug symbols, or a variant that adds the unstripped binaries instead of the stripped ones, etc would be much more doable/sustainable/discussable. 🙇 ❤️

[danog]

I really don't see the need for compromises like fat builds, as at least when considering dbgsym builds we're not talking about doubling the build time (which by itself also shouldn't be a blocker, since this is all needed stuff), but simply starting out with dbgsym builds, and then creating non-dbgsym builds by stripping the dbgsym builds.

[pereorga]

@tianon So the matrix of supported versions includes some older Alpine and Debian releases with newer PHP versions. I was wondering what the rationale is behind supporting these older OS releases with more recent PHP versions (e.g., Bullseye with PHP 8.4, or Alpine 3.19 with PHP 8.4). Doesn't this increase the maintenance?

Is there any way to access detailed usage stats for these images, like the number of pulls per specific variant or version? Otherwise, could you share this information?