ID: 21306
Comment by: soletan at toxa dot de
Reported By: Xuefer at 21cn dot com
Status: Open
Bug Type: Session related
Operating System: linux
PHP Version: 4.3.0
New Comment:
I tried to compile some information on that bug, that probably helps to
understand my problems. Because this report system lacks of a support
for attachments (which is quite reasonable to me, of course). But I
guess you won't read >3MB text files unzipped or 86 KB archived, but
binary here ... I send the compilation to anyone who likes to get.
Several php-scripts, some modifications to php-source I made, two quite
large but still „simple“ syslog-excerpts, a copy of output are included
with that compilation. The scripts are excerpts only, because a full
backup of my scripts’ source tree would take 190 KB gzipped. If you
need more information (sources) to reproduce the malfunction, send me a
mail, but I hope this is enough and maybe you don’t need that much
additional information.
Some first idea of what’s wrong: In my case this bug doesn’t
immediately belong to sessions. It’s probably some scripting failure or
a malfunction of how several parts of PHP-core and ext’s – zend
scripting engine and altered session handler – work together. It looks
like some overflow, like something’s trashing PHP’s heap. As a
consequence, or in conjunction with that, PHP doesn’t end and gets
dropped by maximum-execution-time observer, which then ignores any
session save procedures and cleans up everything. During this the
session still gets informed about restoring the ini-environment and
produces the posted error message.
Here is what I did:
The bug appeared again and I couldn't find any place in my scripts
missed to include some session_write_close() + exit() – this in
consequence to my last comment!
One of my scripts is a layouter (lib/layout.php), implemented as a
class. I feed it with information about the body content, menu
structure and else. It stores all these in a structured array. Finally
I call a method named "draw()", that searches for available plugins
depending on the client's browser-caps and uses one of these to produce
a string, which draw() returns itself to its caller afterwards. That
caller finally echo's the string right before the closing tag and the
end of major script file – I used src/start.php for testing.
Each trial to break the execution before calling that draw method was
successful, tested with included snippet "echo 'test'; exit( 0 );" ...
Now comes some interesting point:
Placing the same at the first line inside the draw-method, I get "test"
twice without delay. One exit gets ignored, then scripting gets into
draw() a second time and this time the exit seems to be computed, too.
This double call might become visible by the second logfile-excerpt,
message-foo ...
Removing any additional echo’s and exit’s, the script runs for maximum
execution time and then produces the output, Xuefer posted – at
modification notifier in ext/session/session.c:OnUpdateSaveHandler.
I included some debugging support by calling syslog in zend/zend_ini.c
and in session/session.c of PHP's source tree at several points of
code. Watching my syslog-file I detected, that my installed
session-class didn’t get called for writing and closing, but zend
engine shuts down script execution.
Well, after detecting one of my variables having values at second run,
I've never assigned myself anywhere, I used this to detect the second
call and return immediately from method draw() after flushing session
with a pair of "session_write_close(); @session_start();". Now there's
no execution delay, no strange error message, nothing but a f**king
workaround hack.
Best Regards
Thomas Urban
Previous Comments:
------------------------------------------------------------------------
[2003-03-06 11:35:25] soletan at toxa dot de
Damn, I got rid of that message Xuefer initially posted. All I had done
was calling exit() before session could write back its data.
Then I included session_write_close() before some exit. It's not that
exit inside some session_set_save_handler-calling function. It's any
exit at any place, I expect.
Isn't it possible, to include this needed call to session_write_close()
automatically in sources of exit() to avoid all that trouble I have
been handling with for the last 24 hours??? It would be more
convenient, doesn't it?
BTW: I have PHP 4.3.1 as DSO to Apache 2.0.43 under SuSE Linux 7.1. The
first two are both self-compiled from source.
Best Regards,
Thomas Urban
------------------------------------------------------------------------
[2003-02-07 17:15:20] rob at nospamplease dot com
This appears (in our case anyway) to be triggered by the use of an
"exit" statement in the session_set_save_handler session_write
function. We had a benign error in our custom session_write function
(caused by the session data not changing when it was writing out)..
this caused an error message to be written to a log file, and then the
"exit;" statement. In PHP 4.2, this exit apparently caused no problems
but now it generates this seemingly unrelated error message.
Incidently, because this message is generated at the time of
session_write (rather than during actual content generation) it also
caused an interaction with ob_gzhandler (gzip compression) such that
blank pages were being served up.. we had to disable ob_gzhandler to
even see the "A session is active..." messages.. This seems buggy to
me.
------------------------------------------------------------------------
[2003-01-27 20:12:46] steve-php-dev at spamaphobia dot com
I upgraded to 4.3.0 from 4.2.3 a couple weeks ago. I did not see this
problem at all until today, when I uploaded two minor changes to my web
site. We get several hundred thousand page views per day, and since
this upload we're getting 3-4 of this error per minute. So for most
page views it doesn't happen, but it's definitely happening frequently
and regularly.
The first change was to our error handler. We specifically trigger
errors using $php_errormsg if it exists (after the session is started),
so that we can catch stupid users who try to upload humongous images to
our site (we limit them to 40KB). Some bright young individual
uploaded a 476MB file ten times this morning, so we added some code
(three lines) to log the date, time, username, and file size. Here is
the code we added:
$fp = fopen("/tmp/big_images.log", 'a');
fwrite($fp, sprintf("%s: %s (%s KB)\n", date("Y-m-d H:i:s"),
$_SESSION['auth']->auth['username'], $kb));
fclose($fp);
While typing this, I made a change which seems to have fixed the
problem. I have a function called session_setup() which makes sure the
session id is unique, and call session_set_save_handler() or whatever
the name of that function is. The trigger_error mentioned above used
to be called after calling session_setup() in my authentication include
file. I moved it to inside the session_setup() function, after setting
the save_handler. For some reason, this fixed the problem.
Odd.
Perhaps this can help someone else somehow?
------------------------------------------------------------------------
[2003-01-05 16:03:24] vi at sh dot nu
Have a working installation of os-commerce in 4.2.3. Upgraded to 4.3.0,
and now I get the same error listed here.
All I want to do is confirm that this is NOT a script error. I'm not
going to dig through some code I didn't write to track this down.
Thanks
------------------------------------------------------------------------
[2003-01-01 10:11:39] Xuefer at 21cn dot com
note that, i don't even use one ini_set()
and the script is impossible to session_set_save_handler() twice;
seems php don't re-initize correctly, same as
http://bugs.php.net/bug.php?id=19292
but i'm just guessing
------------------------------------------------------------------------
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
