PHP 8.3 with libcurl 7.29.0 segmentation fault

[thg2k]

Description

I know this is a bit late to the party, but as the last 8.3 bugfix release is about to happen, I was wondering if we can get this segfault fixed.

The reason is very straightforward, the multi init should be followed by at least one curl_multi_add_handler before it is destroyed, otherwise the library crashes in the curl_multi_cleanup function.

I'd happy to provide a PR but I will need a few more days, if somebody has a quick fix idea please go ahead.

For the records, this bug exists since at least PHP 7.2.

The following code:

<?php
$ch = curl_multi_init();
unset($ch);
print "EOF\n";

Resulted in this output:

Segmentation fault (core dumped)

But I expected this output instead:

EOF

PHP Version

PHP 8.3.29 (cli) (built: Dec 29 2025 17:10:47) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.29, Copyright (c) Zend Technologies

Operating System

No response

[thg2k]

@bukka As you announced already the branching for the final 8.3 release, do you think we can get a fix for this in?

[ndossche]

Doesn't reproduce for me. This may be dependent on the libcurl version, or even be a curl bug instead of a PHP bug.
And since that curl version is very old, why fix it in PHP? Is this a situation like libxml where people use outdated software or the distro ships outdated software with tons of bugs?

[ndossche]

Not bukka but I'll give my opinion:

do you think we can get a fix for this in?

Why does this bug deserve an exception to the rules?

[bukka]

If this was a crash in PHP (which this might not be as mentioned by Niels), it could still go to 8.3 as per our new policy https://github.com/php/policies/blob/main/release-process.rst#bug-fix-and-security-releases :

Security fixes, compatibility build fixes, fixes to address regressions introduced during a normal bug fix release, and fixes for crashes like use after free or segmentation faults.

But please note that this won't trigger the release until there is a security or regression fix as per:

Release only when there is a security issue or regression issue to address.

[bukka]

So in other words it doesn't require exception and it could get normally merged and wait till there is a security release. This applies only for 8.3. For 8.2 (4th year), the rules are a bit more strict and would require RM approval.

[thg2k]

Doesn't reproduce for me. This may be dependent on the libcurl version, or even be a curl bug instead of a PHP bug. And since that curl version is very old, why fix it in PHP? Is this a situation like libxml where people use outdated software or the distro ships outdated software with tons of bugs?

It is dependent on the libcurl version, it has to be exactly vanilla 7.29.0, as this was fixed in 7.30.0. But PHP 8.3 claims to be compatible with it (minimum version was bumped in 8.4 from 7.29.0 to 7.61.0), so.. I was wondering if it made sense to add a workaround.