Ars Longa, Vita Brevis » PHP

SQLMon для Yii

Vladimir — Tue, 22 Nov 2011 15:02:18 +0000

Расширение для анализа производительности SQL-запросов для Yii

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

Ситуацию частично исправило расширение под названием Yii DB profiler. Но остались некоторые неудобства:

Отображение запросов в порядке убывания времени выполнения — в принципе, это дело вкуса: при таком порядке сразу видны проблемные запросы. С другой стороны, лично мне более привычен хронологический порядок — так чётче прослеживается логика работы;
Prepared statements. Это просто здорово, но если повторять запрос в phpMyAdmin (например, если интересует план выполнения запроса), бывает очень муторно заменять все связанные значения. Например, для запросов вида

SELECT 't'."object_id" AS "t0_c0", 't'."ymd" AS "t0_c1", 't'."black" AS "t0_c2", 't'."brown" AS "t0_c3", 't'."yellow" AS "t0_c4",
't'."neutral" AS "t0_c5", 't'."white" AS "t0_c6", 't'."unknown" AS "t0_c7", 't'."error" AS "t0_c8", 'object'."object" AS "t1_c2",
'object'."id" AS "t1_c0"
FROM 'dnsbl_summary' 't'
LEFT OUTER JOIN 'objects' 'object' ON ('t'."object_id"='object'."id")
WHERE (((black > 0) OR (brown > 0)) AND
(((((((((ymd=:ycp0) AND (black>:ycp1)) AND (brown=:ycp2)) AND (yellow=:ycp3)) AND
(neutral>:ycp4)) AND (white>:ycp5)) AND (unknown=:ycp6)) AND (black>:ycp7)) AND
(error=:ycp8))) AND (object.enabled = 1)
LIMIT 50

заменять все :ycpXXX на их значения немного муторно. В общем случае здесь вряд ли можно что-то сделать — заполнители параметров могут быть любыми (и даже позиционными), поэтому тупое использование str_replace может наделать делов.

Лично мне список запросов нужен обычно только для двух вещей:

Оценка работы механизмов кэширования;
Оценка плана выполнения запроса, составленная оптимизатором.

Первое обычно не критично (зачастую достаточно посмотреть на количество запросов), а вот второе позволяет выявить многие будущие проблемы с производительностью заранее.

В результате, взяв за основу плагин Александра, я портировал SQLMon на Yii.

В результате получилось расширение, позволяющее получать планы выполнения запросов в реальном времени.

Поддерживаются MySQL и SQLite, в планах поддержка PgSQL (там не всё просто, ибо Postgres выполняет запрос, что может привести к интересным последствиям при использовании INSERT/UPDATE/DELETE; как следствие, придётся использовать вложенные транзакции).

Вывод результатов осуществляется либо при помощи виджета:

$this->widget(
'ext.sqlmon.components.SQLMon'
array(
'explain' => true, // Показывать план выполнения запроса
'backtrace' => true, // Показывать трассу вызовов
'dsn' => true, // Показывать DSN соединения (может быть полезно при использовании нескольких БД)
'cssFile' => null, // Эстеты могут задать свой файл стилей
)
);

Либо при помощи Log Route:

return array(
'components' => array(
'log' => array(
'routes' => array(
array(
'class' => 'ext.sqlmon.components.SQLMonLogRoute',
'showExplain' => true, // Показывать план выполнения
'showDsn' => true, // Показывать DSN соединения
'showBacktrace' => true, // Показывать трассу вызовов
),
array(
'class' => 'ext.sqlmon.components.SQLMonFileLogRoute',
'logFile' => 'sqlmon.log',
'showExplain' => true, // Показывать план выполнения
'showDsn' => true, // Показывать DSN соединения
'showBacktrace' => true, // Показывать трассу вызовов
),
),
)
),
);

SQLMonLogRoute наследуется от CWebLogRoute, но, как и CProfileLogRoute, отказывается выдавать данные для AJAX-запросов.

SQLMonFileLogRoute наследуется от CFileLogRoute и, как следствие, воспринимает все параметры конфигурации последнего.

Для того, чтобы протоколирование нормально работало, сообщения от SQLMon попадают в общий протокол и, как следствие, видны при использовании CWebLogRoute (в этом случае выдаётся минимум информации).

Результаты работы выглядят примерно так (пример приведён для SQLite):

