ID:               21306
 Comment by:       carlos dot mafla at calipso dot com dot co
 Reported By:      Xuefer at 21cn dot com
 Status:           No Feedback
 Bug Type:         Session related
 Operating System: linux
 PHP Version:      4.3.0
 New Comment:

I got that warning too with some php scripts ...( Warning: Unknown(): A
session is active. You cannot change the session module's ini settings
at this time. in Unknown on line 0 ).

The scripts are the same and are placed in two different servers, one
with php 4.3.1 and apache 1.3 and the other one with php 4.3.3 and
apache 2, the first one works  fine without any problem but when i put
it in the second one i got that warning ... so i know its not an script
warning, but i dont know how to fix it... please help because we are
now upgrading other servers to apache 2 and php 4.3.3..

thanx

carlos mafla
from colombia


Previous Comments:
------------------------------------------------------------------------

[2003-05-28 02:02:24] eric dot ritchie at dorten dot com

I think I may be able to cast some light on this particular problem.
First the important info:

OS: Suse Linux 8.1 / Suse Linux 7.0 / Windows 2000
PHP: 4.3.1 / 4.3.0 / 4.3.1 & 4.3.2PL4
Apache: 1.3.27+ssl1.48 / same / 1.3.26

PHP is compiled into Apache on the Linux machines and inserted as a
module under Windows.

The application, that am developing for my company, is a large project
with user management, sessions, SSL admin and non SSL user sections
etc. I first started to get this problem frequently after making one
particular change to the application. Since one user should only have
one connection to the application, I checked the session table (in a
MySQL database) and deleted all previous sessions that contained the
same user ID.

The problem came when someone was still using the session that was
deleted. Depending apon what that user was doing at the time of the
deletion, the application would either take them back to the login
screen and report the session had expired (what I intended) or crash
within the PEAR:throwError() method in the PEAR.php library. Checking
with debug_backtrace() I could see that a constant
(DB_FETCHMODE_ASSOC), passed to  one of the preceeding function calls,
was being corrupted during the call.

I thought that there was something screwed up with the MySQL session
handling code (in our application), so I switched back to using file
based sessions and found the same problem to exist. After some time I
found the following solution (see the comment for details):


function read($id) {
  $hackStr =
"selectedParts|a:0:{}selectedCars|a:0:{}selectedCountries|a:0:{}cartHead|a:0:{}sessionUser|a:0:{}sessionCustomer|a:0:{}";
  $db = &$GLOBALS['db'];
  $db->setFetchMode(DB_FETCHMODE_ASSOC);
    
  $q = "SELECT * FROM ourSession WHERE id = '".$id."'";
  $res = $db->query($q);
  if (PEAR::isError($res) || !($row = $res->fetchRow())) {
    // WARNING returning '' seems to crash PHP. Therefore, 
    // I return a empty session instead.    
    return $hackStr;
  }
  return base64_decode($row['data']);
} // read()


Which is of course called via session_set_save_handler(). I noted the
same problem with file session handling. If the contents of the file
are emptied (or the file is deleted) then the application crashed.
However, if I overwrote the file with a dummy session string, then all
worked well.

I am guessing that the version 4.3.x of PHP have a problem initialising
sessions and can cause buffer overflows under certain conditions.

I hope you all find this useful!
Eric Ritchie
Dorten GmbH.

------------------------------------------------------------------------

[2003-05-25 21:53:44] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

..and this is not likely anything wrong in PHP, some broken HTML can
make your script getting run twice too.


------------------------------------------------------------------------

[2003-05-20 13:13:43] xuefer at 21cn dot com

sorry, i meant chance, not change

------------------------------------------------------------------------

[2003-05-20 13:11:56] xuefer at 21cn dot com

sorry, i don't have change to test it yet
so will soletan confirm the snapshot
thx

------------------------------------------------------------------------

[2003-05-20 10:03:32] [EMAIL PROTECTED]

Code being executed twice really sounds like a problem in the scripting
engine to me. It could be caused or triggered by defects in the tool
chain (buggy compiler optimizer, broken bison/flex).

Please retest with current Stable snapshot from snaps.php.net.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/21306

-- 
Edit this bug report at http://bugs.php.net/?id=21306&edit=1

Reply via email to