Если жмакнуть одну из этих кнопочек, то увидеть скрытый контент!

Tweet

Итак, какие бывают ошибки и как их можно отловить.

1. Самые простые и самые распространённые — это ошибки, связанные с чудным свойством php — динамической типизацией. Помимо того, что иногда просто упускаешь из виду, что там и в каком формате у тебя хранится, php сам подкидывает сюрпризы вида true при сравнении «qwerty» == 0 и другие чудеса автоматического приведения типов и подобные им брейнфаки.

Если точно известно место, где переменная перестает себя вести, как от нее ожидают, то я особо не мудрствую и ставлю var_dump(переменная). Если догадка подтверждается, то исправляем косяк и идем дальше.

Но не всегда получается определить точное место расхождения значения с ожидаемым. Расхождение это может быть зарыто глубоко в дебри кода, либо наоборот, находится на самом видном месте.

Так же бывает, что переменная меняет значение из-за нарушенной логики приложения. Например, присвоение идет внутри локальной видимости вложенной функции или неверно построенного цикла. Наружу передается не тот результат, который ждешь, хотя с виду все правильно. Просто не там открыл или закрыл скобку и все изменяется причудливым образом.

Такую красоту довольно трудно отловить руками, особенно в крупных приложениях. Поэтому лучше воспользоваться дебаггером. Во всяких умных книжках довольно часто пишут про APD, хвалят его, но дата его последнего релиза за 2004 год как-то меня настораживает. В багтрекере пишут, что под 5.3 не хочет он работать, у меня из груши не встал, поэтому я забил на него.

Трассировку скрипта можно сделать xdebug’ом. Он часто бывает установлен, но как модуль PHP, а для нормальной работы нужно, чтобы он стоял как Zend module.  По установке все итак расписано в нете, не буду повторяться.

Xdebug генерирует отчет, который показвает последовательно, кто, куда, зачем обратился. Есть специальные парсилки логов, но мне удобнее читать сырые отчеты, потому как в консоли особо красоту не получишь, а через веб я не умею отлаживать. Выдается вот такая красота:

3	67	0	0.013521	394468	drXdebugTraceFileParser->parseLine	1		/home/alex/tmp/trace.php	123	1	$line = '2\t3\t1\t0.000772\t328656\n'
4	68	0	0.013588	394584	explode	0		/home/alex/tmp/trace.php	149	2	'\t'	'2\t3\t1\t0.000772\t328656\n'
4	68	1	0.013630	395376
4	69	0	0.013666	395348	count	0		/home/alex/tmp/trace.php	150	1	array (0 => '2', 1 => '3', 2 => '1', 3 => '0.000772', 4 => '328656\n')
4	69	1	0.013716	395348
4	70	0	0.013757	395436	array_pop	0		/home/alex/tmp/trace.php	178	1	array (0 => '{main}', 1 => 'ini_set')
4	70	1	0.013800	395408
4	71	0	0.013823	395332	drXdebugTraceFileParser->addToFunction	1		/home/alex/tmp/trace.php	180	5	$function = 'ini_set'	$time = 4.3E-5	$memory = 236	$nestedTime = 0	$nestedMemory = 0
5	72	0	0.013900	395376	in_array	0		/home/alex/tmp/trace.php	194

Этого достаточно, чтобы проследить логику хода выполнения и отследить косяки. Забыл еще сказать, что xdebug можно подключать на лету. Обычно я выключаю и дебаггер и профайлер в php.ini, а в нужном скрипте просто включаю их вместе или по очереди через

ini_set('xdebug.default_enable', 1);
ini_set('xdebug.profiler_enable', 1);

Это быстро, не нужно никаких дополнительных телодвижений. Xdebug еще можно подключать на кучу разных IDE, даже вроде в денвере он есть.Таким нехитрым образом можно отловить большинство ошибок и невнимательностей в коде. Естественно, что изначально задуманную кривую логику так не исправить.

