`zend_mm_heap corrupted` in AppVeyor CI test runner on 8.2+

[nielsdos]

Description

I recently worked on a PR for master and I noticed there was a message zend_mm_heap corrupted printed right after starting the test runner on Windows. It only happens on AppVeyor, which tests ZTS and opcache enabled. It does not happen on the Windows CI on GitHub Actions, which does not test for the ZTS+opcache combination AFAIK.

I first thought it was a bug in my PR, but looking at CI runs of other PRs I see the same message.
(I only linked my PR CI runs here because I don't want to give the impression that I'm pointing fingers or anything like that)

Examples on master:

• https://ci.appveyor.com/project/php/php-src/builds/46478528/job/5jhyt021y4aejd8r
• https://ci.appveyor.com/project/php/php-src/builds/46353979/job/cpive0xu6edqlbg4
• https://ci.appveyor.com/project/php/php-src/builds/46277751/job/oax4crng72mamnwn
• ... there are more, you'll find this in many CI runs in many PRs

I also saw it happen on 8.2 test runs. Interestingly, the CI run does succeed in those cases.

Given that they are all unrelated PRs, this issue seems to be unrelated and older than the PRs.

PHP Version

8.2+

Operating System

Windows

[mvorisek]

First 04eb8b4 commit from Sep 17, 2022 with such problem in AppVeyor history.

[nielsdos]

Got a trace from CI

assertion broken at line 1459 in zend_alloc.c
zend_mm_heap corrupted
13: zend_mm_startup_ex - 0x7FF9041E5390
12: zend_mm_startup_ex - 0x7FF9041E5390
11: efree - 0x7FF9041E20B0
10: zend_hash_destroy - 0x7FF90427C8F0
9: destroy_zend_class - 0x7FF9042AF6C0
8: zend_hash_apply_with_argument - 0x7FF90427F770
7: zend_restore_error_handling - 0x7FF9041D4C10
6: zend_post_deactivate_modules - 0x7FF9041D4A40
5: php_request_shutdown - 0x7FF90430BFD0
4: OPENSSL_Applink - 0x7FF6E5F11170
3: OPENSSL_Applink - 0x7FF6E5F11170
2: OPENSSL_Applink - 0x7FF6E5F11170
1: BaseThreadInitThunk - 0x7FF93D337AC0
0: RtlUserThreadStart - 0x7FF93D98A350

I think it's the dl() bug w.r.t. persistency, but I'll have to investigate further tonight to be sure.

[nielsdos]

I found that this issue has the same root cause as GH-9196.
The reason it corrupts the heap is because memory allocated with libc malloc gets freed with efree instead of free, which is because of the persistent/non-persistent mixups due to dl().
I'm therefore closing this as a duplicate.