View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002081||Xdebug||Stacktraces||public||2022-04-06 10:50||2022-05-27 09:06|
|Priority||normal||Severity||crash||Reproducibility||unable to reproduce|
|Status||resolved||Resolution||unable to reproduce|
|Summary||0002081: SIGSEGV, Segmentation fault in xdebug_append_printable_stack|
/ $ gdb /usr/local/sbin/php-fpm /tmp/core-php-fpm.38
|Tags||No tags attached.|
The bug does not occur on PHP 7.4. I cannot test on PHP 8.1 yet. Also, it occurs on a request that does not generate an error when xdebug is disabled with xdebug.mode=off. When I use xdebug.mode=develop,profile it generates the error.
How can I reproduce this? Your GDB trace alone is not nearly enough. Please follow the instructions at https://xdebug.org/reporting-bugs
I don't know how to reproduce this, and the requested information was not provided so I am closing this report.
Sorry Derick, I forgot to mention that I was unable to create a reproducible example. I felt it was related to some class autolpading when I was creating it through a dependency injection container. But since it was so deep into the object graph, I was not able to locate it exactly. Then I decided to file the bug with a stack trace. Maybe when someone else has a similar issue, this one popups again.
2022-05-27T08:37:56.254857614Z php-fpm 19 [27-May-2022 08:37:56] NOTICE: fpm is running, pid 19
But debugging this one is extremely hard. The request fails during constructing the dependency graph. I am using aura/di as container.
1) On this line: https://github.com/auraphp/Aura.Di/blob/4.x/src/Resolver/Resolver.php#L247 it is trying to see what to inject in the constructor of a class
The crash happens when returning the value on the latter line (not during construction of that DefaultValueParam class). And now comes even more weird part. It can be solved by changing the constructor. The file that is being constructed looks as follows.
public function __construct(
If I change the last parameter, the one that is causing the crash during construction, into this.
public function __construct(
The problem disappears.
So removing that array type-hint resolves the issue, and considering that my coredump shows: /tmp/pear/temp/xdebug/src/develop/stack.c No such file or directory. Could it somehow be that the array is seen as something that needs to be loaded from the filesystem?
|2022-04-06 10:firstname.lastname@example.org||New Issue|
|2022-04-06 11:email@example.com||Note Added: 0006266|
|2022-04-06 15:07||derick||Assigned To||=> derick|
|2022-04-06 15:07||derick||Status||new => feedback|
|2022-04-06 15:07||derick||Note Added: 0006267|
|2022-05-25 14:24||derick||Status||feedback => resolved|
|2022-05-25 14:24||derick||Resolution||open => unable to reproduce|
|2022-05-25 14:24||derick||Note Added: 0006314|
|2022-05-25 14:firstname.lastname@example.org||Note Added: 0006317|
|2022-05-27 08:email@example.com||Note Added: 0006321|
|2022-05-27 09:firstname.lastname@example.org||Note Added: 0006322|