> FATAL: emalloc(): Unable to allocate 1701082243 bytes
> FATAL: erealloc(): Unable to allocate 369098752 bytes
>
> in the log. Somehow when I query the database it must be trying to
> allocate -- unless my eyes deceive me -- ~1.6 GBs of memory in the first
> entry and ~350 Megs in the second.
>
> What could be causing this???
>
> As I mentioned earlier, I have a custom session handler set up that uses
> Manuel Lemos' Metabase library to save the session to a database (of the
> supported ones, I'm using mySQL.)
>
> I hope this message makes it to the list in a day or so (I really don't
> understand why the list is so slow...) because this is driving me crazy!
Well, the lists were on my personal DSL connection for a while. The
bandwidth requirements were too high. Sorry to drive you crazy. The
lists should be quite a bit quicker now.
As for your problem. Try to narrow down exactly where it might be
happening. For example, try eliminating the MetaBase part and use a
generic mysql session save handler like the following:
<?
function open($db,$name) {
global $table;
mysql_connect('localhost');
mysql_select_db($db);
$table = $name;
return true;
}
function close() {
mysql_close();
return true;
}
function read($id) {
global $table;
$result = mysql_query("select data from $table where id=\'$id\'");
if($result && mysql_num_rows($result)) {
return mysql_result($result,0);
} else {
error_log("read: ".mysql_error()."\n",3,"/tmp/errors.log");
return "";
}
}
function write($id, $data) {
global $table;
mysql_query("replace into $table (id,data) values('$id','$data')")
or error_log("write: ".mysql_error()."\n",3,"/tmp/errors.log");
return true;
}
function gc($max_time) {
global $table;
mysql_query("delete from $table where
UNIX_TIMESTAMP(ts)<UNIX_TIMESTAMP()-$max_time")
or error_log("gc: ".mysql_error()."\n",3,"/tmp/errors.log");
return true;
}
session_set_save_handler('open','close','read','write','destroy','gc');
?>
The schema for this handler is:
CREATE TABLE sessions (
id char(32) NOT NULL,
data text,
ts timestamp,
PRIMARY KEY (id)
)
Does it still leak with this handler? If not, if it does let us know. If
it doesn't, then it must be somewhere in the Metabase code.
-Rasmus
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]