View Issue Details

IDProjectCategoryView StatusLast Update
0002333XdebugUncategorizedpublic2025-04-11 10:18
Reporterisviziev Assigned Toderick  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionno change required 
Product Version3.4.2 
Summary0002333: Segmentation fault while using symfony console with xdebug
Description

Hi,

I noticed that the Magento 2 command line fails with a Segmentation fault when xdebug is enabled (originally reported in https://github.com/wardenenv/warden/issues/843). Once xdebug is disabled, the issue will not be reproduced.
The interesting part is that debug actually works at the beginning, but then fails when the symfony console component initializes and executes the following code https://github.com/symfony/console/blob/6.4/Command/Command.php#L71-L77

I was able to restrict it to the Symfony console component so we can easily reproduce it.

Steps To Reproduce
  1. composer require symfony/console:^6.4
  2. Run the attached PHP file as php test.php
Additional Information

$ php -v
PHP 8.1.32 (cli) (built: Mar 11 2025 22:09:20) (NTS gcc aarch64)
Copyright (c) The PHP Group
Zend Engine v4.1.32, Copyright (c) Zend Technologies
with the ionCube PHP Loader v14.4.0, Copyright (c) 2002-2025, by ionCube Ltd.
with Zend OPcache v8.1.32, Copyright (c), by Zend Technologies
with Xdebug v3.4.2, Copyright (c) 2002-2025, by Derick Rethans

TagsNo tags attached.
Attached Files
xdebug.log (4,689 bytes)
valgrind.log (1,898 bytes)   
==426== Memcheck, a memory error detector
==426== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==426== Using Valgrind-3.24.0 and LibVEX; rerun with -h for copyright info
==426== Command: php test.php
==426== 
==426== Invalid read of size 8
==426==    at 0x46B5DC: zend_observer_fcall_end (in /usr/bin/php)
==426==    by 0x437FFB: execute_ex (in /usr/bin/php)
==426==    by 0x58D91AB: ic_call_function (in /usr/lib64/php/modules/ioncube_loader.so)
==426==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==426== 
==426== 
==426== Process terminating with default action of signal 11 (SIGSEGV)
==426==  Access not within mapped region at address 0x0
==426==    at 0x46B5DC: zend_observer_fcall_end (in /usr/bin/php)
==426==    by 0x437FFB: execute_ex (in /usr/bin/php)
==426==    by 0x58D91AB: ic_call_function (in /usr/lib64/php/modules/ioncube_loader.so)
==426==  If you believe this happened as a result of a stack
==426==  overflow in your program's main thread (unlikely but
==426==  possible), you can try to increase the size of the
==426==  main thread stack using the --main-stacksize= flag.
==426==  The main thread stack size used in this run was 8388608.
==426== 
==426== HEAP SUMMARY:
==426==     in use at exit: 10,961,514 bytes in 80,720 blocks
==426==   total heap usage: 170,290 allocs, 89,570 frees, 55,233,437 bytes allocated
==426== 
==426== LEAK SUMMARY:
==426==    definitely lost: 51,128 bytes in 1,596 blocks
==426==    indirectly lost: 115 bytes in 5 blocks
==426==      possibly lost: 6,017,612 bytes in 44,280 blocks
==426==    still reachable: 4,892,659 bytes in 34,839 blocks
==426==         suppressed: 0 bytes in 0 blocks
==426== Rerun with --leak-check=full to see details of leaked memory
==426== 
==426== For lists of detected and suppressed errors, rerun with: -s
==426== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
valgrind.log (1,898 bytes)   
test.php (303 bytes)   
<?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;
}
test.php (303 bytes)   
Operating SystemmacOS 15.4 (arm), Ubuntu Linux 24.04 (amd64)
PHP Version8.1.30-8.1.39

Activities

isviziev

2025-04-08 10:25

reporter   ~0007230

Note: when running xdebug in disabled mode - script executes successfully.

XDEBUG_MODE=off php test.php

derick

2025-04-08 12:47

administrator   ~0007232

Xdebug isn't compatible with "ionCube". Can you turn that one off to see whether you can still reproduce it? I can't locally.

And your attached xdebug.log also sees a normal debug connection, although your IDE decides to detach without running code (that's an IDE issue).

isviziev

2025-04-08 13:43

reporter   ~0007243

Hi Derick,
Thank you so much for your reply!
I've turned off the ionCube, and the issue is gone.
Thank you so much for a prompt reply!

isviziev

2025-04-08 13:44

reporter   ~0007244

Just wonder... why ioncube adds something to the code that isn't generated by ioncube...
Never mind, it's a question for ionCube, not for xdebug

derick

2025-04-11 10:18

administrator   ~0007245

ionCube changes the executor in PHP. As it's closed source I have no idea what they're doing with it, nor can I check it out.

Glad that the Xdebug crash now went away!

Issue History

Date Modified Username Field Change
2025-04-08 09:19 isviziev New Issue
2025-04-08 09:19 isviziev File Added: xdebug.log
2025-04-08 09:19 isviziev File Added: valgrind.log
2025-04-08 09:19 isviziev File Added: test.php
2025-04-08 10:25 isviziev Note Added: 0007230
2025-04-08 12:47 derick Assigned To => derick
2025-04-08 12:47 derick Status new => feedback
2025-04-08 12:47 derick Note Added: 0007232
2025-04-08 13:43 isviziev Note Added: 0007243
2025-04-08 13:43 isviziev Status feedback => assigned
2025-04-08 13:44 isviziev Note Added: 0007244
2025-04-11 10:18 derick Status assigned => resolved
2025-04-11 10:18 derick Resolution open => no change required
2025-04-11 10:18 derick Note Added: 0007245