#49098 [NEW]: Using custom session handler causes segfault in session_save_state

2009-07-29 Thread bugs at timj dot co dot uk
From: bugs at timj dot co dot uk
Operating system: Linux
PHP version:  5.2.10
PHP Bug Type: Reproducible crash
Bug description:  Using custom session handler causes segfault in 
session_save_state

Description:

I am seeing segfaults on various pages that don't occur on 5.2.9 (and the
same site has been working on many previous versions of 5.1/5.2). I have a
session handler using PEAR HTTP_Session2, that saves via MDB2/mysqli to a
MySQL database. The segfaults seem to happen during session_save_state.

Unfortunately I don't currently have a trivial reproduction scenario, but
it does reliably cause a segfault in both 5.2.10 and
5.2SVN-snap200907182030.

I am not a C developer but after a diligent attempt to search the
bugtracker and investigate the bug, I concluded that it was probably
duplicate of bug #48922 and tried to add additional information to that
bug, explaining my reasoning, to avoid filing a duplicate (in accordance
with http://bugs.php.net/report.php). However, Jani disagrees (see comments
in other bug), so I'm filing a new bug.

Actual result:
--
Here's 5.2.10: (crash in version_compare):

Program received signal SIGSEGV, Segmentation fault.
0x71ea4d3f in _zend_mm_free_int (heap=0x78396480,
p=0x78bb7010) at /usr/src/debug/php-5.2.10/Zend/zend_alloc.c:1978
1978if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) bt
#0  0x71ea4d3f in _zend_mm_free_int (heap=0x78396480,
p=0x78bb7010) at /usr/src/debug/php-5.2.10/Zend/zend_alloc.c:1978
#1  0x71ea5af4 in _efree (ptr=0x78bb7010) at
/usr/src/debug/php-5.2.10/Zend/zend_alloc.c:2311
#2  0x71e3f4ff in php_version_compare (orig_ver1=0x787b7538
"5.2.10", orig_ver2=0x78e41ac0 "5.0") at
/usr/src/debug/php-5.2.10/ext/standard/versioning.c:202
#3  0x71e3f58b in zif_version_compare (ht=3,
return_value=0x787bc458, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1) at
/usr/src/debug/php-5.2.10/ext/standard/versioning.c:222
#4  0x71ef028d in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffac00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:200
#5  0x71ef4235 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x7fffac00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:1739
#6  0x71eefd6f in execute (op_array=0x78a028c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#7  0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffba00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#8  0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffba00) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#9  0x71eefd6f in execute (op_array=0x78b696e8) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#10 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffbf60) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#11 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffbf60) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#12 0x71eefd6f in execute (op_array=0x78b69588) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#13 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffc2d0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#14 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffc2d0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#15 0x71eefd6f in execute (op_array=0x78b6a728) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#16 0x71ef043e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fffd1c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:234
#17 0x71ef0984 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffd1c0) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:322
#18 0x71eefd6f in execute (op_array=0x78e29300) at
/usr/src/debug/php-5.2.10/Zend/zend_vm_execute.h:92
#19 0x71eb816b in zend_call_function (fci=0x7fffd440,
fci_cache=0x0) at
/usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:1032
#20 0x71eb66d4 in call_user_function_ex
(function_table=0x78396d20, object_pp=0x0,
function_name=0x78e3eea0, retval_ptr_ptr=0x7fffd4e8,
param_count=2, params=0x787b7670, no_separation=1, 
symbol_table=0x0) at
/usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:640
#21 0x71eb65af in call_user_function
(function_table=0x78396d20, object_pp=0x0,
function_name=0x78e3eea0, retval_ptr=0x787b7c18, param_count=2,
params=0x7fffd590)
at /usr/src/debug/php-5.2.10/Zend/zend_execute_API.c:613
#22 0x71da4785 in ps_call_handler (func=0x78e3eea0, argc=2,
argv=0x7fffd590) at
/usr/src/debug/php-5.2.10/ext/session/mod_user.c:53
#23 0x71da4c2d in ps_write_user (mod

#45956 [NEW]: Design problem: parse_ini_file lacks ability to handle errors gracefully

2008-08-30 Thread bugs at timj dot co dot uk
From: bugs at timj dot co dot uk
Operating system: irrelevant
PHP version:  5.2.6
PHP Bug Type: Filesystem function related
Bug description:  Design problem: parse_ini_file lacks ability to handle errors 
gracefully

Description:

This seems to be a design error rather than a bug: parse_ini_file() does
not provide any way to handle errors gracefully. In the event of a syntax
error, it throws an E_WARNING *but* the return value is simply an empty
array (the same as a - valid - empty file) instead of FALSE. Thus there is
no way to trap the error (via @ prefix) and handle it in a more graceful
way than an E_WARNING.

I would argue that changing the return value to FALSE in the case of an
invalid file is a reasonable change, since the only situations it will
break are ones where currently PHP throws a warning anyway.


Reproduce code:
---
This is what it would be nice to be able to do:

$ini = @parse_ini_file('some_invalid.ini');
if ($ini === false) {
   // error: do something graceful
}
// normal execution

Expected result:

The code section "// do something graceful" executes

Actual result:
--
The code section "// normal execution" executes

-- 
Edit bug report at http://bugs.php.net/?id=45956&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=45956&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=45956&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=45956&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45956&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=45956&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=45956&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45956&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45956&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=45956&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45956&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=45956&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=45956&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45956&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=45956&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45956&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45956&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=45956&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=45956&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=45956&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45956&r=mysqlcfg