Реализовано всё через собственный класс PDO, поэтому для использования SQLMon нужно в файл конфигурации добавить такие строки:

return array(
'import' => array(
'ext.sqlmon.components.*',
),

'components' => array(
'db' => array(
// ...
'pdoClass' => 'SQLMonPDO',
),
),
);

Реализация просмотра выполнения плана выполнения запроса осуществляется при помощи класса-наследника от PDOStatement и переопределения метода PDO::prepare().

Планы на будущее:

поддержка PostgreSQL;
возможность расширения классов SQLMonPDO и SQLMonPDOStatement (возможно, придётся позаимствовать некоторые идеи из Kohana);
наследование SQLMon_Explainer_Base от CComponent, что даст дополнительные плюшки для расширяемости;
более красивая реализация функции SQLMon::arr2pre(), что позволит рисовать красивые ASCII-таблички;
возможная поддержка FireBug;
протоколирование в HTML-файл;
информация профайлера MySQL (нужность пока под большим вопросом);
рефакторинг, написание документации

SQLMon 0.1 for Yii — скачать бесплатно без регистрации без смс

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Преобразование ошибок в PHP в исключения

Vladimir — Wed, 17 Aug 2011 21:13:06 +0000

Механизм трансляции ошибок в исключения с целью последующей обработки

Навеяно этим сообщением на форуме.

Дано:

фреймворк перехватывает все возникающие ошибки (которые разрешены текущим значением error_reporting()) и аварийно завершает работу скрипта (в целях отладки/безопасности/нужное подчеркнуть);
имеется код, вызывающий PHP-функцию, которая может сгенерировать предупреждение (в оригинальном сообщении это mkdir() — кидает E_WARNING, если не удаётся создать каталог)
местные стандарты кодирования запрещают использование оператора @ (довольно распространённая практика).

Требуется обработать возникшую ошибку без авоста скрипта.

Сначала рассмотрим предложенные варианты решений и наведём критику (как же без этого).

Способ 1:

В PHP существуют специальные функции (is_dir, is_writable, …), в зависимости от возвращаемого значения которых вы можете генерировать соответствующее сообщение.

Идея в том, чтобы проверять все возможные ошибочные ситуации до вызова проблемной функции. С одной стороны по-хорошему так и надо поступать. С другой стороны, всего не предусмотришь — а если создавать обёртку для каждой проблемной функции, код может очень сильно раздуться. К тому же следует помнить, что проверка на возможные ошибки с последующим вызовом функции — операция неатомарная. Иными словами, требуемый каталог может быть создан другим скриптом в следующее мгновение после того, как проверка на существование создаваемого каталога вернула отрицательный результат. Для каталогов это, возможно, не очень актуально, но для операция с сокетами — самое то.

Способ 2: изменение error_reporting.

Что-то типа:

$level=error_reporting();
error_reporting($level | ~E_WARNING | ~E_ERROR);

if(!is_dir($path) && false===mkdir($path))
throw new CException(Yii::t('myapp','Can not create path "{path}"',array('{path}'=>$path)));

error_reporing($level);

Убирать E_ERROR всё же не стоит.
Опять же, создание обёртки для каждой проблемной функции раздует код. К тому же вызов error_reporting() — не самая быстрая операция (по крайней мере раньше было именно так).

Способ 3:

Мы в текущем проекте столкнулись с приблизительно такой же проблемой: Memcache генерит PHP-ошибки, а не исключения, которые хотя бы через try/catch можно было отловить.
Пришлось изобретать свой хэндлер и «оборачивать» все обращения к мемкешу предвалительно нашим «молчаливым» хэндлером:

function mcSilenceErrorHandler($errno, $errstr, $errfile, $errline)
{
QLogger::log('memcache_errors', $errstr . ' at (' . $errfile . ':' . $errline . ')');
return true;
}

В самом коде используется так, что перед потенциально «опасными» обращениями к мемкешу, мы выставляем свой «молчаливый» хэндлер, а потом возвращаем старый – Yii’шный – хэндлер.

public function flush()
{
$result = false;

$old_handler = set_error_handler('mcSilenceErrorHandler');
$result = $this->_cache->flush();
set_error_handler($old_handler);

return $result;
}

Решение à la Способ №2, обладающее практически теми же недостатками.

