Http fake call returning exception causes SIGSEV with XDebug enabled

[eleftrik]

Laravel Version

11.3.1

PHP Version

8.3.6

Database Driver & Version

No response

Description

Laravel 11 brand new application (same behavior with Laravel 10).

The following test

<?php

use Illuminate\Support\Facades\Http;

it('should throw an Exception', function () {
    Http::fake([
        '*' => fn () => throw new Exception()
    ]);

    expect(fn () => Http::get('www.example.com'))
        ->toThrow(Exception::class);
});

• passes with XDebug disabled
• does not pass with XDebug enabled, returning Process finished with exit code 139 (interrupted by signal 11:SIGSEGV).

php.ini configuration:

memory_limit=512M
upload_max_filesize=2M

; XDebug
xdebug.mode=develop,coverage
zend_extension=/Applications/Herd.app/Contents/Resources/xdebug/xdebug-83-x86.so

Sorry, I don't know if it's related to Laravel or is more about Pest / PHPUnit. Could be related to sebastianbergmann/phpunit#5809?

I have a couple of Laravel 10/11 applications with a bunch of similar tests (the one above is a simplified example) and they passed without problems, until a couple of weeks ago.

I could disable XDebug, but I need it enabled to run code coverage.

Thank you for any hints.

Steps To Reproduce

laravel new test --pest --no-interaction

# write the above test

# enable XDebug

php artisan test

[driesvints]

until a couple of weeks ago.

Could you maybe pinpoint the exact PHP, Laravel, PHPUnit or Pest version that introduces this issue?

[eleftrik]

until a couple of weeks ago.

Could you maybe pinpoint the exact PHP, Laravel, PHPUnit or Pest version that introduces this issue?

Hi @driesvints, thanks for the feedback.
I don't know exactly which version introduced this issue. I can report versions I'm experiencing this issue with:

PHP: 8.3.6
Laravel: 11.3.1 / 10.48.7
Pest: 2.34.7
XDebug: 3.3.1

Please let me know if I answered what you need.

Thanks

[driesvints]

What versions did you come from? You specifically mention the issue only popped up in recent weeks. Which versions were you at before that?

[eleftrik]

@driesvints I checked out my codebase to old commits, but the issue is still happening, so I don't know who the culprit is...

I just tried to use PHP 8.3.6 + XDebug 3.3.2 (just release, I think), but the segmentation fault issue is still happening.
I'm sorry, I can't provide further useful details.

Anyway, it should be possible to reproduce the issue as I reported.
Are you able to run that test with XDebug enabled in a Laravel brand new application?
I'm using Herd 1.6.0 with its bundled XDebug.

Thanks

[eleftrik]

@driesvints Upon further investigation, I found the exact place where problems start only when XDebug is enabled (but I don't know why):

vendor/guzzlehttp/guzzle/src/Client.php - line 333

        try {
            return P\Create::promiseFor($handler($request, $options)); // <----------- here something causes infinite recursion?
        } catch (\Exception $e) {
            return P\Create::rejectionFor($e);
        }

[driesvints]

@eleftrik I found this which seems similar: guzzle/guzzle#942

Can you change xdebug.remote_autostart=0 in your php.ini and try again?

[eleftrik]

@eleftrik I found this which seems similar: guzzle/guzzle#942

Can you change xdebug.remote_autostart=0 in your php.ini and try again?

xdebug.remote_autostart=0 didn't solve, but thanks for the Guzzle link, because you gave me a big hint! 🥳

I changed from xdebug.mode=develop,coverage to xdebug.mode=debug,coverage and now everything works as expected.

Thank you very much.

[mszabo-wikia]

@eleftrik you're very likely running into XDebug feature 2222. XDebug 3.3.0 and newer made it so that all locals alongside the stack of the last eight thrown exceptions are kept alive in memory until the process or request finishes if xdebug.mode=develop, breaking standard destructor semantics.