Как диагностировать эту сегментацию PHP-Code-Coverage и поврежденные ошибки zend_mm_heap

Я счастливо кодировал свою машину Ubuntu. Это мускулистая машина с большим количеством ОЗУ. Я работал над четырьмя новыми классами, записывая и запуская модульные тесты. В какой-то момент я заметил, что, хотя модульные тесты заканчивались хорошо, охвата кода не было.

После сообщения «Генерирование отчета о покрытии кода … и т. Д.» Я получаю сообщение о том, что zend_mm_heap поврежден. Я попробовал несколько исправлений, включая: установку output_buffering = On в моем php.ini (оба apache2 и cli) и удаление вызовов для unset() из моего кода. (Я прочитал, что это исправление может потребоваться).

Теперь я, кажется, чередую между ошибкой zend_mm … и ошибкой сегментации (core dump), независимо от того, что я делаю. Я комментирую тесты до тех пор, пока не сужу то, что, по-моему, вызывает проблему, и внесем некоторые изменения там, пока я не получу чистый прогон. Затем я раскомментирую весь тест только для того, чтобы найти, что эта ошибка все еще происходит.

Есть идеи? Какие инструменты или методы можно использовать для сбора дополнительной информации?

Я использую PHP_CodeCoverage 1.2.6, PHP 5.3.10-1ubuntu3.5, PHPUnit 3.7.9.

РЕДАКТИРОВАТЬ:

В стороне я не могу найти файлы дампа ядра. Искали из корня обоих моих физических дисков без везения. Я прочитал запись человека по ядру, включая возможные причины создания дампов ядра, не создавая файл, но я не думаю, что это применимо.

Solutions Collecting From Web of "Как диагностировать эту сегментацию PHP-Code-Coverage и поврежденные ошибки zend_mm_heap"

Недавно у меня была такая же проблема. Похоже, что проблема связана с сборкой мусора PHP. Отключение сбора мусора во время трассировки phpunit решило проблему для меня.

Добавить:

 zend.enable_gc=0 

в файл php.ini или из командной строки:

 phpunit -d zend.enable_gc=0 

Иногда бывает трудно понять ошибку ошибки сегментации при запуске PhpUnit с охватом кода. У меня была ошибка сегментации на PHP 7.0.5 с двумя версиями PhpUnit.

Наконец, после отслеживания проблемы в моем случае что-то вроде этого вызывало ошибку сегментации

 $x = doSomething(doSomethingElse()); 

и извлечения внутренней функции в переменную следующим образом:

 $y = doSomethingElse(); $x = doSomething($y); 

решили проблему. Это выше, конечно, упрощенный код, но вы должны понимать, что в вашем коде нет реальной ошибки, но вы должны изменить это, чтобы PhpUnit с кодом покрытия работать для вашего кода.

У меня была такая же проблема и я попытался использовать zend.enable_gc = 0, но тогда у phpunit закончилась нехватка памяти. Чтобы исправить это, я в основном изменил свой белый список покрытия, чтобы быть более гранулированным. Итак, в phpunit.xml, где я ранее имел это:

 <filter> <whitelist> <directory suffix=".php">../application/src</directory> </whitelist> </filter> 

Я изменил это на следующее:

 <filter> <whitelist> <directory suffix=".php">../application/src/module1</directory> <directory suffix=".php">../application/src/module2</directory> <directory suffix=".php">../application/src/module3</directory> <exclude> <directory>../application/src/module1/views</directory> </exclude> </whitelist> </filter> 

Поэтому просто постарайтесь ограничить фильтр только включением файлов, которые на самом деле имеют значение. Это все еще ошибка, но на данный момент я считаю, что ограничение количества файлов, которые рассматриваются для расчета покрытия, поможет предотвратить подобные проблемы.