Ну а теперь собственно предлагаемое решение.

Как известно, PHP позволяет пользователю установить собственные обработчики для обработки ошибок и необработанных исключительных ситуаций. Решение же состоит в том, чтобы из обработчика ошибок кинуть исключение. Исключение либо будет перехвачено в блоке try/catch где-то в коде, либо не будет обработано пользовательским кодом и будет перехвачено в обработчике необработанных исключений (что приведёт к аварийному завершению скрипта).

Код будет выглядеть примерно так:

После такого можно писать:

try {
mkdir($dir);
}
catch (ErrorException $e) {
echo 'Всё плохо при создании каталога: ', $e;
}

Так как тема взята с форума Yii, рассмотрим, как интегрировать всё это безобразие с Yii:

class MyWebApplication extends CWebApplication
{
public function __construct($config=null)
{
parent::__construct($config);
register_shutdown_function(array($this, 'shutdown'));
if (YII_ENABLE_EXCEPTION_HANDLER && !YII_ENABLE_ERROR_HANDLER) {
set_error_handler(array($this, 'myErrorHandler'));
}
}

public function shutdown()
{
if (YII_ENABLE_EXCEPTION_HANDLER && ($error = error_get_last()) && in_array($error['type'], array(E_PARSE, E_ERROR, E_USER_ERROR))) {
$this->handleException(new ErrorException($error['message'], $error['type'], 0, $error['file'], $error['line']));
die();
}
}

public function myErrorHandler($code, $error, $file = null, $line = null)
{
if (error_reporting() & $code) {
throw new ErrorException($error, $code, 0, $file, $line);
}

return true;
}
}

Использование:

define('YII_ENABLE_ERROR_HANDLER', false);
define('YII_ENABLE_EXCEPTION_HANDLER', true);

require_once 'protected/components/MyWebApplication.php';
Yii::createApplication('MyWebApplication', $config)->run();

Перехват фатальных ошибок в Yii

Vladimir — Sun, 07 Aug 2011 08:06:17 +0000

Облегчаем жизнь разработчику

Как и Kohana, Yii помогает разработчику, отлавливая неперехваченные исключения и ошибки в коде. Как и в Kohana, реализуется это одинаково — через функции PHP set_exception_handler() и set_error_handler(). Но, в отличие от Kohana, Yii не умеет перехватывать фатальные ошибки (E_ERROR в терминах PHP).

Как следствие, если приложение сгенерирует фатальную ошибку (например, вызов несуществующей функции), у разработчика все шансы об этом не узнать (например, на production-сервере с display_errors установленным Off). Конечно, если приложение хорошо протестировано шансы возникновения такой ситуации близки к нулю, но если приложение позволяет пользователю устанавливать какие-либо свои дополнения, то лучше узнавать о проблемах прежде, чем начальник получит кучу гневных писем

Причина, по которой Yii не может обработать фатальные ошибки заключается в том, что PHP принципиально не вызывает функции, установленные set_error_handler(), при возникновении ошибок типа E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING.

Тем не менее, Kohana умеет перехватывать E_ERROR, поэтому было бы неплохо добавить такую поддержку и в Yii.

Вся магия заключается в том, что функции, зарегистрированные при помощи register_shutdown_function() вызываются даже в случае E_ERROR. А определить наличие ошибки можно при помощи функции error_get_last().

У меня получился такой код:

class MyWebApplication extends CWebApplication
{
public function __construct($config=null)
{
parent::__construct($config);
register_shutdown_function(array($this, 'shutdown'));
}

public function shutdown()
{
if (YII_ENABLE_ERROR_HANDLER && ($error = error_get_last())) {
$this->handleError($error['type'], $error['message'], $error['file'], $error['line']);
die();
}
}
}

Пользоваться так:

require_once 'protected/components/MyWebApplication.php';
Yii::createApplication('MyWebApplication', $config)->run();

Вложенные транзакции в PDO

Vladimir — Sat, 06 Aug 2011 07:21:34 +0000

Использование вложенных транзакций в MySQL и PostgreSQL с PDO

В PDO есть такая особенность: отсутствие поддержки вложенных транзакций.

Вложенные транзакции бывают весьма полезны: например, у нас есть два сервиса, которые могут взаимодействовать между собой. Сервис А начинает транзакцию, что-то делает, затем вызывает сервис Б, затем подтверждает транзакцию.

