Can you always reproduce it with a same HTTP refresh or CLI command?

Especially if you can reproduce it on CLI, you can try the following (even if it doesn't always reproduce):

export USE_ZEND_ALLOC=0
export ZEND_DONT_UNLOAD_MODULES=1

valgrind --trace-children=yes php your-script.php

If that shows things like use after free, or uninitialised warnings, then something fishy is going on.

The absolute best way would be able to make a reproducer, obviously. If you can reliably reproduce it in a docker container or something, then that could also be a way of trying to figure this out.

Right now, there is not really enough information here.

Hi Derick,

thank you for taking the time to look into this issue. I completely understand that my initial message lacked the necessary detail, and I appreciate you guiding me toward the next steps to investigate—just as you did.

I’ve attached the trace output for the following command:

valgrind \
--trace-children=yes \
--track-origins=yes \
--leak-check=full \
-s \
php ./vendor/bin/phpunit tests/<...>/ContractAccountControllerTest.php --filter AllocatedTransaction 2> trace.txt

This command executes only the two test cases that fail when enable_native_lazy_objects is enabled and Xdebug is active.

I hope the trace provides you with some useful insights—unfortunately, it doesn’t shed much light for me.

Sadly this does not produce any insight. I think most of these errors are actually PCRE JIT "warnings", which you can probably get rid of by using -dpcre.jit=0 as option to PHP.

But I also can't see how I can reproduce this myself with this? I'm really going to need a reproducible case here, I'm afraid.

@derick: Would it be helpful if I provided a (slimmed-down) Docker image to reproduce the issue? I’ll need to confirm whether this is legally permissible, but if it would be beneficial, I’m happy to look into it.

@sgehrig Sure!

@derick: Great. Do you have a possibility for me to securely upload about 500 MB?

I have slimmed-down the application with the error still reproducible to a multi-platform (amd64 and arm64) Docker image based on php:8.4.10-cli with Xdebug 3.4.5.

Can I contact you via email with some more information that I'd not want to share publicly.

@sgehrig --- I don't have a facility to upload that much data, sorry. I can pull it down from somewhere though. Reach out through email (address is behind an icon at https://derickrethans.nl/who.html). I don't need arm64 as I don't have the hardware for it.

@derick: I’m almost afraid to ask, but did the reproducer reveal anything useful?

Sorry, but no. Although I can reproduce it, there is too much code to narrow it down. I also can't make an xdebug trace because I can't do that with Xdebug off, and even if I just enable tracing mode, the issue appears already.

Is there anything I can do to help? Further reducing the application might not be particularly useful, as it would still involve executing a considerable amount of code—most of which is likely unrelated to the issue.

There might be some more helpful information here https://github.com/symfony/symfony/issues/61058 as some more developers experience the same issue in slightly difference use-cases.

https://github.com/xdebug/xdebug/pull/1041

Should be fixed in GIT (both xdebug_3_4 and master branch) — can you please check?

@HypeMC: Your issue is a different one than was reported here. I have created a new one: https://bugs.xdebug.org/view.php?id=2375

I'm also marking the related comments here as "private" to prevent it from confusing future visitors.

@derick Sorry for the late reply, but I also can confirm that the issue is fixed with 3.4.7. Thanks so much and thanks to @GromNaN for providing the reproducible test case.