|
|
I had the same issue with PHP 8.1 and Xdebug 3.3.1 on an M2 Macbook Pro. Downgrading to 3.2.2 has worked for me also.
More information on my issue and be found here https://github.com/nicoverbruggen/phpmon/discussions/280 |
|
|
|
same issue as well (PHP 8.1, Xdebug 3.3.2, M2 Macbook Pro), only when listening to xdebug connections (PhpStorm), downgrading to 3.2.2 worked. |
|
|
|
Xdebug 3.3.1* :) |
|
|
|
The latest working version is 3.3.0alpha2, starting from 3.3.0alpha3 there is this problem. |
|
|
|
I have the same crash. the backtrace points at Xdebug:
GI___memmove_falkor () at ../sysdeps/aarch64/multiarch/memcpy_falkor.S:310
310 ../sysdeps/aarch64/multiarch/memcpy_falkor.S: No such file or directory.
(gdb) bt
#0 GI___memmove_falkor () at ../sysdeps/aarch64/multiarch/memcpy_falkor.S:310
#1 0x0000ffff7c2afd5c in xdebug_str_internal_addl (f=0, le=18, str=0xffff7c2d7fd0 "<tr><td class=\"i\">",
xs=0xaaaac3bd2ca0) at /build/downloads/xdebug/src/lib/str.c:44
0000002 xdebug_str_addl (xs=0xaaaac3bd2ca0, str=str@entry=0xffff7c2d7fd0 "<tr><td class=\"i\">", le=le@entry=18,
f=f@entry=0) at /build/downloads/xdebug/src/lib/str.c:60
0000003 0x0000ffff7c2ae258 in xdebug_diagnostic_log (
message=0xaaaac3cfbe30 "Select failed: Bad file descriptor", error_code=0xffff7c2d6b50 "CTRL-SELECT",
log_level=<optimized out>, channel=0) at /build/downloads/xdebug/src/lib/log.c:106
0000004 xdebug_log_ex (channel=channel@entry=0, log_level=log_level@entry=3,
error_code=error_code@entry=0xffff7c2d6b50 "CTRL-SELECT",
fmt=fmt@entry=0xffff7c2d6b38 "Select failed: %s") at /build/downloads/xdebug/src/lib/log.c:170
0000005 0x0000ffff7c2a86c8 in xdebug_control_socket_handle ()
at /build/downloads/xdebug/src/base/ctrl_socket.c:256
0000006 0x0000aaaab0855f6c in zend_llist_apply_with_argument (l=<optimized out>,
func=func@entry=0xaaaab0883194 <zend_extension_statement_handler>, arg=0xffff7c813020)
at /build/downloads/php-8.3.2/Zend/zend_llist.c:236
0000007 0x0000aaaab04a385c in ZEND_EXT_STMT_SPEC_HANDLER ()
at /build/downloads/php-8.3.2/Zend/zend_vm_execute.h:3035
0000008 0x0000aaaab08e5d14 in execute_ex (ex=0x1555587823dc0)
at /build/downloads/php-8.3.2/Zend/zend_vm_execute.h:57296
0000009 0x0000ffff79458440 in ?? () from /opt/php/8.3/lib/php/extensions/no-debug-non-zts-20230831/blackfire.so
0000010 0x0000aaaab08e5f8c in zend_execute (op_array=0xffff7c8fe000, return_value=<optimized out>)
at /build/downloads/php-8.3.2/Zend/zend_vm_execute.h:61604
0000011 0x0000ffff79476480 in bf_load_embedded_code ()
from /opt/php/8.3/lib/php/extensions/no-debug-non-zts-20230831/blackfire.so
0000012 0x0000ffff7945da28 in zm_activate_blackfire ()
from /opt/php/8.3/lib/php/extensions/no-debug-non-zts-20230831/blackfire.so
0000013 0x0000aaaab086a8b0 in zend_activate_modules () at /build/downloads/php-8.3.2/Zend/zend_API.c:3202
0000014 0x0000aaaab07f95b8 in php_request_startup () at /build/downloads/php-8.3.2/main/main.c:1805
0000015 0x0000aaaab04b0fe0 in main (argc=<optimized out>, argv=<optimized out>)
at /build/downloads/php-8.3.2/sapi/fpm/fpm/fpm_main.c:1859 |
|
|
|
seeing that the backtrace points at the control socket, I have set
xdebug.control_socket=off
in my php.ini as I don't need this feature. This has solved the crash for me. |
|
|
|
xdebug.control_socket=off did not work for me with PHP 8.1
|
|
|
|
I have released Xdebug 3.3.1, which could have fixed this issue. Can you please try it? (I don't think it will, but it would be good to test. And it does fix some other bugs too) |
|
|
|
Can you provide the requested feedback please? |
|
|
|
Hi!
I'm also having the problem with 502 error from nginx (laravel valet windows), it happens only when I enable XDEBUG_SESSION cookie. PHP 8.3, tried couple versions of XDebug, 3.3.0-alpha2, 3.3.0, 3.3.2.
I'm not quite sure which logs should I provide for you, if you could give me some hints how to generate them I'll paste them here.
Cheers |
|
|
|
This is my configuration:
PHP 8.3.2 (cli) (built: Jan 16 2024 20:48:07) (NTS Visual C++ 2019 x64)
Copyright (c) The PHP Group
Zend Engine v4.3.2, Copyright (c) Zend Technologies
with Xdebug v3.3.2, Copyright (c) 2002-2024, by Derick Rethans |
|
|
|
@derick
What is more interesting is that when I make a request which contains XDEBUG_SESSION=PHPSTORM then the request will fail with 502 Bad Gateway.
BUT when I make same request without cookie, but with ?XDEBUG_SESSION=PHPSTORM query string then everything work correctly and debugger properly stops at given breakpoint. Any idea what can actually happen here ?
Cheers |
|
|
|
Having exactly the same issue:
PHP 8.2.20 (cli) (built: Jun 4 2024 13:22:51) (NTS gcc aarch64)
Copyright (c) The PHP Group
Zend Engine v4.2.20, Copyright (c) Zend Technologies
with the ionCube PHP Loader v13.0.4, Copyright (c) 2002-2024, by ionCube Ltd.
with Zend OPcache v8.2.20, Copyright (c), by Zend Technologies
with Xdebug v3.3.2, Copyright (c) 2002-2024, by Derick Rethans
Deleting the XDEBUG_SESSION everything works fine. |
|
|
|
My config:
; Enable xdebug extension module
zend_extension=xdebug.so
xdebug.discover_client_host="on"
xdebug.client_discovery_header="HTTP_X_DEBUG_HOST,HTTP_X_FORWARDED_FOR,REMOTE_ADDR"
xdebug.idekey="PHPSTORM"
xdebug.show_local_vars="on"
xdebug.var_display_max_depth=3
xdebug.max_nesting_level=250
xdebug.file_link_format = '"phpstorm://open?file=%f&line=%l"'
xdebug.mode="debug,develop"
xdebug.output_dir="/tmp"
xdebug.profiler_output_name="cachegrind.out.%t.%s_%R"
xdebug.trace_output_name="trace.%t.%s_%R"
xdebug.start_with_request=yes
xdebug.client_host=host.docker.internal
xdebug.control_socket=off
|
|
|
|
Hi, any update on that ? Currently it is totally impossible to use Xdebug on any project using PHP 8.1 and even PHP 8.3 with XDebug Helper Chrome extension, because it adds XDEBUG_SESSION cookie to the requests.
Currently the only way to make it work is by XDEBUG_SESSION=PHPSTORM query param to each request I'd like to test. No idea why it works with query string and not with cookie, maybe do you have some idea @derick?
@se45ky could you also check and eventually confirm that it works for you when using query param instead of cookie ? |
|
|
|
By the way the easiest way to reproduce this (I think) is to install Laravel Herd for Windows, add some PHP version to it, download XDebug DLL, put it into ext folder, edit php.ini. My config is:
[xdebug]
xdebug.client_host=127.0.0.1
xdebug.client_port=9003
xdebug.mode=debug
xdebug.start_with_request = trigger;
and restart herd services. But I've had this problem also with valet-windows, so I think it is rather "global" issue. |
|
|
|
The original reporter still has not a provided a way on how to reproduce this problem.
There are currently several reported crash bugs where more than one person added information, but often with a different cause. This makes researching this challenging, especially because I still do not have a reproducible case.
I am going to close this ticket (and the others), and will only accept issues related to crashes when there is a full reproducible case — the exact steps on how I could potentially try to have the same issue. |
|