Может так случиться, что сервисы А и Б разрабатываются разными людьми и разработчик сервиса Б может не знать, что сервис А уже начал выполнение транзакции. Как следствие, при использовании PDO как только сервис Б попытается начать транзакцию, PDO выбросит исключение, предупреждающее о наличии активной транзакции.

Тем не менее, такие СУБД как MySQL и PostgreSQL поддерживают вложенные транзакции (о чём PDO не знает). Поэтому было бы неплохо добавить поддержку вложенных транзакций для данных СУБД в PDO.

Ниже приведена очень простая реализация поддержки вложенных транзакций в PDO:

class MyPDO extends PDO
{
protected static $_supported_drivers = array(
'mysql' => true,
'pgsql' => true,
);

protected $_nest_level = 0;

protected function nestedTransactionsSupported()
{
return !empty(self::$_supported_drivers[$this->getAttribute(PDO::ATTR_DRIVER_NAME)]);
}

public function beginTransaction()
{
if (!$this->_nest_level || !$this->nestedTransactionsSupported()) {
parent::beginTransaction();
}
else {
$this->exec("SAVEPOINT LEVEL{$this->_nest_level}");
}

++$this->_nest_level;
}

public function commit()
{
--$this->_nest_level;

if (!$this->_nest_level || !$this->nestedTransactionsSupported()) {
parent::commit();
}
else {
$this->exec("RELEASE SAVEPOINT LEVEL{$this->_nest_level}");
}
}

public function rollBack()
{
--$this->_nest_level;

if (!$this->_nest_level || !$this->nestedTransactionsSupported()) {
parent::rollBack();
}
else {
$this->exec("ROLLBACK TO SAVEPOINT LEVEL{$this->_nest_level}");
}
}
}

Подводные камни: в MySQL есть такое понятие как неявное подтверждение транзакции (implicit commit). На практике это ломает уровень вложенности транзакций, поддерживаемый данной реализацией. С другой стороны, в web-приложениях редко возникает необходимость использования транзакций (тем более вложенных) там, где присутствуют операторы, вызывающие неявное подтверждение транзакции.

Автоматическая проверка репутации IP-адреса

Vladimir — Thu, 03 Feb 2011 02:51:44 +0000

На примере SendMail, Reputation Authority, SenderBase и SenderScore

Репутация IP-адреса — одна из очень важных составляющих, используемых для борьбы с почтовым спамом.

Письма приходят с IP-адресов, а репутация этих адресов может сказать, является ли данный адрес ответственным за рассылку спама или нет. По некоторым данным проверка репутации IP-адресов позволяет остановить порядка 80% спама.

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

Очень часто для отправки писем используется множество адресов — в частности из-за того, что крупные почтовые сервисы (GMail, Yahoo!, Hotmail, AOL, ….) имеют различные ограничения на количество сообщений, принимаемых с одного адреса, а также на скорость отправки почтовых сообщений. Например, компания, которую мы консультируем, рассылает более 100,000,000 писем в месяц, для чего используется не один десяток IP-адресов.

Естественно, что ручная проверка сотен адресов в десятке различных сервисов — занятие неблагодарное и утомительное. Но, к счастью, всё автоматизируется, что будет рассмотрено на примере PHP.

Очень часто для извлечения данных из web-страницы (data scraping) используются регулярные выражения. Но это вчерашний день К тому же не всегда просто составить эффективное регулярное выражение, которое сразу выберет все необходимые данные — с большой вероятностью могут потребоваться несколько выражений и доводка результата напильником.

Простая и достойная альтернатива регулярным выражениям — XPath. Тем более, что построить нужный XPath можно при помощи FireBug (он позволяет скопировать адрес выделенного элемента как XPath).

Рассмотрим на примере SenderScore. Репутация проверяется по ссылке вида https://senderscore.org/lookup.php?lookup=1.1.1.1, где вместо 1.1.1.1 задаётся IP-адрес.

Как видно на скриншоте, FireBug показывает XPath требуемого элемента. Но при знании XPath можно использовать и более простое выражение.

Как это выглядит на PHP:

$oldSetting = libxml_use_internal_errors(true);
libxml_clear_errors();
$html = new DOMDocument();
$html->loadHtmlFile('https://senderscore.org/lookup.php?lookup=1.1.1.1');

