session_set_save_handler не коректная работа PHP

Kosarev

Новичок
session_set_save_handler не коректная работа PHP

Проблема, на примере:
m.php
PHP:
<?php
phpinfo();
?>
m1.php
PHP:
<?php
ini_set('session.save_handler', 'user');
phpinfo();

session_set_save_handler('open_session', 'close_session', 'read_session', 'write_session', 'destroy_session', 'gc_session');

function gc_session(){
}
function write_session(){
}
function destroy_session(){
}
function read_session(){
}
function open_session($ad, $df){
}
function close_session(){
}
?>
# curl test/m.php -o /tmp/out
возвращает 32811 байт и
curl: (18) transfer closed with outstanding read data remaining

# curl test/m1.php -o /tmp/out1
возвращает 34027

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

Фанат

oncle terrible
Команда форума
отредактируй свой пост, чтобы привести его в соответстие с правилами (не больше экрана кода).
 

Kosarev

Новичок
Убрал результаты работы diff /tmp/out /tmp/out1, информацию о системе, установленых пакетах и другую инфу.

Cчитал нужным присутствие этих результатов.
 

si

Administrator
не видно чтото описания самой проблемы, кроме того что вам не нравится что страницы разных размеров.
 

Kosarev

Новичок
Автор оригинала: si
не видно чтото описания самой проблемы, кроме того что вам не нравится что страницы разных размеров.
Собственно мои извинения не заметил что сократил суть проблемы.

Проблема следующая при использовании функции session_set_save_handler процес PHP валиться(сообщения об остановки процесса по сигналу 11).

Проект drupal (drupal.org) не могу вообще запустить возвращает пустой ответ. В результате многочисленных тестов открыл что при использовании session_set_save_handler пхп не работает коректно.

Ситуация следующая. 3 сервера, два из них для тестирования на всех FreeBSD 5.3. После апгрейда тестовых серверов появилась эта проблема. Рабочий сервер работает коректно.

Примеры в первом посте должны возвращать один и тот же результат(максимум разницы должно быть несколько байт).

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

SiMM

Новичок
> ini_set('session.save_handler', 'user');
Вот это вот вообще зачем?

> два из них для тестирования на всех FreeBSD 5.3
Версия PHP, наверно, была бы куда полезней? И значение остальных session-параметров (auto_start, например).
 

Kosarev

Новичок
ini_set('session.save_handler', 'user');

по умолчанию files.


Все значения session параметров стандартные(по умолчанию, auto_start = off). Проблема появилась достаточно давно. Я провёл огромное число експерементов. В том числе пересобрал apache2 и ПХП. Пробавал с apache 1.3 , пробавал вручную собирать(все пaкеты поставлены из портов) -- результат один и тот же:

drupal возвращает нулевой результат.
Пример из первого поста показывает примерно теже результаты(разница в несколько байт).

О версиях я писал до сокращения в первом посте...

Система портов обновлена и проведён portupgrade -a .
php - 4.3.11
apache - 2.0.54
 

si

Administrator
нужен backtrace падения, как это сделать читать тут
http://bugs.php.net/how-to-report.php

P.S предварительно следует поставить последние стабильные версии PHP и apache 1.3
 

Фанат

oncle terrible
Команда форума
как-то я не очень понимаю значение слова "drupal возвращает нулевой результат"
как будто drupal - это функция.
если что-то не работает - оно выдаёт сообщения об ошибках.
причём обычно сообщения валятся каскадом.

при чём тут курл - тоже непонятно.

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

SiMM

Новичок
> ini_set('session.save_handler', 'user');
> по умолчанию files.
Если ты делаешь session_set_save_handler, то трогать session.save_handler, насколько я понимаю, нет никакой необходимости.
 

Kosarev

Новичок
Автор оригинала: Фанат
как-то я не очень понимаю значение слова "drupal возвращает нулевой результат"
как будто drupal - это функция.
если что-то не работает - оно выдаёт сообщения об ошибках.
причём обычно сообщения валятся каскадом.

при чём тут курл - тоже непонятно.

почему вопросы задаются на форуме по пхп, а не службе поддержски дурпала - опять загадка.
curl localhost/drupal/
Empy result.

Писал в службу поддержки друпал неделю назад не помогли.

-~{}~ 22.06.05 11:18:

Автор оригинала: si
нужен backtrace падения, как это сделать читать тут
http://bugs.php.net/how-to-report.php

P.S предварительно следует поставить последние стабильные версии PHP и apache 1.3
Спасибо. Я не знал куда обращаться с этой проблемой.
 

Фанат

oncle terrible
Команда форума
Kosarev
а что - логи у вас запрещены?
запрос курлом - это единственный способ обратиться к тестовому серверу? и этот запрос на тестовом сервере не оставляет никаких следов? Апач ничего не видел, пхп не поднимался, да?
 

Kosarev

Новичок
Автор оригинала: SiMM
> ini_set('session.save_handler', 'user');
> по умолчанию files.
Если ты делаешь session_set_save_handler, то трогать session.save_handler, насколько я понимаю, нет никакой необходимости.
попробовал без. Результат тот же.
 

Kosarev

Новичок
Автор оригинала: Фанат
Kosarev

а что - логи у вас запрещены?
запрос курлом - это единственный способ обратиться к тестовому серверу? и этот запрос на тестовом сервере не оставляет никаких следов? Апач ничего не видел, пхп не поднимался, да?
В лога собщение о завершении процеса по сигналу 11. Пробывал выставлять перенаправляние ошибок ПХП в файл, файл остаёться пустым.

курлом удобней. Можно хедеры подать и посмотреть. Только при опыте обращения к директории с друпала ответ нулевой(в том числе и хедеров нет)

ПХП - работает чудестно с проектами не использущими session_set_save_handler
При использовани получаю не ожиданные результаты.
 

tony2001

TeaM PHPClub
поставьте последний снэпшот 4.4.
не поможет - покажите бэкстрэйс по ссылке данной выше есть целая страница на тему его генерации.

о чем тут вообще столько текста? о чем можно рассуждать, не видя ничего, кроме симптомов?
"- больной перед смертью потел? - да. - это очень хороший признак." (с)
 
Сверху