Bug is active since 3.0.1, because originally i had xdebug 3.0.1, then updated to 3.1.1 to check, and this problem persisted.
Xdebug settings:

xdebug.mode = debug,coverage
xdebug.output_dir = /tmp
xdebug.start_with_request = trigger
xdebug.log = /tmp/xdebug.log
xdebug.log_level = 0

Can you please provide a reproducible test case, as is requested at https://xdebug.org/reporting-bugs ?

Also, what is xdebug.max_nesting_level set to?

Unfortunately i can't now compose standalone example to reproduce that case, and main application is private, i will try i later tho.
Xdebug settings are default except i posted above, so they are the following:

root@b9f248e69e2a:/var/www/atm# php -v
PHP 7.4.24 (cli) (built: Sep 28 2021 16:21:38) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.24, Copyright (c), by Zend Technologies
with Xdebug v3.1.1, Copyright (c) 2002-2021, by Derick Rethans
root@b9f248e69e2a:/var/www/atm# php -r "phpinfo();" | grep xdebug
/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini,
xdebug
Support Xdebug on Patreon, GitHub, or as a business: https://xdebug.org/support
Enabled Features (through 'xdebug.mode' setting)
xdebug.auto_trace => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.cli_color => 0 => 0
xdebug.client_discovery_header => no value => no value
xdebug.client_host => 172.21.0.1 => localhost
xdebug.client_port => 9000 => 9003
xdebug.cloud_id => no value => no value
xdebug.collect_assignments => Off => Off
xdebug.collect_includes => (setting removed in Xdebug 3) => (setting removed in Xdebug 3)
xdebug.collect_params => (setting removed in Xdebug 3) => (setting removed in Xdebug 3)
xdebug.collect_return => Off => Off
xdebug.collect_vars => (setting removed in Xdebug 3) => (setting removed in Xdebug 3)
xdebug.connect_timeout_ms => 200 => 200
xdebug.coverage_enable => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.default_enable => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.discover_client_host => Off => Off
xdebug.dump.COOKIE => no value => no value
xdebug.dump.ENV => no value => no value
xdebug.dump.FILES => no value => no value
xdebug.dump.GET => no value => no value
xdebug.dump.POST => no value => no value
xdebug.dump.REQUEST => no value => no value
xdebug.dump.SERVER => no value => no value
xdebug.dump.SESSION => no value => no value
xdebug.dump_globals => On => On
xdebug.dump_once => On => On
xdebug.dump_undefined => Off => Off
xdebug.file_link_format => no value => no value
xdebug.filename_format => no value => no value
xdebug.force_display_errors => Off => Off
xdebug.force_error_reporting => 0 => 0
xdebug.gc_stats_enable => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.gc_stats_output_dir => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.gc_stats_output_name => gcstats.%p => gcstats.%p
xdebug.halt_level => 0 => 0
xdebug.idekey => no value => no value
xdebug.log => /tmp/xdebug.log => /tmp/xdebug.log
xdebug.log_level => 0 => 0
xdebug.max_nesting_level => 256 => 256
xdebug.max_stack_frames => -1 => -1
xdebug.mode => debug,coverage => debug,coverage
xdebug.output_dir => /tmp => /tmp
xdebug.overload_var_dump => (setting removed in Xdebug 3) => (setting removed in Xdebug 3)
xdebug.profiler_append => Off => Off
xdebug.profiler_enable => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.profiler_enable_trigger => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.profiler_enable_trigger_value => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.profiler_output_dir => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p
xdebug.remote_autostart => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.remote_connect_back => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.remote_enable => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.remote_host => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.remote_log => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.remote_log_level => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.remote_mode => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.remote_port => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.remote_timeout => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.scream => Off => Off
xdebug.show_error_trace => Off => Off
xdebug.show_exception_trace => Off => Off
xdebug.show_local_vars => Off => Off
xdebug.show_mem_delta => (setting removed in Xdebug 3) => (setting removed in Xdebug 3)
xdebug.start_upon_error => default => default
xdebug.start_with_request => trigger => trigger
xdebug.trace_enable_trigger => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.trace_enable_trigger_value => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.trace_format => 0 => 0
xdebug.trace_options => 0 => 0
xdebug.trace_output_dir => (setting renamed in Xdebug 3) => (setting renamed in Xdebug 3)
xdebug.trace_output_name => trace.%c => trace.%c
xdebug.trigger_value => no value => no value
xdebug.use_compression => 1 => 1
xdebug.var_display_max_children => 128 => 128
xdebug.var_display_max_data => 512 => 512
xdebug.var_display_max_depth => 3 => 3

Do you run symfony on the command line, or did you see the error through a web server? They might have different php.ini files.

Does symfony change the max_nesting_level setting?

If you stick var_dump(ini_get("xdebug.max_nesting_level")) in your code, but way after symfony's bootstrap has loaded, what does it output?

1) I run bin/console - symfony CLI tool
2) I don't think that symfony change max_nesting_level, but i may be wrong
3) php.ini is the same, i on purpose greped the output of php -r from cmd to show that the env is the same with bin/console
4) Sticking var_dump - results in 256, tried different places, i also really don't think that symfony change that in any place

Also tried reducing nesting to 1\64\128 - no luck, same segfault, only disabling xdebug do show correct error message

Ah, I see that you don't have develop as part of mode, so use this:

xdebug.mode = develop, debug,coverage

I bet that the shows the max nesting level error instead of a stack overflow.

If that's the case then there is no bug here.

Ok, now i've got this. log_level was 0 before, so segfault occurs only if log_level = 0, if i set log_level = 1 or more, correct error about infinite loop shows up without any segfault. So not so big of an issue now, but not ideal anyway ;)

I am going to close this then. Xdebug's stack overflow prevention only works when "develop" is part of its modes.