ID: 24131
Comment by: leo at alternative dot ch
Reported By: meat at reed dot edu
Status: Bogus
Bug Type: Session related
Operating System: Linux 2.2.16-22 SMP
PHP Version: 4.3.2
New Comment:
I get this bug too with 4.3.3 on a YellowDog Champion
Server release 1.2
-leo
Previous Comments:
------------------------------------------------------------------------
[2003-07-02 03:45:12] 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.
---------------------------
------------------------------------------------------------------------
[2003-06-12 05:39:31] [EMAIL PROTECTED]
Since even you can't reproduce it on another box, we should
assume it's just problem with the system, not PHP.
------------------------------------------------------------------------
[2003-06-11 23:13:23] 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-11 18:42:38] [EMAIL PROTECTED]
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 17:41:59] 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.
------------------------------------------------------------------------
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/24131
--
Edit this bug report at http://bugs.php.net/?id=24131&edit=1