2. Второй тип ошибок гораздо сложнее отловить. Они также появляются вследствии зевков и невнимательностей, но проявляют себя не сразу, а по наступлению определенных условий. Например, время работы или количество итераций или появление определенного числа в арифметических операциях или наоборот, его непоявление.Еще ошибки могут возникать из-за изменений среды окружения, например форк апача завершил свою сессию и скинул скрипт или крон запускает что-то, что отъело всю память и скрипт просто не может запуститься.

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

Тут приходит на помощь замечательная утилита — strace. Я одно время мучился с тем, что апач раз в 24 часа убивал свои потоки, а с ними и скрипты, из-под которых они были запущены. Так вот был настроен сервер. Нашли ошибку, когда подключились с другого терминала непосредственно к скрипту и слушали его через strace. Там и увидели, что скрипт ловит SIGTERM. Как использовать strace я уже писал. Позволяет исследовать реальную работу скрипта в реальном времени и видит все, что с ним происходит. Вывод можно перенаправить в файл и потом проанализировать. Еще есть схожая утилита, называет ptrace. Все они родные для nix систем. Некоторые чуваки с хабры используют для схожих целей сишный дебаггер. Кому в чем удобней…

3. Третий тип ошибок заключается в том, что память начинает резко утекать куда-то и нужно выяснить куда. Они также возникают из-за невнимательности или усталости и получаются чудеса типа файл инклюдится в бесконечном цикле или переменная набирает и набирает обьемиз-за того, что ее не обнулили предварительно.  Все это конечно можно отловить и через strace, но лучше использовать для этого профайлер xdebug’а.

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

function            #calls time memory time memory
------------------------------------------------------------
ini_set                  3 0.0002      584 0.0002      584
fix_string               1 0.0010      264 0.0009      184
xdebug_call_file         1 0.0001       48 0.0001       48
xdebug_call_function     1 0.0000       32 0.0000       32
var_dump                 1 0.0002        0 0.0002        0
xdebug_memory_usage      1 0.0000        0 0.0000        0
xdebug_call_line         1 0.0000        0 0.0000        0
{main}                   1 0.0018      480 0.0003     -368

Здесь уже можно отследить и вызовы  и время. Запускаю его обычно в конце работы, чтобы посмотреть, не напортачил ли я чего в коде. Также использую его при оптимизации для оценки результатов

Вот такие нехитрые способы, надеюсь, помогут спасти время и нервы при отладке скриптов. Если есть у кого свои методики — велкам в коменты, буду рад услышать.

P.S. Если кто знает, как завести APD под 5.3, отпишитесь плз!

P.P.S Тут вот чувак просто тру-самурай, целый квест прошел чтобы найти ошибку. Шрифт жесть.

Там строку 967 в файле php_apd.c надо закоментить и все заработает.

И чтобы сделать читалку логов, надо скомпиленную pprofp скопировать в /usr/bin и создать ссылку на php в /usr/local/bin/

На закуску.

• Проблемы с сериализацией массивов
• Класс для работы с сервисами сокращения ссылок
• Простой способ проверки процесса на существование

Но это не очень красивое решение. Очень запросов много + на переменные память расходуется. Проще использовать вложенные запросы, они же nested queries. Но тут возникает проблемка -  если вставлять  только данные из INSERT, то все ок, но если добавлять еще и какие-нибудь неизменные значения, то выдается Subquery returned more than 1 value.

Чтобы не обьяснять на пальцах — сама таблица B

CREATE TEMPORARY TABLE `B` (
  `status` TINYINT(4) NULL DEFAULT NULL ,
  `pair` TEXT NULL DEFAULT NULL ,
)
ENGINE = MyISAM
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;

Копируем из таблицы A и вставляем в B так

INSERT INTO `B` (`pair`)
            SELECT `pair` FROM `A` ORDER BY RAND() LIMIT 100;

Если поле status имеет неизменное значение, например 123, то просто вот так уже не вставить

INSERT INTO `B` (`status`, `pair`) VALUES (
            (SELECT `pair` FROM `A` ORDER BY RAND() LIMIT 100),
            123);

