|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #31464 session_start() function blocking the script
Submitted: 2005-01-10 04:39 UTC Modified: 2005-01-10 09:59 UTC
From: wildmaple at yahoo dot com Assigned:
Status: Not a bug Package: Session related
PHP Version: 5.0.3 OS: Linux
Private report: No CVE-ID: None
 [2005-01-10 04:39 UTC] wildmaple at yahoo dot com
i don't be sure if this is a bug, anyway i don't think it is logically acceptable.

*  A short script that reproduces the problem.
we developed a service structure, using webservice tech(php5.soap). most things went well as we'd expected till we decided to make one service script access another one. we have 3 seperate sites under construction in the same linux box, and maybe more sites coming. some services on one site will contact another on a second site, and we think this schema is easy to understand and develope.

scriptA.php makes an SoapClient->__call() to scriptB.php , which serves well using SoapServer class when called from an binary client programmed with c++. then scriptB.php blocked when it got to the line where session_start() resides.

when we commented out session_start(), scriptB.php worked out as fast as possible, but we lost support of session tech here, that is not acceptable as we designed.

btw, we tried other ways to solve this problem, but all failed at function session_start(). some of the methods are xml-rpc and fsocket(writing and recieving soap envelope handly or xml-rpc structures),pear-xml-rpc(pear's xml-rpc lib).

* The list of modules you compiled PHP with (your configure line).
 	 './configure' '--prefix=/usr/local/php' '--with-config-file-path=/usr/local/php' '--enable-sockets' '--with-apxs2=/usr/local/apache/bin/apxs' '--with-mysql=/usr/local/mysql' '--enable-track-vars' '--enable-static' '--enable-roxen-zts' '--with-gd' '--with-zlib' '--with-xml' '--with-gettext' '--with-ttf' '--enable-gd-native-ttf' '--enable-gd-imgstrttf' '--with-freetype-dir=/usr/local/freetype' '--with-iconv=/usr/local/iconv' '--enable-force-cgi-redirect' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-dom' '--with-ncurses' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--with-soap=shhared' '--enable-soap' '--with-xmlrpc'

* Any other information unique or specific to your setup.
nothing special.

 * Any changes made in your php.ini compared to php.ini-dist (not your whole php.ini!)

* A gdb backtrace.

Reproduce code:


$ServObj = new SoapServer("",array('encoding'=>'GB2312'));

Expected result:
script workout to put some message when called by another script on the same machine using soap method.

Actual result:
blocked at the line where session_start() locates.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-01-10 08:13 UTC]
This is indeed not a bug at all, the session extension needs to lock the session file so that concurrent updates can not corrupt the file. This means that all scripts using the same session file needs to be serialized. To improve performance you can use as soon as you are done reading/setting session variables, which will remove the lock of the file.
 [2005-01-10 09:59 UTC] wildmaple at yahoo dot com
Thanx alot!
you show me the bright way out, it is the session file's lock blocked the script, and session_write_close() solves it appropriately.

but, may i point out another phenomenon, which puzzled me a great.

before we received your message about this bogus bug, we made another test, a monitor program(something that transports and inspects data flowing between processes in network environment, running on a third machine) interfered scriptA.php (SoapClient::__call()) and scriptB.php (SoapServer::handle()), and without commenting out session_start() or adding session_write_close(), scriptA.php and scriptB.php both worked out exactly as we expected.

can you give some explain about this? i am alittle confused, why php blocks scripts using the same session files as the previous, but does not block them when they ware executed by through monitor by the same previous script.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Wed Aug 10 23:05:51 2022 UTC