ID: 14826
Updated by: [EMAIL PROTECTED]
-Summary: 4.1.0 on powerpc doesn't save session variables
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
Bug Type: Session related
Operating System: Debian Linux 2.2.19 ppc
PHP Version: 4.1.0
Previous Comments:
------------------------------------------------------------------------
[2002-01-14 13:37:57] [EMAIL PROTECTED]
sure! only logs page under normal acces.log nothing on error log, then
gdb also doesn't shows just nothing! but here's the strace of the
session for same script menthioned on begining: the real thing is that
it says:
(Inappropriate ioctl for device)
what to check?
bests.
open("/var/www/auth3/index34.phtml", O_RDONLY|O_LARGEFILE) = 6
getcwd("/var/www/auth3", 4095) = 15
lstat("/var", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lstat("/var/www", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lstat("/var/www/auth3", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lstat("/var/www/auth3/index34.phtml", {st_mode=S_IFREG|0644,
st_size=684, ...}) = 0
ioctl(6, 0x402c7413, 0x7fffe268) = -1 ENOTTY (Inappropriate
ioctl for device)
fstat(6, {st_mode=S_IFREG|0644, st_size=684, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x30016000
read(6, "<?php\n\nsession_start();\n\n// sess"..., 8192) = 684
read(6, "", 4096) = 0
read(6, "", 8192) = 0
ioctl(6, 0x402c7413, 0x7fffcb68) = -1 ENOTTY (Inappropriate
ioctl for device)
close(6) = 0
munmap(0x30016000, 4096) = 0
open("/tmp/sess_e5e831fb05e5f870e85a1971aee43e77", O_RDWR|O_LARGEFILE)
= 6
flock(6, LOCK_EX) = 0
fstat(6, {st_mode=S_IFREG|0600, st_size=40, ...}) = 0
pread(6, "", 0, 171798691840) = 0
time(NULL) = 1011029244
chdir("/") = 0
pwrite(6, "counter|i:1;timeAtLastLoad|i:101"..., 40, 0) = 40
close(6) = 0
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) =
0
umask(022) = 022
_newselect(0x6, 0x7ffffc68, 0, 0, 0x7ffffce8) = 0
write(5, "HTTP/1.1 200 OK\r\nDate: Mon, 14 J"..., 487) = 487
time(NULL) = 1011029244
write(17, "127.0.0.1 - - [14/Jan/2002:18:27"..., 156) = 156
gettimeofday({1011029244, 538769}, NULL) = 0
times({tms_utime=8, tms_stime=4, tms_cutime=0, tms_cstime=0}) =
2276553
rt_sigaction(SIGUSR1, {0x10018530, [], SA_INTERRUPT}, {SIG_IGN}, 8) =
0
read(5, 0x10068218, 4096) = ? ERESTARTSYS (To be
restarted)
--- SIGALRM (Alarm clock) ---
close(5) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigaction(SIGURG, {0x10016e84, [], SA_INTERRUPT}, {0x10016e84, [],
SA_INTERRUPT}, 8) = 0
rt_sigaction(SIGALRM, {0x10017148, [], SA_INTERRUPT}, {0x10017148, [],
SA_INTERRUPT}, 8) = 0
rt_sigaction(SIGUSR1, {0x10018530, [], SA_INTERRUPT}, {0x10018530, [],
SA_INTERRUPT}, 8) = 0
accept(16, <unfinished ...>
------------------------------------------------------------------------
[2002-01-11 18:50:24] [EMAIL PROTECTED]
Just making sure again. You don't get any errors (segfualt, etc) in
your apache error log, right?
I just want you to run httpd under gdb to see if you get any signal :)
gdb /usr/sbin/httpd
% run -X
------------------------------------------------------------------------
[2002-01-11 06:52:15] [EMAIL PROTECTED]
I'm sorry but my apache doesn't segfault on any moment it serves both
static pages and php pages nicely except for those php apps with
session variables that isn't able to save them.
could be the common unsigned char problem ?
what to check?
------------------------------------------------------------------------
[2002-01-10 22:34:22] [EMAIL PROTECTED]
Your httpd may be segfaulting. Run httpd under gdb see if you get
segfault or any.
------------------------------------------------------------------------
[2002-01-10 11:18:02] [EMAIL PROTECTED]
umm dosen't seems this here...
teixi@satellite:~$ cat /etc/php4/apache/php.ini | grep -i save.path
session.save_path = /tmp
teixi@satellite:~$ ls -lad /tmp
drwxrwxrwt 6 root root 1024 Jan 10 15:52 /tmp
teixi@satellite:~$ uname -a
Linux satellite 2.2.19 #1 Sat Apr 14 23:20:24 CDT 2001 ppc unknown
------------------------------------------------------------------------
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/14826
--
Edit this bug report at http://bugs.php.net/?id=14826&edit=1