$xpath = new DOMXPath($html);
echo 'Sender Score: ', $xpath->query('//div[@id="senderscore_number"]')->item(0)->nodeValue, "\n";

libxml_clear_errors();
libxml_use_internal_errors($oldSetting);
?>

XPath для других сервисов

Reputation Authority

http://reputationauthority.org/lookup.php?ip=1.1.1.1

Поиск ведётся относительно вершины //div[@class="LookupIP-content"]/table[2]/tr[4]/td

Reputation Score: .//table/tr[2]/td[2]
Clean emails: .//table[2]/tr[2]/td[2]
Viruses: .//table[2]/tr[3]/td[2]
Spam: .//table[2]/tr[4]/td[2]
Malformed Emails: .//table[2]/tr[5]/td[2]
Suspicious Emails: .//table[2]/tr[6]/td[2]
Good Users: .//table[2]/tr[8]/td[2]
Bad Users: .//table[2]/tr[9]/td[2]

SenderBase

http://www.senderbase.org/senderbase_queries/rep_lookup?search_name=1.1.1.1&action%3ASearch=Search

При запросе страницы User-Agent должен быть похожим на нормальный браузер.

Email Reputation //div[@id="tab1body"]//span[1]/text()
Web Reptation //div[@id="tab2body"]//span[1]/text()

SendMail

http://sendmail.com/sm/resources/tools/ip_reputation/ip_reputation_results/index.shtml?IP=1.1.1.1&search.x=1&search.y=1&search=Submit

При запросе страницы Referer должен указывать на http://sendmail.com/sm/resources/tools/ip_reputation/.

Поиск ведётся относительно вершины //dev[@id="content"]/table[@class="ip_reputation"]

IP Reputation Class: .//tr[4]/td[2]/text()
Volume (может отсутствовать) .//tr[5]/td[2]
Weighted Risk .//tr[6]/td[2] (если Volume отсутствует, то .//tr[5]/td[2])
Spam Ratio (может отсутствовать) .//tr[7]/td[2]
Valid Bulk Ratio (может отсутствовать) .//tr[8]/td[2]

Либо можно использовать проверку текста:

Volume .//tr/td[1][normalize-space()="Volume"]/following-sibling::td[1]
Weighted Risk .//tr/td[1][normalize-space()="Weighted Risk"]/following-sibling::td[1]
Spam Ratio .//tr/td[1][normalize-space()="Spam Ratio"]/following-sibling::td[1]
Valid Bulk Ratio .//tr/td[1][normalize-space()="Valid Bulk Ratio"]/following-sibling::td[1]

Особенности работы функции checkdnsrr()

Wandering Soul — Fri, 24 Sep 2010 12:49:56 +0000

Иногда «Да» означает «Нет»

Функция checkdnsrr() используется для проверки существования записей DNS. Например, фреймворк Kohana использует эту функцию для проверки наличия MX-записи домена, указанного в адресе электронной почты.

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

В Linux есть магический файл — /etc/resolv.conf; он отвечает за конфигурацию резолвера (набор функций в библиотеке C, предоставляющих доступ к Internet DNS).

В этом файле может быть задан параметр search, в котором задаётся список дополнительных доменов для поиска (обычно локальное имя домена).

Этот параметр может оказывать очень сильное влияние на результат, возвращаемый checkdnsrr(). Например, при поиске записи типа A для несуществующего домена checkdnsrr() вернёт 0:

$ php -r 'echo (int)checkdnsrr("x.y", "A"), "\n";'
0

Но если вдруг в /etc/resolv.conf задан параметр search, то результат уже не так однозначен. Например, если имеется запись

search example.com

то алгоритм поиска будет таким:

Сначала система будет пытаться найти запись A для несуществующего домена x.y;
Так как домен с таким именем не существует, система будет пробовать суффиксы, перечисленные в параметре search. В нашем случае система будет искать домен x.y.example.com

Если у домена example.com есть wildcard-запись типа A (*.example.com. IN A 1.2.3.4), то checkdnsrr() вернёт true — хотя это и не тот результат, который ожидается.

С проверкой MX-записей может возникнуть такая же ситуация: например, если имеются такие записи DNS:

*.example.com. IN CNAME example.com.
example.com. IN MX 10 mail.example.com.

В этом случае при наличии search example.com в /etc/resolv.conf checkdnsrr() будет возвращать true для любых доменов.

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

