Bug #52109 [Bgs]: session_start / session_write_close memory leak

From: Date: Sat, 03 Jul 2010 10:59:51 +0000
Subject: Bug #52109 [Bgs]: session_start / session_write_close memory leak
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-152051@lists.php.net to get a copy of this message
Edit report at http://bugs.php.net/bug.php?id=52109&edit=1 ID: 52109 User updated by: smacky86 at gmail dot com Reported by: smacky86 at gmail dot com Summary: session_start / session_write_close memory leak Status: Bogus Type: Bug Package: Session related Operating System: Linux PHP Version: 5.3.2 New Comment: In my case I start a database synchronization from a website, send the job to the background, and show the actual result to the user. e.g.: if (isset($_POST["user_clicked_on_the_synch_button"])) { header("Location: ?result_page"); header("Content-length: 0"); header("Connection: close"); session_write_close(); usleep(100); // at this point the browser goes to the result page, and we can start the synchronization process in the background synch(); // this event handler is called after every synchronized product function onSynchEvent() { // here i need to save the actual state of the synch process session_start(); $_SESSION["blah"]++; session_write_close(); } } On the result page I can check this session variable with periodic ajax requests. The session has to be closed due to the file lock. This is why I have to call session start/close multiple times. Since the browser is already detached, it throws the "cannot start session, headers already sent" errors, but even then the data is stored in session. Previous Comments: ------------------------------------------------------------------------ [2010-07-03 11:52:28] johannes@php.net That is expected. You might have sessions with different session names and keeping a list of them is a source of more trouble than simply sending them out in the correct order and letting the browser decide which to keep. Especially as usually no application doe multiple session_start) calls. ------------------------------------------------------------------------ [2010-07-03 04:06:24] smacky86 at gmail dot com Now I was able to test this case with a fresh new setup, now really v5.3.2 (the previous was 5.2.9, but I opend the ticket as 5.3.2). The problem without Suhosin or any other extension doesn't appear, so the first question is solved. But I observed something: the header of the HTTP response contains a lot of Set-Cookie line, one for each session_start() call. I don't think it's the right way it should work. ------------------------------------------------------------------------ [2010-06-21 07:19:26] kalle@php.net I forgot to include, did you try to disable the Zend allocator (USE_ZEND_ALLOC)? ------------------------------------------------------------------------ [2010-06-21 07:07:56] kalle@php.net We don't support PHP patched with 3rd party patches like Suhosin, what is the results without, and what does valgrind give you? Should show if there is a real leak ------------------------------------------------------------------------ [2010-06-17 15:49:23] smacky86 at gmail dot com Description: ------------ session_start() and session_write_close() don't free unused memory. When they are called multiple times, the memory usage reported by memory_get_usage() constantly grows. The session data is stored in files, ini settings are default. # php -v PHP 5.2.9 (cli) (built: Sep 1 2009 11:43:38) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies with Suhosin v0.9.31, Copyright (c) 2007-2010, by SektionEins GmbH Test script: --------------- session_start(); $_SESSION["foo"] = str_repeat("bar", 5000); session_write_close(); $memory_before = round(memory_get_usage() / 1024, 2) . "KB"; for ($i=0; $i<1000; $i++) { session_start(); session_write_close(); } $memory_after = round(memory_get_usage() / 1024, 2) . "KB"; echo "Before: " . $memory_before . "\n"; echo "After: " . $memory_after; Expected result: ---------------- Before: 88.34KB After: 88.34KB (or something small amount) Actual result: -------------- Before: 88.34KB After: 19906.61K ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/bug.php?id=52109&edit=1

« previous php.bugs (#152051) next »