Zveruga
Новичок
Мега-глюк с mssql_connect
Небольшое вступление:
Есть два веб-сервера (рабочий и тестовый). Конфигурации практически идентичные, чтобы в случае чего можно было делать экстренную замену рабочего сервера сразу на тестовый. И новые версии ПО сначала ставятся и опробируются на тестовом серваке.
сервер #1:
Apache/1.3.37 (Unix) PHP/5.2.1 mod_ssl/2.8.28 OpenSSL/0.9.7l rus/PL30.22
собран с настройками:
'./configure' '--with-mysql=/root/install/mysql-4.1.21' '--with-mnogosearch=/usr/local/mnogosearch' '--with-mysql' '--with-charset' '--with-sybase=/usr/local/freetds' '--with-zlib' '--enable-gd-native-ttf' '--with-png-dir=../graphlib/libpng-1.0.6' '--with-ttf' '--with-apache=../apache_1.3.37rusPL30.23' '--with-gd' '--with-iconv' '--with-openssl=/usr/local/ssl' '--with-curl=/usr/local/lib'
сервер #2:
Apache/1.3.37 (Unix) PHP/5.2.3 mod_ssl/2.8.28 OpenSSL/0.9.7l rus/PL30.22
собран с настройками:
'./configure' '--with-mysql=/root/install/mysql-5.0.41' '--with-mnogosearch=/usr/local/mnogosearch' '--with-mysql' '--with-charset' '--with-sybase=/usr/local/freetds' '--with-zlib' '--enable-gd-native-ttf' '--with-png-dir=../graphlib/libpng-1.0.6' '--with-ttf' '--with-apache=../apache_1.3.37rusPL30.23' '--with-gd' '--with-iconv' '--with-openssl=/usr/local/ssl' '--with-curl=/usr/local/lib'
Отличия только в версиях PHP (5.2.1 и 5.2.3) и в версиях MySQL (но это роли не играет, т.к. не про это речь). FreeTDS на обоих серверах 0.63.
Глюк в следующем:
Есть еще MSSQL сервер, к которому коннектятся php-скрипты. Скрипты коннектятся к 127.0.0.1:1433, что на самом деле является редиректом порта на реальный адрес сервера (так надо). Для тестирования берем простейший скрипт:
На первом сервере все без проблем, а на втором php(или апач?) (процесс) рушится с логами (3 строчки на каждую попытку коннекта) в error_log вида:
[notice] child pid NNN1 exit signal Segmentation fault (11)
[notice] child pid NNN2 exit signal Segmentation fault (11)
[notice] child pid NNN3 exit signal Segmentation fault (11)
А в браузер выдает "Ответ нулевой длины", т.к. апач ничего вообще не успевает выдать.
Дело именно в вызове mssql_connect(), т.к. на циске доступ к MSSQL-серверу прописан правильно. С обоих серверов из консоли "telnet 127.0.0.1 1433" работает без проблем, т.е. MSSQL-сервер позволяет обоим веб-серверам коннектиться к себе. Вызовы остальных функций mssql_xxxxxxxxx работают и они выдают стандартные ошибки, т.к. коннекта с сервером нет.
error_reporting(E_ALL) ничего не дает. "mssql_connect(....) or die(........)" не доходит до die() т.к. все сразу рушится при попытке вызова функции.
Все остальное на обоих серверах работает без проблем. Смена конфигурации на тестовом (на PHP/5.2.3) произошла на днях и сегодня обнаружилась эта проблема.
Вопрос:
Кто-нибудь с подобным сталкивался? На каких инет-ресурсах искать какую-нибудь информации (на сайтах где упор на PHP или там где че-нить есть про FreeTDS). Версия FreeTDS одна и та же, на рабочем сервер работа с MSSQL идет без проблем. Может ли связка PHP/5.2.3 + FreeTDS 0.63 не работать, когда PHP/5.2.1 + FreeTDS 0.63 работает на ура? Или дело в чем то другом?
-~{}~ 14.06.07 16:53:
Сделал все как рекомендуют разработчики FreeTDS на http://www.freetds.org/userguide/pagenodata.htm
Затем: Read the backtrace to determine what the cause of the problem is. Examine each line, assigning responsibility by component; some code is PHP, some is FreeTDS, and some may be glibc.
В бэктрейсе все ошибки только с PHP? Получается что баг именно в новой версии 5.2.3? Для анализа как они пишут надо обладать "software engineering debugging skills". У меня не такой уровень знаний, мож кто подтвердит или опровергнет, что баг в PHP?
#0 0x08265f5b in zend_inline_hash_func (arKey=0x40634000 <Address 0x40634000 out of bounds>, KeyLength=1075612464) at zend_hash.h:260
#1 0x0826534f in zend_hash_find (ht=0x846dc40, arKey=0x403fe800 "sybase_127.0.0.1:1433_demo_demo__", nKeyLength=1077928752, pData=0x172db09d) at /root/install/php-5.2.3/Zend/zend_hash.c:870
#2 0x0821cfb1 in php_sybase_do_connect (ht=388870301, return_value=0x403fe7e8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, persistent=0) at /root/install/php-5.2.3/ext/sybase/php_sybase_db.c:495
#3 0x0821dbd4 in zif_sybase_connect (ht=3, return_value=0x403fe7e8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /root/install/php-5.2.3/ext/sybase/php_sybase_db.c:570
#4 0x08274f26 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffcc80) at zend_vm_execute.h:200
#5 0x082747f1 in execute (op_array=0x403fe338) at zend_vm_execute.h:92
#6 0x0825dc69 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/install/php-5.2.3/Zend/zend.c:1134
#7 0x0822b880 in php_execute_script (primary_file=0xbffff000) at /root/install/php-5.2.3/main/main.c:1794
#8 0x082b8476 in main (argc=2, argv=0xbffff094) at /root/install/php-5.2.3/sapi/cli/php_cli.c:1138
#9 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
Небольшое вступление:
Есть два веб-сервера (рабочий и тестовый). Конфигурации практически идентичные, чтобы в случае чего можно было делать экстренную замену рабочего сервера сразу на тестовый. И новые версии ПО сначала ставятся и опробируются на тестовом серваке.
сервер #1:
Apache/1.3.37 (Unix) PHP/5.2.1 mod_ssl/2.8.28 OpenSSL/0.9.7l rus/PL30.22
собран с настройками:
'./configure' '--with-mysql=/root/install/mysql-4.1.21' '--with-mnogosearch=/usr/local/mnogosearch' '--with-mysql' '--with-charset' '--with-sybase=/usr/local/freetds' '--with-zlib' '--enable-gd-native-ttf' '--with-png-dir=../graphlib/libpng-1.0.6' '--with-ttf' '--with-apache=../apache_1.3.37rusPL30.23' '--with-gd' '--with-iconv' '--with-openssl=/usr/local/ssl' '--with-curl=/usr/local/lib'
сервер #2:
Apache/1.3.37 (Unix) PHP/5.2.3 mod_ssl/2.8.28 OpenSSL/0.9.7l rus/PL30.22
собран с настройками:
'./configure' '--with-mysql=/root/install/mysql-5.0.41' '--with-mnogosearch=/usr/local/mnogosearch' '--with-mysql' '--with-charset' '--with-sybase=/usr/local/freetds' '--with-zlib' '--enable-gd-native-ttf' '--with-png-dir=../graphlib/libpng-1.0.6' '--with-ttf' '--with-apache=../apache_1.3.37rusPL30.23' '--with-gd' '--with-iconv' '--with-openssl=/usr/local/ssl' '--with-curl=/usr/local/lib'
Отличия только в версиях PHP (5.2.1 и 5.2.3) и в версиях MySQL (но это роли не играет, т.к. не про это речь). FreeTDS на обоих серверах 0.63.
Глюк в следующем:
Есть еще MSSQL сервер, к которому коннектятся php-скрипты. Скрипты коннектятся к 127.0.0.1:1433, что на самом деле является редиректом порта на реальный адрес сервера (так надо). Для тестирования берем простейший скрипт:
PHP:
<?php
mssql_connect("127.0.0.1:1433", "test", "test");
?>[notice] child pid NNN1 exit signal Segmentation fault (11)
[notice] child pid NNN2 exit signal Segmentation fault (11)
[notice] child pid NNN3 exit signal Segmentation fault (11)
А в браузер выдает "Ответ нулевой длины", т.к. апач ничего вообще не успевает выдать.
Дело именно в вызове mssql_connect(), т.к. на циске доступ к MSSQL-серверу прописан правильно. С обоих серверов из консоли "telnet 127.0.0.1 1433" работает без проблем, т.е. MSSQL-сервер позволяет обоим веб-серверам коннектиться к себе. Вызовы остальных функций mssql_xxxxxxxxx работают и они выдают стандартные ошибки, т.к. коннекта с сервером нет.
error_reporting(E_ALL) ничего не дает. "mssql_connect(....) or die(........)" не доходит до die() т.к. все сразу рушится при попытке вызова функции.
Все остальное на обоих серверах работает без проблем. Смена конфигурации на тестовом (на PHP/5.2.3) произошла на днях и сегодня обнаружилась эта проблема.
Вопрос:
Кто-нибудь с подобным сталкивался? На каких инет-ресурсах искать какую-нибудь информации (на сайтах где упор на PHP или там где че-нить есть про FreeTDS). Версия FreeTDS одна и та же, на рабочем сервер работа с MSSQL идет без проблем. Может ли связка PHP/5.2.3 + FreeTDS 0.63 не работать, когда PHP/5.2.1 + FreeTDS 0.63 работает на ура? Или дело в чем то другом?
-~{}~ 14.06.07 16:53:
Сделал все как рекомендуют разработчики FreeTDS на http://www.freetds.org/userguide/pagenodata.htm
Затем: Read the backtrace to determine what the cause of the problem is. Examine each line, assigning responsibility by component; some code is PHP, some is FreeTDS, and some may be glibc.
В бэктрейсе все ошибки только с PHP? Получается что баг именно в новой версии 5.2.3? Для анализа как они пишут надо обладать "software engineering debugging skills". У меня не такой уровень знаний, мож кто подтвердит или опровергнет, что баг в PHP?
#0 0x08265f5b in zend_inline_hash_func (arKey=0x40634000 <Address 0x40634000 out of bounds>, KeyLength=1075612464) at zend_hash.h:260
#1 0x0826534f in zend_hash_find (ht=0x846dc40, arKey=0x403fe800 "sybase_127.0.0.1:1433_demo_demo__", nKeyLength=1077928752, pData=0x172db09d) at /root/install/php-5.2.3/Zend/zend_hash.c:870
#2 0x0821cfb1 in php_sybase_do_connect (ht=388870301, return_value=0x403fe7e8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, persistent=0) at /root/install/php-5.2.3/ext/sybase/php_sybase_db.c:495
#3 0x0821dbd4 in zif_sybase_connect (ht=3, return_value=0x403fe7e8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /root/install/php-5.2.3/ext/sybase/php_sybase_db.c:570
#4 0x08274f26 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffcc80) at zend_vm_execute.h:200
#5 0x082747f1 in execute (op_array=0x403fe338) at zend_vm_execute.h:92
#6 0x0825dc69 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/install/php-5.2.3/Zend/zend.c:1134
#7 0x0822b880 in php_execute_script (primary_file=0xbffff000) at /root/install/php-5.2.3/main/main.c:1794
#8 0x082b8476 in main (argc=2, argv=0xbffff094) at /root/install/php-5.2.3/sapi/cli/php_cli.c:1138
#9 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6