$result = checkdnsrr("x.y.", "A");

В этом случае над именем не будет проводиться никаких манипуляций, и результат будет не таким неопределённым

DoS для PHP через imap_fetchbody

Wandering Soul — Mon, 16 Aug 2010 07:04:55 +0000

Пример исследования дампа памяти для нахождения ошибки

Как оказалось, если передать функции imap_fetchbody() параметр $secton, длина которого больше 1004 байт, PHP падает по segmentation fault. На некоторых конфигурациях с применением некоторых усилий (подробности, понятное дело, разглашаться не будут) получалось вместе с PHP положить и Apache.

Пример кода, убивающего PHP:

imap_fetchbody($imap_handle, $message_number, "3.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.0");

Предполагается, что $imap_handle — ресурс, возвращенный функцией imap_open(), $message_number — номер существующего сообщения в почтовом ящике.

Анализ посмертного дампа памяти показывает, где происходит сбой:

$ gdb /usr/bin/php core
...
Program terminated with signal 11, Segmentation fault.
#0 memcpy () at ../sysdeps/x86_64/memcpy.S:398
398 ../sysdeps/x86_64/memcpy.S: Нет такого файла или каталога.
in ../sysdeps/x86_64/memcpy.S
(gdb) bt full
#0 memcpy () at ../sysdeps/x86_64/memcpy.S:398
No locals.
#1 0x0000000000678788 in _estrndup (s=0x7ff1797aaf4e "", length=2136037704) at /usr/include/bits/string3.h:52
No locals.
#2 0x00007ff1799ce292 in zif_imap_fetchbody () from /usr/lib/php5/20090626/imap.so
No symbol table info available.
#3 0x00000000006e611a in zend_do_fcall_common_helper_SPEC (execute_data=0x7ff17f3e3068) at /build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:313
opline = 0x7ff17f5141a8
should_change_scope = 200 '\310'
...

Видно, что ошибка произошла в функции zif_imap_fetchbody() (что соответствует PHP-функции imap_fetchbody()), когда та вызвала функцию estrndup() для пустой строки (адрес строки — 0x7ff1797aaf4e), но при этом передав ошибочную длину строки (length=2136037704). Значение length примерно равное двум гигабайтам в любом случае должно настораживать.

Пересоберём php5-imap с отладочной информацией:

CFLAGS="-g3 -O2"
export CFLAGS
phpize
./configure --with-kerberos --with-imap-ssl PHP_OPENSSL="yes"
make && sudo make install

Повторим тест. PHP по-прежнему должен упасть. На этот раз у нас будет больше информации о сбое:

(gdb) bt full
#0 memcpy () at ../sysdeps/x86_64/memcpy.S:398
No locals.
#1 0x0000000000678788 in _estrndup (s=0x7ff8881ddf4e "", length=2381609288) at /usr/include/bits/string3.h:52
No locals.
#2 0x00007ff8884013c2 in zif_imap_fetchbody (ht=3, return_value=0x7ff88df465d0, return_value_ptr=, this_ptr=, return_value_used=) at /opt/php-imap-5.3.2/php_imap.c:2361
streamind = 0x7ff88df46670
msgno = 1
flags = 0
body = 0x0
sec = 0x7ff88df468c8 "3.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1."...
sec_len = 1005
len = 140705510226248

Теперь у нас есть номер строки, где произошел сбой (файл /opt/php-imap-5.3.2/php_imap.c, строка 2361).

(gdb) frame 2
#2 0x00007ff8884013c2 in zif_imap_fetchbody (ht=3, return_value=0x7ff88df465d0, return_value_ptr=, this_ptr=, return_value_used=) at /opt/php-imap-5.3.2/php_imap.c:2361
2361 RETVAL_STRINGL(body, len, 1);
(gdb) print len
$1 = 140705510226248
(gdb) print &len
$2 = (long unsigned int *) 0x7ffffa9bdd80
(gdb) frame 1
#1 0x0000000000678788 in _estrndup (s=0x7ff8881ddf4e "", length=2381609288) at /usr/include/bits/string3.h:52
warning: Source file is more recent than executable.
52 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
(gdb) print s
$3 = 0x7ff8881ddf4e ""
(gdb) print length
$4 = 2381609288

