PHP :: Bug #40747 :: Reproducible Crash
- ️Wed Mar 07 2007
| 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 |
[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-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.