warden debug return Segmentation fault error for all different commands

[iranimij]

Version of Warden

0.15.0

Operating System and Installation Method

Mac os 15.3, Apple M3 pro

Describe the Bug

When I run a command like bin/magento inside warden shell, it works fine, but when I run it inside warden debug, it returns the below error

Segmentation fault

Do you have any idea what might be the issue?

Magento version: 2.4.7-p2
all commands in warden debug return the error
I am using docker desktop

To Reproduce

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected Behavior

No response

Additional context

No response

[bap14]

@iranimij Can you please add more details? The details you provided in the Warden Version is actually a Magento version, as Warden only goes up to 0.15.0 as of time of writing.

What specific version of Magento are you using (2.4.7, 2.4.7-p1, 2.4.7-p2, etc.)?
What is the specific command you're running?
What version of Warden are you running?
What MacOS version are you using?
What is your processor (Intel, M1/2/3/4)?
Are you using Docker Desktop, OrbStack, Colima, or some other containerization service?
When was the last time you pulled your PHP image(s) from the repository: warden env pull?

A segmentation fault in the container is rather odd, and I have no issues running the Magento CLI in the debug containers on my system.

[iranimij]

@bap14 I updated the info. Sorry for the missed info
I have different projects on my loca, all projects work fine except this one.

[RenzeD98]

Im experiencing the same issue.

Magento version: 2.4.7-p4
Command: bin/magento (any bin/magento command)
Warden version: 0.15.0
MacOs: Sequoia 15.1.1
Processor: Apple M4
Im using docker desktop

Im experiencing this with all my project.

[hardyjohnson]

I don't see this issue pulling the latest images and doing a fresh install of community edition.

Magento version: 2.4.7-p4
Command: bin/magento module:status (as an example)
Warden version: 0.15.0
MacOs: Sequoia 15.3.1
Processor: Apple M2 Max

Following PHP debug image info:

php -v
PHP 8.3.16 (cli) (built: Jan 14 2025 18:25:29) (NTS gcc aarch64)
Copyright (c) The PHP Group
Zend Engine v4.3.16, Copyright (c) Zend Technologies
    with the ionCube PHP Loader v14.4.0, Copyright (c) 2002-2025, by ionCube Ltd.
    with Zend OPcache v8.3.16, Copyright (c), by Zend Technologies
    with Xdebug v3.4.1, Copyright (c) 2002-2025, by Derick Rethans

[hardyjohnson]

Other possibly relevant questions:

1. What Virtual Machine Manager are you using? (Docker VMM, Apple Virtualization Framework, QEMU)
2. Is Use Rosetta for x86_64/amd64 emulation on Apple Silicon enabled?
3. What does your project .env look like? i.e. what service versions are declared there?
4. Do you have any warden-env.yml overrides or customizations?

[ihor-sviziev]

Hi,
I'm having the same issue, and would like to add more notes:

• OS: macOS 15.3.2 (Apple Silicon) and Ubuntu Linux 24.04 (Intel based) <-- This means it's not ARM-specific bug
• PHP version where we see this issue - 8.1
• On macOS we're using orbStack
• Image where the issue reproduces for us: docker.io/wardenenv/php-fpm:8.1-magento2-xdebug3

The debugger itself is inside the bin/magento file, and starts execution, then it goes to the symfony cli library, and there it crashes. I believe it's an xdebug issue.

---

UPD:
I was also able to reproduce this issue on the following code based on symfony/console lib code (require only symfony/console 6.4.20):
https://github.com/symfony/console/blob/2e4af9c952617cc3f9559ff706aee420a8464c36/Command/Command.php#L75-L77

<?php
require __DIR__ . '/vendor/autoload.php';

$class = \Symfony\Component\Console\Command\CompleteCommand::class;

$name = null;
if ($attribute = (new \ReflectionClass($class))->getAttributes(\Symfony\Component\Console\Attribute\AsCommand::class)) {
    $name = $attribute[0]->newInstance()->name;
}

Console out:

$ php test.php 
Segmentation fault

Next steps:

• Report it to xdebug

[ihor-sviziev]

Reported issue to XDebug https://bugs.xdebug.org/view.php?id=2333

[ihor-sviziev]

@derickr replied in https://bugs.xdebug.org/view.php?id=2333#c7232 :

Xdebug isn't compatible with "ionCube"

https://xdebug.org/docs/compat#compat also states it's not compatible

I tried disabling ioncube with the following line, and issue is gone.

sudo sed -i '/zend_extension/ s/^/;/' /etc/php.d/01-ioncube-loader.ini 

@bap14 @navarr, maybe we can remove ioncube extension from xdebug images?

[bartoszkubicki]

That happens to me even without ionCube.
PHP 8.1.30 (cli) (built: Sep 26 2024 17:35:59) (NTS gcc aarch64) Copyright (c) The PHP Group Zend Engine v4.1.30, Copyright (c) Zend Technologies with Zend OPcache v8.1.30, Copyright (c), by Zend Technologies with Xdebug v3.3.2, Copyright (c) 2002-2024, by Derick Rethans

[ihor-sviziev]

@bartoszkubicki,
My issue was fixed by disabling the ioncube, so I'm not sure how to reproduce your.
Could you please report the issue to xdebug then?

[bartoszkubicki]

In my case, changing Evaluation settings in PHPStorm/PHP/Debug did the job (https://codisfy.com/core-dumped-segmentation-fault-xdebug/). I had them all checked. Play around with them:

I restarted downed containers and up them again to verify how that works with this ioncube and it turned out that with modified settings it doesn't matter anymore

[derickr]

That's not a way to get a possible bug in xdebug fixed.

[bartoszkubicki]

I agree it is a workaround but at least you can use xdebug, that's a big step forward