Я счастливо кодировал свою машину 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.
РЕДАКТИРОВАТЬ:
В стороне я не могу найти файлы дампа ядра. Искали из корня обоих моих физических дисков без везения. Я прочитал запись человека по ядру, включая возможные причины создания дампов ядра, не создавая файл, но я не думаю, что это применимо.
Недавно у меня была такая же проблема. Похоже, что проблема связана с сборкой мусора 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>
Поэтому просто постарайтесь ограничить фильтр только включением файлов, которые на самом деле имеют значение. Это все еще ошибка, но на данный момент я считаю, что ограничение количества файлов, которые рассматриваются для расчета покрытия, поможет предотвратить подобные проблемы.