#48745 [NEW]: Segmentation fault in MySQL extension with mysqlnd
From: theta...@php.net
Operating system: Solaris 10 x86
PHP version: 5.3.0
PHP Bug Type: MySQL related
Bug description: Segmentation fault in MySQL extension with mysqlnd
Description:
Installed PHP 5.3 today on our Solaris server running with NSAPI as SAPI
module (which is not the problem here). Our test environment with some
applications like MediaWiki and our own PHP scripts worked as exspected.
We are using the new mysqlnd, because under solaris 10 with Blastwave
mysql libs you have problems with compiling (libs are 32/64 bit dual,
mysql_config only return 64 bit params, php should be compiled as 32bit,
see my php_dev mail after RC4). Mysqlnd works super, mediawiki runs much
faster than before.
With one application, which was not tested before, we have a problem. The
content managment system Contenido 4.8.12 (www.condenido.org) works in the
frontend without problem, so the website is running, but the backend
crashes PHP with an SIGSEGV. The stacktrace is attached.
Contenido uses the old mysql extension (which also uses mysqlnd).
Reproduce code:
---
I do not exectly know at which portion of contenido's code it crashes. It
seems that Z_STRLEN_P(return_value) = strlen(mysql_field->table) produces a
sigsegv (mysql_field->table == NULL):
Expected result:
It should not crash the webserver process.
Actual result:
--
Program terminated with signal 11, Segmentation fault.
#0 0xfc3925e2 in php_mysql_field_info (ht=0, return_value=0xa5b157c,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1,
tsrm_ls=0xa61f228, entry_type=2) at
/pangaea/install/php-5.3.0/ext/mysql/php_mysql.c:2410
2410Z_STRLEN_P(return_value) =
strlen(mysql_field->table);
(gdb) where
#0 0xfc3925e2 in php_mysql_field_info (ht=0, return_value=0xa5b157c,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1,
tsrm_ls=0xa61f228, entry_type=2) at
/pangaea/install/php-5.3.0/ext/mysql/php_mysql.c:2410
#1 0xfc56ce5d in zend_do_fcall_common_helper_SPEC
(execute_data=0xa406f20, tsrm_ls=0xa1315e0)
at /pangaea/install/php-5.3.0/Zend/zend_vm_execute.h:313
#2 0xfc56bce2 in execute (op_array=0xa511654, tsrm_ls=0xa1315e0) at
/pangaea/install/php-5.3.0/Zend/zend_vm_execute.h:104
#3 0xfc54a103 in zend_execute_scripts (type=8, tsrm_ls=0xa1315e0,
retval=0x0, file_count=3)
at /pangaea/install/php-5.3.0/Zend/zend.c:1188
#4 0xfc4f5562 in php_execute_script (primary_file=0xebbe7cb8,
tsrm_ls=0xa1315e0) at /pangaea/install/php-5.3.0/main/main.c:2196
#5 0xfc5d5916 in php5_execute (pb=0x82efe08, sn=0x9b9939c, rq=0x9b99414)
at /pangaea/install/php-5.3.0/sapi/nsapi/nsapi.c:1040
#6 0xfecfb147 in func_exec_str () from
/pangaea/webserver70/lib/libns-httpd40.so
#7 0xfecfbd2a in INTfunc_exec_directive () from
/pangaea/webserver70/lib/libns-httpd40.so
#8 0xfed009d6 in INTservact_service () from
/pangaea/webserver70/lib/libns-httpd40.so
#9 0xfed01a39 in INTservact_handle_processed () from
/pangaea/webserver70/lib/libns-httpd40.so
#10 0xfed5e358 in __1cLHttpRequestUUnacceleratedRespond6M_v_ () from
/pangaea/webserver70/lib/libns-httpd40.so
#11 0xfed5d5ba in __1cLHttpRequestNHandleRequest6MpnGnetbuf_I_i_ () from
/pangaea/webserver70/lib/libns-httpd40.so
#12 0xfed5be90 in __1cNDaemonSessionDrun6M_v_ () from
/pangaea/webserver70/lib/libns-httpd40.so
#13 0xfeb861fc in ThreadMain () from
/pangaea/webserver70/lib/libnsprwrap.so
#14 0xfe0bb6c9 in _pt_root () from /pangaea/webserver70/lib/libnspr4.so
#15 0xfd37fd36 in _thr_setup () from /lib/libc.so.1
#16 0xfd380020 in L3_doit () from /lib/libc.so.1
#17 0xfb2d0400 in ?? ()
#18 0x in ?? ()
(gdb) print *mysql_field
$2 = {name = 0x0, org_name = 0x0, table = 0x0, org_table = 0x0, db = 0x0,
catalog = 0x0, def = 0x0, length = 0, max_length = 0,
name_length = 0, org_name_length = 0, table_length = 0, org_table_length
= 0, db_length = 0, catalog_length = 0, def_length = 0,
flags = 0, decimals = 0, charsetnr = 0, type = MYSQL_TYPE_DECIMAL, root
= 0x0, root_len = 0}
--
Edit bug report at http://bugs.php.net/?id=48745&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48745&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48745&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48745&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48745&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48745&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48745&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48745&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48745&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48745&r=oldversion
Not developer issue:
#48752 [NEW]: SIGSEGV during date parsing with new timelib
From: theta...@php.net
Operating system: Solaris 10 x86
PHP version: 5.3.0
PHP Bug Type: Date/time related
Bug description: SIGSEGV during date parsing with new timelib
Description:
I found a second problem with our PHP installation. Sometimes, not
everytime, the server crashes with sigsegv when parsing date/times. I
cannot reproduce the crash, I only can post the code that most times crash.
Reproduce code:
---
This code crashes not always, but often. The $mindate initially contains
as noted in the core dump: 1998-01-01
This is enetered by a user any may look different. The code is used to
fomat any input from the users to an ATOM timestamp.
$mindate=new DateTime($mindate,new DateTimeZone('UTC'));
$search->dateTimeCoverage->min=$mindate->format(DateTime::ATOM);
Expected result:
The server should not crash.
Actual result:
--
Core was generated by `webservd -d
/pangaea/webserver70/https-panwebserver/config -r /pangaea/webserve'.
Program terminated with signal 11, Segmentation fault.
#0 0xfc2b5a44 in timelib_error_container_dtor (errors=0x6d) at
/pangaea/install/php-5.3.0/ext/date/lib/timelib.c:153
153 for (i = 0; i < errors->warning_count; i++) {
(gdb) where
#0 0xfc2b5a44 in timelib_error_container_dtor (errors=0x6d) at
/pangaea/install/php-5.3.0/ext/date/lib/timelib.c:153
#1 0xfc29636d in date_initialize (dateobj=0xa963cd0, time_str=0xa9620a0
"1998-01-01", time_str_len=179481560,
format=0xfca4e4e8 "\v", timezone_object=0xa963bb8, ctor=1,
tsrm_ls=0xaa57068)
at /pangaea/install/php-5.3.0/ext/date/php_date.c:2339
#2 0xfc296728 in zim_DateTime___construct (ht=2, return_value=0xa963d28,
return_value_ptr=0x0, this_ptr=0xa963b6c,
return_value_used=0, tsrm_ls=0xaa57068) at
/pangaea/install/php-5.3.0/ext/date/php_date.c:2479
#3 0xfc56ce5d in zend_do_fcall_common_helper_SPEC
(execute_data=0xa9694a0, tsrm_ls=0xaa57068)
at /pangaea/install/php-5.3.0/Zend/zend_vm_execute.h:313
#4 0xfc56bce2 in execute (op_array=0xa950570, tsrm_ls=0xaa57068) at
/pangaea/install/php-5.3.0/Zend/zend_vm_execute.h:104
#5 0xfc54a103 in zend_execute_scripts (type=8, tsrm_ls=0xaa57068,
retval=0x0, file_count=3)
at /pangaea/install/php-5.3.0/Zend/zend.c:1188
#6 0xfc4f5562 in php_execute_script (primary_file=0xeabe7cb8,
tsrm_ls=0xaa57068) at /pangaea/install/php-5.3.0/main/main.c:2196
#7 0xfc5d5916 in php5_execute (pb=0xa818228, sn=0x9e761dc, rq=0x9e76254)
at /pangaea/install/php-5.3.0/sapi/nsapi/nsapi.c:1040
#8 0xfecfb147 in func_exec_str () from
/pangaea/webserver70/lib/libns-httpd40.so
#9 0xfecfbd2a in INTfunc_exec_directive () from
/pangaea/webserver70/lib/libns-httpd40.so
#10 0xfed009d6 in INTservact_service () from
/pangaea/webserver70/lib/libns-httpd40.so
#11 0xfed01a39 in INTservact_handle_processed () from
/pangaea/webserver70/lib/libns-httpd40.so
#12 0xfed5e358 in __1cLHttpRequestUUnacceleratedRespond6M_v_ () from
/pangaea/webserver70/lib/libns-httpd40.so
#13 0xfed5d5ba in __1cLHttpRequestNHandleRequest6MpnGnetbuf_I_i_ () from
/pangaea/webserver70/lib/libns-httpd40.so
#14 0xfed5be90 in __1cNDaemonSessionDrun6M_v_ () from
/pangaea/webserver70/lib/libns-httpd40.so
#15 0xfeb861fc in ThreadMain () from
/pangaea/webserver70/lib/libnsprwrap.so
#16 0xfe0bb6c9 in _pt_root () from /pangaea/webserver70/lib/libnspr4.so
#17 0xfd37fd36 in _thr_setup () from /lib/libc.so.1
#18 0xfd380020 in L3_doit () from /lib/libc.so.1
#19 0xfb321400 in ?? ()
#20 0x in ?? ()
--
Edit bug report at http://bugs.php.net/?id=48752&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48752&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48752&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48752&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48752&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48752&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48752&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48752&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48752&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48752&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48752&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48752&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48752&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48752&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48752&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php
[PHP-BUG] Req #55403 [NEW]: $_SERVER['HTTPS'] should be undefined on unsecure connection
From: Operating system: PHP version: Irrelevant Package: iPlanet related Bug Type: Feature/Change Request Bug description:$_SERVER['HTTPS'] should be undefined on unsecure connection Description: All other SAPIs (Apache, too, of course) only set the $_SERVER['HTTPS'] variable to "ON", if a secure connection is availab.e The key is undefined otherwise. NSAPI on the other hand defines $_SERVER['HTTPS']='OFF' in this case. This breaks apps that just do an isset() test (Drupal,...). -- Edit bug report at https://bugs.php.net/bug.php?id=55403&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55403&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55403&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55403&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55403&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55403&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55403&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55403&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55403&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55403&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55403&r=support Expected behavior: https://bugs.php.net/fix.php?id=55403&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55403&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55403&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55403&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55403&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55403&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55403&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55403&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55403&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55403&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55403&r=mysqlcfg
Req #55403 [PATCH]: $_SERVER['HTTPS'] should be undefined on unsecure connection
Edit report at https://bugs.php.net/bug.php?id=55403&edit=1 ID: 55403 Patch added by: theta...@php.net Reported by:theta...@php.net Summary:$_SERVER['HTTPS'] should be undefined on unsecure connection Status: Open Type: Feature/Change Request Package:iPlanet related PHP Version:Irrelevant Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: PatchForTrunk.patch Revision: 1313083309 URL: https://bugs.php.net/patch-display.php?bug=55403&patch=PatchForTrunk.patch&revision=1313083309 Previous Comments: [2011-08-11 17:19:25] theta...@php.net Description: All other SAPIs (Apache, too, of course) only set the $_SERVER['HTTPS'] variable to "ON", if a secure connection is availab.e The key is undefined otherwise. NSAPI on the other hand defines $_SERVER['HTTPS']='OFF' in this case. This breaks apps that just do an isset() test (Drupal,...). -- Edit this bug report at https://bugs.php.net/bug.php?id=55403&edit=1
