php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #24131 session_start() warns about failed read
Submitted: 2003-06-11 13:17 UTC Modified: 2003-06-12 05:39 UTC
From: meat at reed dot edu Assigned:
Status: Not a bug Package: Session related
PHP Version: 4.3.2 OS: Linux 2.2.16-22 SMP
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: meat at reed dot edu
New email:
PHP Version: OS:

 

 [2003-06-11 13:17 UTC] meat at reed dot edu 
This problem first occurred for me on PHP 4.3.2, and 
installing the CVS snapshot for 6-10-2003 did not help.  

When calling session_start() for the first time, in a 
script as simple as this one:

<?php

session_start();

?>

This warning appears in the browser:

Warning:  session_start(): read failed: Value too large 
for defined data type (75) in /usr/local/httpd/webapp/
html/tools/lib/std.php on line 19

Line 19 in the above script is simply 
"session_start()".  If I preface the call with an @ to 
turn off warnings/errors, then the script works as 
intended.  If I remove the @ while the session is 
active, the error is not given, but as soon as I log 
out (i.e. call session_destroy()), it comes back.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-06-11 17:33 UTC] sniper@php.net 
What is the session.save_path set to? And on what kind
of partition does that exist? (never seen this before, might be something broken in your system..)
 [2003-06-11 17:41 UTC] meat at reed dot edu 
This occurs both when session.save_path is the default 
(/tmp) and when I set it to something else.  The 
session files are created successfully.  Like I said in 
the original submissions, the sessions appear to work 
just fine, and the warning only happens when starting a 
fresh session.  It's totally possible that something is 
broken on the system, but that would seem to be at odds 
with the apparent functionality despite the warning.
 [2003-06-11 18:42 UTC] sniper@php.net 
Can you reproduce this within some other machine?
And are you sure it's not just some bug in that kernel?
(latest is 2.2.25 already.. :)
 [2003-06-11 23:13 UTC] meat at reed dot edu 
I certainly hope that I can't reproduce this bug, since 
all it takes is a call to session_start()--all configs 
are out-of-the-box defaults.  No, I am not sure it's 
not a kernel bug, but the same scripts work flawlessly 
on my FreeBSD box.  I guess I will keep it as 
@session_start() and see if the admin will upgrade the 
kernel (and the Apache installation).
 [2003-06-12 05:39 UTC] sniper@php.net 
Since even you can't reproduce it on another box, we should
assume it's just problem with the system, not PHP.
 [2003-07-02 03:45 UTC] dont at spam dot me "manfred at yumyum dot at" 
ok, i also had this bug with 4.3.2 on a RH 6.2 system and could reproduce it.

the php source code for this shows in 4.2.2:
-------------------------------------
if (n != sbuf.st_size) {
        efree(*val);
        return FAILURE;
    }
-------------------------------------

while in 4.3.2:
-------------------------------------
if (n != sbuf.st_size) {
        if (n == -1)
            php_error_docref(NULL TSRMLS_CC, E_WARNING, "read failed: %s (%d)", strerror(errno), errno);        
        else
            php_error_docref(NULL TSRMLS_CC, E_WARNING, "read returned less bytes than requested");

        efree(*val);
        return FAILURE;
    }
-------------------------------------
so basically its the same code as in 4.2.2 just with
some warning-messages added.

so i assume the reason for the warnings was also there in 4.2.2. but with 4.2.2 the whole stuff worked, so maybe that
warning should be safe to ignore.

i just commented the 2 warnings out in the source code, works for me now (altough not a clean solution;)

i think the whole stuff might be caused by some 32/64 bit troubles in the system. this is what i found somewhere else:

------------------------
At a glance I'd say an lstat limit. There's an lstat64() call whose returned structure has wider size fields. That's the core reason for this ugly open64/lseek64/... fiasco - binary compatability :-(
Given that system calls are a binary API you're pretty much stuck with this.
---------------------------
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Thu Nov 06 16:00:01 2025 UTC