Do you have the remote debugger (xdebug.remote_enable=1) enabled?

Yes - here is my config:

wolkerstorfer@****:/home/tkwww$ php -i | grep xdebug
/etc/php/7.2/cli/conf.d/20-xdebug.ini,
xdebug
xdebug support => enabled
Support Xdebug on Patreon, GitHub, or as a business: https://xdebug.org/support
xdebug.auto_trace => Off => Off
xdebug.cli_color => 0 => 0
xdebug.collect_assignments => Off => Off
xdebug.collect_includes => On => On
xdebug.collect_params => 0 => 0
xdebug.collect_return => Off => Off
xdebug.collect_vars => Off => Off
xdebug.coverage_enable => On => On
xdebug.default_enable => On => On
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 => Off => Off
xdebug.gc_stats_output_dir => /tmp => /tmp
xdebug.gc_stats_output_name => gcstats.%p => gcstats.%p
xdebug.halt_level => 0 => 0
xdebug.idekey => no value => no value
xdebug.max_nesting_level => 400 => 400
xdebug.max_stack_frames => -1 => -1
xdebug.overload_var_dump => 2 => 2
xdebug.profiler_append => Off => Off
xdebug.profiler_enable => Off => Off
xdebug.profiler_enable_trigger => Off => Off
xdebug.profiler_enable_trigger_value => no value => no value
xdebug.profiler_output_dir => /tmp => /tmp
xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p
xdebug.remote_addr_header => no value => no value
xdebug.remote_autostart => Off => Off
xdebug.remote_connect_back => On => On
xdebug.remote_cookie_expire_time => 3600 => 3600
xdebug.remote_enable => On => On
xdebug.remote_host => localhost => localhost
xdebug.remote_log => no value => no value
xdebug.remote_log_level => 7 => 7
xdebug.remote_mode => req => req
xdebug.remote_port => 9000 => 9000
xdebug.remote_timeout => 200 => 200
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 => Off => Off
xdebug.trace_enable_trigger => Off => Off
xdebug.trace_enable_trigger_value => no value => no value
xdebug.trace_format => 0 => 0
xdebug.trace_options => 0 => 0
xdebug.trace_output_dir => /tmp => /tmp
xdebug.trace_output_name => trace.%c => trace.%c
xdebug.var_display_max_children => 128 => 128
xdebug.var_display_max_data => 512 => 512
xdebug.var_display_max_depth => 3 => 3

Why exactly do you have debugging enabled for a long running script? If you're not going to debug it (and you can't start debugger while it is running), it's not wise to turn the debugger on. This change in 2.9.1 reduces execution time a lot, and also makes hitting debug breakpoints more reliable.

Having said that, does using the following patch improve things?

diff --git a/src/debugger/debugger.c b/src/debugger/debugger.c

index 4bf61061..b32e3b5b 100644

--- a/src/debugger/debugger.c

+++ b/src/debugger/debugger.c

@@ -630,7 +630,7 @@ static void add_function_to_lines_list(xdebug_lines_list *lines_list, zend_op_ar

map_item->lines_breakable = xdebug_debugger_get_breakable_lines_from_oparray(opa);

if (lines_list->count >= lines_list->size) {

lines_list->size = lines_list->size == 0 ? 16 : lines_list->size * 2;
lines_list->size = lines_list->size == 0 ? 16 : lines_list->size + 16;

lines_list->functions = xdrealloc(lines_list->functions, sizeof(xdebug_function_lines_map_item )  lines_list->size);

}

lines_list->functions[lines_list->count] = map_item;

Thank you for the patch - I tested it and the memory usage didn`t change. For now we deactivated xdebug for the CLI to avoid the problem.

I further investigated the issue and found out, that commit https://github.com/xdebug/xdebug/commit/0e1c9de6ad9d6f05953e309605eca02947c04c44 introduced the increased memory usage.
We use Symphony Dependency Injection in our application. The resulting generated CachedContainerBuilder in our case is a php file with ~90000 lines, 0000157:0000300 proxy classes and ~7787 methods.

I wrote a simple testscript - xdebugtest.php:

<?php
require_once("app/cache/autoloader_project.php");
require_once('redx/core/autoloader.php');

$pid = getmypid();

echo "Mem Usage before require dependency_config.php: ";
passthru('cat /proc/' . $pid . '/status | grep VmRSS');

// Cached Symphony Dependency Injection Container
require_once('app/cache/dependency_config.php');

echo "Mem Usage after require dependency_config.php: ";
passthru('cat /proc/' . $pid . '/status | grep VmRSS');

Xdebug disabled:

wolkerstorfer@****:/home/tkwwwgw$ php -dxdebug.remote_enable=0 xdebugtest.php
Mem Usage before require dependency_config.php: VmRSS:     38032 kB
Mem Usage after require dependency_config.php: VmRSS:      74828 kB

With Xdebug 2.9.0:

wolkerstorfer@****:/home/tkwwwgw$ php -dxdebug.remote_enable=1 xdebugtest.php
Mem Usage before require dependency_config.php: VmRSS:     38144 kB
Mem Usage after require dependency_config.php: VmRSS:      74940 kB

With Xdebug 2.9.1 (git commit 0e1c9de merged):

wolkerstorfer@****:/home/tkwwwgw$ php -dxdebug.remote_enable=1 xdebugtest.php
Mem Usage before require dependency_config.php: VmRSS:     38264 kB
Mem Usage after require dependency_config.php: VmRSS:     246744 kB

Could you provide me with the full test case, so that I can have a look at this? I am not sure what I can do about it yet, and you are talking about a really big file here...

Hi Derick,

this issue can be closed - the problem no longer exists in version 2.9.3.

Thank you!

That's good to hear - thanks for letting me know.