Не совсем красивое решение нашел

UPDATE `B` SET `status` = '123' WHERE 1=1;

Но хотелось бы в одну строку все заделать. Отпишитесь плиз в коментах, кто знает, как реализовать.

На закуску.

• Скрипт для тюнинга MYSQL
• MYSQL RAND(), как получить рандомную строку из БД
• Робкий tar )

Сама команда:

find . -type f -name "*.php" -exec wc -l {} +;

На закуску.

• Простой способ проверки процесса на существование
• Как узнать статус процесса по pid
• Организация бекапа на серверах

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.51a-24+lenny5-log
[!!] Switch to 64-bit OS - MySQL cannot currently use all of your RAM

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB +Federated -InnoDB -ISAM -NDBCluster 

[--] Data in MyISAM tables: 5M (Tables: 260)
[OK] Total fragmented tables: 0

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1d 12h 14m 59s (4M q [33.837 qps], 39K conn, TX: 822M, RX: 460M)
[--] Reads / Writes: 30% / 70%
[--] Total buffers: 57.0M global + 50.5M per thread
(400 max threads)
[!!] Allocating > 2GB RAM on 32-bit systems can cause system instability
[!!] Maximum possible memory usage: 19.8G (293%
of installed RAM)
[!!] Slow queries: 10%
(443K/4M)
[OK] Highest usage of available connections: 38%
(152/400)
[OK] Key buffer size / total MyISAM indexes:
15.0M/4.7M
[OK] Key buffer hit rate: 99.1% (9M cached
/ 91K reads)
[OK] Query cache efficiency: 75.5% (2M cached /
2M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp
sorts / 439K sorts)
[OK] Temporary tables created on disk: 1% (8K
on disk / 444K total)
[OK] Thread cache hit rate: 99% (307 created /
39K connections)
[!!] Table cache hit rate: 0% (5 open /
11K opened)
[OK] Open file limit used: 0%
(11/65K)
[OK] Table locks acquired immediately: 99%
(2M immediate / 2M
locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    table_cache (> 32562)

Сам скрипт лежит тут: веб, гит

На закуску.

• Вложенные SQL запросы: одновременное добавление одинарных и множественных строк в INSERT
• MYSQL RAND(), как получить рандомную строку из БД
• Робкий tar )

php script.php &

И управление процессом от юзера уходит, отловить такой процесс из другого скрипта уже не получится. А если процесс выполняет какую то одну и ту же задачу с интервалом по крону, и нужно, чтобы при запуска нового процесса старый был убит? Поймать его можно аццкой смесью bash + php:

$killPid = exec("ps ux | awk '/script_name.php/ && !/awk/ {print $2}'");//находим пид процесса
      if($killPid)//если есть, киляем
	  exec ("kill ".$killPid);
exec('php script_name.php &');//запускаем новый

На закуску.

• Считаем, сколько строк кода в php проекте.
• Примеры использования strace для отладки скриптов
• Watchdog для своих скриптов или проверка состояния процесса

Пример использования — есть один сервис, который я написал, и обьявилась там проблема — каким-то неведомым образом права на файл, куда пишется лог, начали выставляться криво. А именно: вместо положенных rw — rw — rw стали w — wx — wT. Проблема тут в том, что надо указывать права при смене не как:

chmod('file.txt', '0666'); или
chmod('file.txt', 666);

в этом случае 0666 будет string, а вот так:

chmod('file.txt', intval('666', 8));

Так они уже будут в корректной форме.

Вернемся к проблеме. Нужно было найти, кто ставит на файл неверные права. Вот так можно отловить все вызовы определенного файла:

strace php ./script.php 2>&1 | grep file.txt

Ответ будет вида:

