PHP :: Bug #40747 :: Reproducible Crash

Bug #40747	Reproducible Crash
Submitted:	2007-03-07 10:12 UTC	Modified:	2007-03-09 10:29 UTC
From:	th at domainbox dot de	Assigned:
Status:	Closed	Package:	Reproducible crash
PHP Version:	4.4.6	OS:	Debian Sarge
Private report:	No	CVE-ID:	None

View Developer Edit

[2007-03-07 10:12 UTC] th at domainbox dot de

Description:
------------
We are experiencing a repoducible crash of an xt:Commerce installation
since the server was upgraded from PHP 4.4.4 to PHP 4.4.5. This was neither resolved by upgrading to 4.4.6 nor by upgrading to snapshot php4-STABLE-200703070730

Reproduce code:
---------------
The failing Code seems to be in xt:Commerce's sessions.php, i'm not able to detect this any further at the moment. The Version is 

$Id: sessions.php,v 1.1 2003/09/06 22:13:54 fanta2k Exp $

Actual result:
--------------
(gdb) bt
#0  0xb7ae907b in _efree (ptr=0x0, __zend_filename=0xb7b29a20 "/opt/confixx-pakete/php4-STABLE-200703070730/ext/session/mod_files.c", 
    __zend_lineno=283, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /opt/confixx-pakete/php4-STABLE-200703070730/Zend/zend_alloc.c:256
#1  0xb7a1c71c in ps_close_files (mod_data=0xb7ba2e90) at /opt/confixx-pakete/php4-STABLE-200703070730/ext/session/mod_files.c:283
#2  0xb7a1b8f5 in php_rshutdown_session_globals () at /opt/confixx-pakete/php4-STABLE-200703070730/ext/session/session.c:1686
#3  0xb7a1baa1 in zm_deactivate_session (type=1, module_number=6) at /opt/confixx-pakete/php4-STABLE-200703070730/ext/session/session.c:1742
#4  0xb7afe9af in module_registry_cleanup (module=0x928ea90) at /opt/confixx-pakete/php4-STABLE-200703070730/Zend/zend_API.c:1168
#5  0xb7b0194c in zend_hash_apply (ht=0xb7ba7280, apply_func=0xb7afe96c <module_registry_cleanup>)
    at /opt/confixx-pakete/php4-STABLE-200703070730/Zend/zend_hash.c:708
#6  0xb7afad75 in zend_deactivate_modules () at /opt/confixx-pakete/php4-STABLE-200703070730/Zend/zend.c:674
#7  0xb7ac2f4a in php_request_shutdown (dummy=0x0) at /opt/confixx-pakete/php4-STABLE-200703070730/main/main.c:989
#8  0xb7b15124 in apache_php_module_main (r=0x812f194, display_source_mode=0)
    at /opt/confixx-pakete/php4-STABLE-200703070730/sapi/apache/sapi_apache.c:60
#9  0xb7b15e57 in send_php (r=0x812f194, display_source_mode=0, filename=0x8130d34 "/var/www/web46/html/shop/index.php")
    at /opt/confixx-pakete/php4-STABLE-200703070730/sapi/apache/mod_php4.c:626
#10 0xb7b15ecd in send_parsed_php (r=0x812f194) at /opt/confixx-pakete/php4-STABLE-200703070730/sapi/apache/mod_php4.c:641
#11 0x08054ece in ap_invoke_handler ()
#12 0x0806b8de in process_request_internal ()
#13 0x0806b93b in ap_process_request ()
#14 0x08062177 in child_main ()
#15 0x08062426 in make_child ()
#16 0x08062794 in perform_idle_server_maintenance ()
#17 0x08062e35 in standalone_main ()
#18 0x080634aa in main ()
(gdb) frame 1
#1  0xb7a1c71c in ps_close_files (mod_data=0xb7ba2e90) at /opt/confixx-pakete/php4-STABLE-200703070730/ext/session/mod_files.c:283
283             efree(data->basedir);
(gdb) frame 2
#2  0xb7a1b8f5 in php_rshutdown_session_globals () at /opt/confixx-pakete/php4-STABLE-200703070730/ext/session/session.c:1686
1686                            PS(mod)->s_close(&PS(mod_data) TSRMLS_CC);
(gdb) frame 3
#3  0xb7a1baa1 in zm_deactivate_session (type=1, module_number=6) at /opt/confixx-pakete/php4-STABLE-200703070730/ext/session/session.c:1742
1742            php_rshutdown_session_globals(TSRMLS_C);
(gdb) frame 4
#4  0xb7afe9af in module_registry_cleanup (module=0x928ea90) at /opt/confixx-pakete/php4-STABLE-200703070730/Zend/zend_API.c:1168
1168                                    module->request_shutdown_func(module->type, module->module_number TSRMLS_CC);
(gdb)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2007-03-07 10:15 UTC] derick@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

[2007-03-07 14:22 UTC] th at domainbox dot de

The problem seems to be that xt::Commerce's configuration variable SESSION_WRITE_DIRECTORY is set to an emtpy value.
The problem can be reduced to this code snippet:

<?
  session_save_path("");
  session_start(); 
?>

[2007-03-07 14:45 UTC] tony2001@php.net

This code snippet works perfectly fine.

[2007-03-08 06:53 UTC] th at domainbox dot de

I retried this on a different System, same behavior in 4.4.6 and php4-STABLE-200703070730. This is my compile Script:

#!/bin/sh
echo "##############################################################"
echo "#### PHP"
echo "##############################################################"


tar xvzf php4-STABLE-200703070730.tar.gz
cd php4-STABLE-200703070730
echo "###### Running configure on php"
./configure \
--prefix=/usr \
--with-gd \
--with-ttf \
--with-freetype \
--with-freetype-dir=/usr \
--with-imap \
--with-iconv \
--with-jpeg-dir=/usr \
--with-png-dir=/usr \
--with-mcrypt=/usr \
--with-zlib \
--with-mysql \
--with-gettext \
--with-config-file-path=/etc/httpd \
--with-ldap-dir=/usr \
--enable-filepro \
--enable-dba \
--enable-ctype \
--enable-wddx \
--enable-exif \
--enable-bcmath \
--enable-track-vars \
--enable-sockets \
--enable-trans-sid \
--enable-dbase \
--no-recursion \
--with-apxs
echo "###### Running make on php"
make
make install

Calling session_save_path with any value gives the expected behavior like: Warning: session_start() [function.session-start]: open(bla/sess_e5d8178fe831d9fa1f29f188c397123c, O_RDWR) failed: No such file or directory (2)

[2007-03-08 12:24 UTC] th at domainbox dot de

I could solve this problem changeing mod_files.c. Note that i'm not a programmer ;)

--- php4-STABLE-200703070730/ext/session/mod_files.c    2007-01-05 02:33:20.000000000 +0100
+++ php4-STABLE-200703070730-dbx/ext/session/mod_files.c        2007-03-08 13:09:48.000000000 +0100
@@ -280,8 +280,10 @@
 
        if (data->lastkey) 
                efree(data->lastkey);
-       efree(data->basedir);
-       efree(data);
+       if (data->basedir)
+               efree(data->basedir);
+       if (data)
+               efree(data);
        *mod_data = NULL;
 
        return SUCCESS;

This returns my php installation to the expected behavior:

Warning: session_start() [function.session-start]: open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (/home/user) in /home/user/html/test.php on line 3

[2007-03-09 10:29 UTC] tony2001@php.net

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2024 The PHP Group All rights reserved.	Last updated: Tue Dec 03 17:01:29 2024 UTC