zend_mm_heap corrupted Error During PHPUnit Tests in PHP 8.4

[amcfarlane]

Thank you for this package.

I understand that this issue might be outside the current scope of the package. However, it seems to cause problems with PHPUnit tests when using PHP 8.4. I thought you might want to be aware of this, in case you are planning to add support. Additional details are provided below:

zend_mm_heap corrupted

   Symfony\Component\Process\Exception\ProcessSignaledException 

  The process has been signaled with signal "6".

  at vendor/symfony/process/Process.php:462
    458▕             usleep(1000);
    459▕         }
    460▕ 
    461▕         if ($this->processInformation['signaled'] && $this->processInformation['termsig'] !== $this->latestSignal) {
  ➜ 462▕             throw new ProcessSignaledException($this);
    463▕         }
    464▕ 
    465▕         return $this->exitcode;
    466▕     }

      +15 vendor frames 

  16  artisan:13
      Illuminate\Foundation\Application::handleCommand()

https://stackoverflow.com/questions/79284458/php-8-4-upgrade-in-laravel-sail-causes-zend-mm-heap-corrupted-error-during-phpun/79290055

[jason-nabooki]

We're also experiencing the same issue after upgrading to 8.4

[gabrielsieben]

For anyone who finds this, I ran into this on Laravel Vapor using the PHP 8.4 Docker build.

[jason-nabooki]

Seems to be an issue with the Facade?

Swapping to the "standalone mode" stops the error.

use hisorange\BrowserDetect\Parser as BrowserDetect

https://github.com/hisorange/browser-detect?tab=readme-ov-file#standalone-mode-without-laravel

But why only when accessing through the Facade?

cc @hisorange

[jason-nabooki]

A colleague found this php/php-src#17132 which may be related, will have to wait for 8.4.4 to be released to see if it is the issue.

[jhm-ciberman]

Having the same issue. Laravel 11, PHP 8.4. This issue is blocking me from migrating our application to PHP 8.4.

[nielsdos]

PHP maintainer here.
I would be kind of surprised if the pcre fix is related to this, or if this is just coincidence.
If someone can give a standalone reproducer (e.g. via a github repo or docker image or something I can easily run on my machine), I can try to debug this.
EDIT: I just ran phpunit on this repo and it seems to work without crashes, so a standalone reproducer would be welcome and I'll gladly take a look from PHP's side of things.

[jason-nabooki]

Thanks for looking at this @nielsdos. When tracing the issue we found that commenting out preg_match usages stopped the error. The package makes heavy use of preg_match in many, many loops. It could also be a red herring or a coincidence.

eg. https://github.com/hisorange/browser-detect/blob/stable/src/Stages/DeviceDetector.php#L94

Since this issue only occurs when using the Facade, I'll see if I can setup a standalone repository where the crash occurs.

[jason-nabooki]

@nielsdos I've been able to create a repository that reproduces the issue.

https://github.com/jason-nabooki/bd-php-84

The test in question passes on 8.3 but throws zend_mm_heap corrupted on 8.4.

I'm quite lost on this one, I can't tell if it's an issue with this package, the Laravel Framework or PHP 8.4. It's very strange and has been quite an effort to pin down reproducibility.

@amcfarlane @jhm-ciberman and @gjsman could you guys maybe also pull down the repo and verify you can replicate?

[gabrielsieben]

@jason-nabooki @nielsdos Replicated here on macOS with Laravel Herd, PHP 8.4.3.

[nielsdos]

This reproduces for me too (on Linux x64), thanks @jason-nabooki ! This is the kind of reproducer I love to see.
Looks like a string flag bug, i.e. a bug in PHP 8.4:

php: /home/niels/php-8.4/Zend/zend_string.h:361: zend_string_release_ex: Assertion `!(zval_gc_flags((s)->gc.u.type_info) & (1<<7))' failed.

After all it's related (and fixed by) php/php-src#17132 anyway. Sorry for doubting!

Technical explanation: It's due to how the caching of pcre regexes works, if the cache is cleared the subpattern names are released in the cache, but they may still exist in userland, and there can be a mismatch then because the subpattern names are persistent. The PR fixes this by making the subpattern names always bound to the request instead of persistent. So although the PR originally fixed a memleak, as a consequence of how it works it also fixes this.

TL;DR: this should be fixed in PHP 8.4.4 (I tested this).

Also: in general if you see zend_mm_heap corrupted it's most likely either a bug in PHP itself or in a third party extension.

[atymic]

Thanks @nielsdos, took me a while to get here as well 😅

[jason-nabooki]

PHP 8.4.4 has dropped. Our test suite is now passing.

[schodemeiss]

I'm on PHP 8.4.4 and I'm still getting zend_mm_heap corrupted when running PHP Unit tests. Is this really confirmed as fixed, or something else?

[gabrielsieben]

@schodemeiss Can you verify that your PHPUnit tests are running on the same PHP version that you are expecting?

For my part, when I tried deploying my app onto Vapor with this package, I was seeing zend_mm_heap corrupted every few minutes in the logs; but it's been several hours now on 8.4.4 and there has not been an appearance.

[nielsdos]

I'm on PHP 8.4.4 and I'm still getting zend_mm_heap corrupted when running PHP Unit tests. Is this really confirmed as fixed, or something else?

First check if everything is running on 8.4.4. The particular issue the people in this thread were having is fixed. It's possible you're hitting another issue. zend_mm_heap corrupted is a sign something went wrong memory-wise, but it could be caused by many things. Ideally, if you confirmed having another issue you should report this to php-src and ideally post a reproducing sample or some repo that we can test on.