open("/path/to/file.txt", O_RDWR|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 4
chmod("/path/to/file.txt", 0666) = 0

Вот так можно отмониторить все обращения к файлу

Однако у меня была проблема с записью при запуске через апача, т.е. скрипт запускался не от моего пользователя. Тут можно отмониторить по pid процесса, но нужен рут.

strace -p 123 2>&1 | grep file.txt

Гашение вывода 2>&1 позволит не читать тонны ненужной инфы. Но для хардкорных дебаггеров можно убрать.

Еще вот примеры использования strace, перевел отсюда

Смотрим, какие конфиги читает скрипт:

$ strace -e open php 2>&1 | grep php.ini
open("/usr/local/bin/php.ini", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/php.ini", O_RDONLY) = 4

Смотрим, почему скрипт не может открыть определенный файл:

$ strace -e open,access 2>&1 | grep your-filename

Что процесс делает в данный момент:

root@dev:~# strace -p 15427
Process 15427 attached - interrupt to quit
futex(0x402f4900, FUTEX_WAIT, 2, NULL
Process 15427 detached

Следующий пример очень полезен — показывает на что тратится процессорное время скриптом:

root@dev:~# strace -c -p 11084
Process 11084 attached - interrupt to quit
Process 11084 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 94.59    0.001014          48        21           select
  2.89    0.000031           1        21           getppid
  2.52    0.000027           1        21           time
------ ----------- ----------- --------- --------- ----------------
100.00    0.001072                    63           total
root@dev:~#

При таком вызове он будет отображать данные до тех пор, пока принудительно его не завершить.

Можно запросить  раскладку от начала до конца:

root@dev:~# strace -c >/dev/null ls
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 23.62    0.000205         103         2           getdents64
 18.78    0.000163          15        11         1 open
 15.09    0.000131          19         7           read
 12.79    0.000111           7        16           old_mmap
  7.03    0.000061           6        11           close
  4.84    0.000042          11         4           munmap
  4.84    0.000042          11         4           mmap2
  4.03    0.000035           6         6         6 access
  3.80    0.000033           3        11           fstat64
  1.38    0.000012           3         4           brk
  0.92    0.000008           3         3         3 ioctl
  0.69    0.000006           6         1           uname
  0.58    0.000005           5         1           set_thread_area
  0.35    0.000003           3         1           write
  0.35    0.000003           3         1           rt_sigaction
  0.35    0.000003           3         1           fcntl64
  0.23    0.000002           2         1           getrlimit
  0.23    0.000002           2         1           set_tid_address
  0.12    0.000001           1         1           rt_sigprocmask
------ ----------- ----------- --------- --------- ----------------
100.00    0.000868                    87        10 total

Вот такая полезная штука. Man strace, одним словом!

На закуску.

• Простой способ проверки процесса на существование
• Wordpress и memcache 2
• Скрипты для морфологического анализа текста.

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

Вобщем, правится так.

Сначала всем ставим 0644

chmod -R 0644 ./*

Затем папкам ставим 0755

chmod -R 0755 ./$(find . -type d)

P.S. Ну и главное правило напоследок -  Не лезь, блять, с несоображающей головой на рабочий сервер. Надо сюда будет его отправить, там таких много))

P.P.S. Вики рулит )

Восстанавливаем текстовые файлы

find . -type f -exec chmod 644 {} \;

Потом папки

find . -type d -exec chmod 755 {} \;

На закуску.

• Организация бекапа на серверах
• Считаем, сколько строк кода в php проекте.
• Простой способ проверки процесса на существование

На закуску.

• Ничего нет похожего на этот пост, он неповторим

telnet towel.blinkenlights.nl

Кстати, полезный сайтик, много всяких команд для консоли.

На закуску.

• Ничего нет похожего на этот пост, он неповторим

<?php
$processName = 'script.php';
$pathToScript = '/home/alex/script.php';
$check = exec("ps a | grep " .$processName. " | grep -v grep | awk '{print $1}'");
if(strlen($check) < 1){
	    exec("php ". $pathToScript ." ");
	} else {
	    echo 'all done\r\n';
	}

?>

По задумке ставится на минутный крон.

На закуску.

• Простой способ проверки процесса на существование
• Профилирование и отладка PHP скриптов
• Проблемы с сериализацией массивов