О локальной переменной len сказать что-либо трудно, так как функция __builtin___memcpy_chk() могла ее перетереть. Придется исправлять код.

Находим в php_imap.c в функции imap_fetchbody строку

body = mail_fetchbody_full(imap_le_struct->imap_stream, msgno, sec, &len, (argc == 4 ? flags : NIL));

и исправляем её на

printf("len before = %ld\n", len);
body = mail_fetchbody_full(imap_le_struct->imap_stream, msgno, sec, &len, (argc == 4 ? flags : NIL));
printf("len after = %ld\n", len);

Пересобираем, запускаем, получаем:

len before = 140425249339720
len after = 140425249339720
Segmentation fault (core dumped)

Становится видно, что по каким-то причинам функция mail_fetchbody_full() может вернуть пустую строку, но при этом не установить len в 0.

Исправление тривиально: находим

unsigned long len;

Заменяем на

unsigned long len = 0;

Пересобираем, устанавливаем, запускаем — voilà, ошибка исчезла, php больше не падает.

Результат: полчаса потраченного времени, ошибка исправлена, php не падает.

Исправление ошибки в INSERT INTO … SELECT в Kohana 3 при использовании конфигурации базы данных, отличной от default

Wandering Soul — Thu, 12 Aug 2010 07:40:55 +0000

Исправление короче описания

Ситуация: нужно выполнить запрос вида

INSERT INTO `table` (`col1`, `col2`) SELECT * FROM `table` WHERE `col1` <> 0;

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

Например:

// application/config/database.php
// Важно, чтобы в конфигурации default нельзя было подключиться к серверу
return array(
'test' => array(
'type' => 'mysql',
'connection' => array(
'hostname' => 'localhost',
'database' => 'test',
'username' => 'username',
'password' => 'password',
'persistent' => FALSE,
),
'table_prefix' => '',
'charset' => 'utf8',
'caching' => FALSE,
'profiling' => TRUE,
),
);
?>

// application/classes/controller/welcome.php

class Controller_Welcome extends Controller
{
public function action_index()
{
$this->request->response = DB::insert('test', array('col1', 'col2'))
->select(DB::select()->from('test')->where('column1', '<>', '0'))
->compile(Database::instance('test')) . "\n";
}
}

?>

Важно, чтобы правая часть условия в where() была строкой.

В результате если мы запустим проект, то получим что-то вида:

INSERT INTO `test` (`column1`, `column2`) ErrorException [ 2 ]: mysql_connect(): Access denied for user 'www-data'@'localhost' (using password: NO) ~ MODPATH/database/classes/kohana/database/mysql.php [ 56 ]

Связано это с особенностью реализации метода Kohana_Database_Query_Builder_Insert::compile():

public function compile(Database $db)
{
// Start an insertion query
$query = 'INSERT INTO '.$db->quote_table($this->_table);

// Не интересно
// …

if (is_array($this->_values))
{
// Не интересно
// …
$query .= 'VALUES '.implode(', ', $groups);
}
else
{
// Add the sub-query
$query .= (string) $this->_values;
}

return $query;
}

Строка $query .= (string) $this->_values; вызывает метод compile() для SELECT, но так как конфигурация базы данных не передаётся, используется конфигурация default.

Самое простое исправление очевидно: заменить строку

$query .= (string) $this->_values;

на

$query .= $this->_values->compile($db);

Тем не менее, если SELECT использует одну базу данных, а INSERT — другую, и при этом используются разные charset’ы (да, это не самое большое извращение — бывают и хуже), этого будет недостаточно. В этом случае нужно добавить дополнительный параметр в метод select(), указывающий, какую конфигурацию использовать. Требуемые изменения кода тривиальны, посему остаются упражнением интересующемуся читателю.

Поддержка JOIN в запросах DELETE для Kohana 3

Wandering Soul — Wed, 11 Aug 2010 10:48:13 +0000

Добавление поддержки multiple-table DELETE в Query Builder Kohana 3

Иногда бывает полезно выполнить удаление записей в нескольких связанных таблицах, благо синтаксис позволяет. Разумеется, есть такая вещь как каскадное удаление записей, но в случае с MySQL (а именно — таблицами MyISAM) на неё надеяться не приходится.

Модуль Database из Kohana 3 не умеет использовать JOIN с операцией DELETE. Нужно ему помочь.

class Database_Query_Builder_Delete extends Kohana_Database_Query_Builder_Delete
{
protected $_to_delete = array();
protected $_join = array();
protected $_last_join;

/**
* Adds addition tables to "JOIN ...".
*
* @param mixed column name or array($column, $alias) or object
* @param string join type (LEFT, RIGHT, INNER, etc)
* @return Database_Query_Builder_Delete
*/
public function join($table, $type = NULL)
{
$this->_join[] = $this->_last_join = new Database_Query_Builder_Join($table, $type);

return $this;
}

public function delete_table($table)
{
$this->_to_delete[] = $table;
}

/**
* Adds "ON ..." conditions for the last created JOIN statement.
*
* @param mixed column name or array($column, $alias) or object
* @param string logic operator
* @param mixed column name or array($column, $alias) or object
* @return $this
*/
public function on($c1, $op, $c2)
{
$this->_last_join->on($c1, $op, $c2);

return $this;
}

/**
* Compile the SQL query and return it.
*
* @param Database Database instance
* @return string
*/
public function compile(Database $db)
{
$query = 'DELETE';
if ($this->_to_delete) {
$query .= ' ' . join(', ', array_map(array($db, 'quote_identifier'), $this->_to_delete));
}

$query .= ' FROM ' . $db->quote_table($this->_table);

if ($this->_join) {
$query .= ' ' . $this->_compile_join($db, $this->_join);
}

if ($this->_where) {
$query .= ' WHERE ' . $this->_compile_conditions($db, $this->_where);
}

if (!$this->_join) {
if ($this->_order_by) {
$query .= ' ' . $this->_compile_order_by($db, $this->_order_by);
}

if ($this->_limit !== null) {
$query .= ' LIMIT ' . $this->_limit;
}
}
else {
throw new Kohana_Exception('Cannot use ORDER BY or LIMIT in a multiple-table DELETE');
}

return $query;
}

public function reset()
{
parent::reset();
$this->_to_delete = array();
$this->_join = array();
$this->_last_join = null;
}
}

?>

Данный класс добавляет функциональность, связанную с удалением данных из нескольких таблиц, в Query Builder. Использование покажу на примерах:

Запросу

DELETE t1, t2 FROM t1 INNER JOIN t2 INNER JOIN t3
WHERE t1.id=t2.id AND t2.id=t3.id;

соответствует код

DB::delete('t1')
->join('t2', 'INNER')
->on('t1.id', '=', 't2.id')
->join('t3', 'INNER')
->on('t2.id', '=', 't3.id')
->delete_table('t1')
->delete_table('t2');

Запросу

DELETE FROM t1 INNER JOIN t2 INNER JOIN t3
WHERE t1.id=t2.id AND t2.id=t3.id;

соответствует код

DB::delete('t1')
->join('t2', 'INNER')
->on('t1.id', '=', 't2.id')
->join('t3', 'INNER')
->on('t2.id', '=', 't3.id');

Как видим, метод Database_Query_Builder_Delete::delete_table() задаёт имена таблиц, которые нужно удалить; если данный метод не вызывать, будут удалены все таблицы, перечисленные в запросе.

Патч для кэширования пустых результатов запросов в Kohana

Wandering Soul — Wed, 11 Aug 2010 08:25:23 +0000

Простое исправление досадного недоразумения

Проблема: Kohana 3 (3.0.7, возможно, ранние версии) не может брать результаты запросов из кэша, если запрос вернул пустой результат.

Решение проблемы.

Разгадка кроется в файле modules/database/classes/kohana/database/query.php. Дело в том, что в PHP проверки вида if ($condition) возвращают false, если вычисленное значение $condition — 0, null, false, "", array(), ….

Поэтому в такой проверке:

if ($result = Kohana::cache($cache_key, NULL, $this->_lifetime))
{
// Return a cached result
return new Database_Result_Cached($result, $sql, $this->_as_object);
}

условие всегда будет ложно для пустых результатов.

Исправляется просто: из исходного кода Kohana::cache() видно, что Kohana::cache() возвращает null, если объект в кэше не найден либо произошла ошибка. Следовательно,

if (($result = Kohana::cache($cache_key, NULL, $this->_lifetime)) !== null)
{
// Return a cached result
return new Database_Result_Cached($result, $sql, $this->_as_object);
}

даст корректный результат.