#39193 [Com]: unset($_SESSION[$key]) not saving session after reload
ID: 39193
Comment by: john dot cecere at sun dot com
Reported By: gearb0x at eml dot cc
Status: Assigned
Bug Type: Session related
Operating System: Linux FC4
PHP Version: 5.1.6
Assigned To: iliaa
New Comment:
I ran into this today with PHP 5.1.6. I spent most of the afternoon
trying to figure out why my vars were coming back after a header()
call.
One might suggest that this isn't a bug and that this behavior is
described in the docs (the session_unregister page for example). I
would disagree with this. This behavior is very quirky and completely
counter-intuitive. It would be much better for unset to behave in a way
that you would expect, i.e. to unset a variable (or element of a
variable) so that it stays unset, regardless of whether that variable
happens to be $_SESSION or not.
John
Previous Comments:
[2006-10-19 15:40:04] gearb0x at eml dot cc
It doesnt clear it, all variables stay intact as they were when the
session started. It clears it in the current execution of the script,
but the next time the page loads all the variables are back as they
were before they were unset call
If i make any changes to session variables AFTER ive tried to unset one
they are not saved in the session on the next page load
Its as if the session doesnt save, even forcing the save with
session_write_close does not work
[2006-10-19 07:47:04] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
>This should clear the session.
But it does ... instead?
[2006-10-19 04:19:11] gearb0x at eml dot cc
replacing unset($_SESSION[$key]) with session_unregister($key) has the
desired effect -- which your not suposed to use according to all docs.
[2006-10-19 04:01:21] gearb0x at eml dot cc
Description:
For some reason unseting session variables is stopping php from saving
any session variables. The code below should clear the session but it
isnt, this code worked fine on 5.1.2 on a freeBSD box. Also ive noticed
that if i make any changes to the session variables (ie: adding new
ones) they dont get saved in the session either
Reproduce code:
---
$value)
{
unset($_SESSION[$key]);
}
?>
Expected result:
This should clear the session. Also, any other changes made to the
session arent saved either (ie: creating more session variables
--
Edit this bug report at http://bugs.php.net/?id=39193&edit=1
#37716 [Bgs]: PHP + OpenLDAP crash
ID: 37716
User updated by: john dot cecere at sun dot com
Reported By: john dot cecere at sun dot com
Status: Bogus
Bug Type: Reproducible crash
Operating System: Solaris 10
PHP Version: 5.1.4
New Comment:
Interesting. I was able to make the problem go away by adding -xdepend
(my previous compilation used no optimizations). The problem also went
away when I used -fast (which is a macro that includes -xdepend).
I will log a bug on SunStudio and see where it goes.
Previous Comments:
[2006-06-14 16:58:52] [EMAIL PROTECTED]
Quick search revealed that there really has been problems with the
SunStudio. (especially with -xdepend it seems)
[2006-06-08 13:47:19] john dot cecere at sun dot com
I've done a little digging on this problem and found out a few things.
First of all, this only affects SPARC. The AMD64 version that I built
didn't have this problem.
I also tried debugging this via dbx. Here's the result:
[EMAIL PROTECTED] ([EMAIL PROTECTED]) signal SEGV (no mapping at the fault
address) in
ldap_unbind_ext at line 49 in file "unbind.c"
49 assert( LDAP_VALID( ld ) );
(dbx) where
current thread: [EMAIL PROTECTED]
=>[1] ldap_unbind_ext(ld = 0x9fdf00, sctrls = (nil), cctrls = (nil)),
line 49 in "unbind.c"
[2] ldap_unbind_s(ld = 0x9fdf00), line 210 in "unbind.c"
[3] _close_ldap_link(rsrc = 0x1009f3238), line 194 in "ldap.c"
[4] list_entry_destructor(ptr = 0x1009f3238), line 184 in
"zend_list.c"
[5] zend_hash_del_key_or_index(ht = 0x1008a6ae0, arKey = (nil),
nKeyLength = 0, h = 1U, flag = 1), line 492 in "zend_hash.c"
[6] _zend_list_delete(id = 1), line 58 in "zend_list.c"
[7] _zval_dtor_func(zvalue = 0x1009f31f8), line 60 in
"zend_variables.c"
[8] _zval_dtor(zvalue = 0x1009f31f8), line 35 in "zend_variables.h"
[9] _zval_ptr_dtor(zval_ptr = 0x1009fc710), line 395 in
"zend_execute_API.c"
[10] zend_hash_apply_deleter(ht = 0x1008a6988, p = 0x1009fc6f8), line
576 in "zend_hash.c"
[11] zend_hash_graceful_reverse_destroy(ht = 0x1008a6988), line 642
in "zend_hash.c"
[12] shutdown_executor(), line 221 in "zend_execute_API.c"
[13] zend_deactivate(), line 854 in "zend.c"
[14] php_request_shutdown(0x0, 0x2000, 0x130814, 0x7d5b27b8,
0x7d6e4000, 0x1009fd080), at 0x1004dccec
[15] main(argc = 2, argv = 0x79f8), line 1666 in
"cgi_main.c"
I put a stop in list_entry_destructor (btw this wasn't arbitrary. I'm
just trying to make this story as short as I can) and took a look at
what was happening to ld:
(dbx) print *ld
*ld = {
list_dtor = (nil)
plist_dtor= (nil)
list_dtor_ex = 0x100276a80 =
&`php`ldap.c`_close_ldap_link(zend_rsrc_list_entry *rsrc)
plist_dtor_ex = (nil)
type_name = 0x100887b68 "ldap link"
module_number = 15
resource_id = 18
type = '\002'
}
(dbx) step
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in list_entry_destructor at line
184 in file
"zend_list.c"
184 ld->list_dtor_ex(le
TSRMLS_CC);
(dbx) print *ld
*ld = {
list_dtor = (nil)
plist_dtor= (nil)
list_dtor_ex = 0x100276a80 =
&`php`ldap.c`_close_ldap_link(zend_rsrc_list_entry *rsrc)
plist_dtor_ex = (nil)
type_name = 0x100887b68 "ldap link"
module_number = 15
resource_id = 18
type = '\002'
}
(dbx) step
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in _close_ldap_link at line 192
in file "ldap.c"
192 ldap_linkdata *ld = (ldap_linkdata *)rsrc->ptr;
(dbx) print *ld
dbx: cannot access address 0x12
(dbx) step
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in _close_ldap_link at line 194
in file "ldap.c"
194 ldap_unbind_s(ld->link);
(dbx) print *ld
*ld = {
link = 0x9fdf00
rebindproc = (nil)
}
(dbx) step
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in ldap_unbind_s at line 210 in
file "unbind.c"
210 return( ldap_unbind_ext( ld, NULL, NULL ) );
(dbx) print *ld
dbx: cannot access address 0x9fdf00
(dbx)
My guess is that the address 0x9fdf00 is supposed to point to an LDAP
structure, but it doesn't for some reason. I'll leave this to someone
else to figure out why. It looks like something is getting stepped on
in Zend's hash tables.
Since I only had this problem in 64-bit SPARC, I decided to play around
with some of the compiler optimizations. I found out that adding
-xdepend to CFLAGS and rebuilding PHP makes this problem go away.
--
#37716 [Opn]: PHP + OpenLDAP crash
ID: 37716
User updated by: john dot cecere at sun dot com
Reported By: john dot cecere at sun dot com
Status: Open
Bug Type: Reproducible crash
Operating System: Solaris 10
PHP Version: 5.1.4
New Comment:
I've done a little digging on this problem and found out a few things.
First of all, this only affects SPARC. The AMD64 version that I built
didn't have this problem.
I also tried debugging this via dbx. Here's the result:
[EMAIL PROTECTED] ([EMAIL PROTECTED]) signal SEGV (no mapping at the fault
address) in
ldap_unbind_ext at line 49 in file "unbind.c"
49 assert( LDAP_VALID( ld ) );
(dbx) where
current thread: [EMAIL PROTECTED]
=>[1] ldap_unbind_ext(ld = 0x9fdf00, sctrls = (nil), cctrls = (nil)),
line 49 in "unbind.c"
[2] ldap_unbind_s(ld = 0x9fdf00), line 210 in "unbind.c"
[3] _close_ldap_link(rsrc = 0x1009f3238), line 194 in "ldap.c"
[4] list_entry_destructor(ptr = 0x1009f3238), line 184 in
"zend_list.c"
[5] zend_hash_del_key_or_index(ht = 0x1008a6ae0, arKey = (nil),
nKeyLength = 0, h = 1U, flag = 1), line 492 in "zend_hash.c"
[6] _zend_list_delete(id = 1), line 58 in "zend_list.c"
[7] _zval_dtor_func(zvalue = 0x1009f31f8), line 60 in
"zend_variables.c"
[8] _zval_dtor(zvalue = 0x1009f31f8), line 35 in "zend_variables.h"
[9] _zval_ptr_dtor(zval_ptr = 0x1009fc710), line 395 in
"zend_execute_API.c"
[10] zend_hash_apply_deleter(ht = 0x1008a6988, p = 0x1009fc6f8), line
576 in "zend_hash.c"
[11] zend_hash_graceful_reverse_destroy(ht = 0x1008a6988), line 642
in "zend_hash.c"
[12] shutdown_executor(), line 221 in "zend_execute_API.c"
[13] zend_deactivate(), line 854 in "zend.c"
[14] php_request_shutdown(0x0, 0x2000, 0x130814, 0x7d5b27b8,
0x7d6e4000, 0x1009fd080), at 0x1004dccec
[15] main(argc = 2, argv = 0x79f8), line 1666 in
"cgi_main.c"
I put a stop in list_entry_destructor (btw this wasn't arbitrary. I'm
just trying to make this story as short as I can) and took a look at
what was happening to ld:
(dbx) print *ld
*ld = {
list_dtor = (nil)
plist_dtor= (nil)
list_dtor_ex = 0x100276a80 =
&`php`ldap.c`_close_ldap_link(zend_rsrc_list_entry *rsrc)
plist_dtor_ex = (nil)
type_name = 0x100887b68 "ldap link"
module_number = 15
resource_id = 18
type = '\002'
}
(dbx) step
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in list_entry_destructor at line
184 in file
"zend_list.c"
184 ld->list_dtor_ex(le
TSRMLS_CC);
(dbx) print *ld
*ld = {
list_dtor = (nil)
plist_dtor= (nil)
list_dtor_ex = 0x100276a80 =
&`php`ldap.c`_close_ldap_link(zend_rsrc_list_entry *rsrc)
plist_dtor_ex = (nil)
type_name = 0x100887b68 "ldap link"
module_number = 15
resource_id = 18
type = '\002'
}
(dbx) step
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in _close_ldap_link at line 192
in file "ldap.c"
192 ldap_linkdata *ld = (ldap_linkdata *)rsrc->ptr;
(dbx) print *ld
dbx: cannot access address 0x12
(dbx) step
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in _close_ldap_link at line 194
in file "ldap.c"
194 ldap_unbind_s(ld->link);
(dbx) print *ld
*ld = {
link = 0x9fdf00
rebindproc = (nil)
}
(dbx) step
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in ldap_unbind_s at line 210 in
file "unbind.c"
210 return( ldap_unbind_ext( ld, NULL, NULL ) );
(dbx) print *ld
dbx: cannot access address 0x9fdf00
(dbx)
My guess is that the address 0x9fdf00 is supposed to point to an LDAP
structure, but it doesn't for some reason. I'll leave this to someone
else to figure out why. It looks like something is getting stepped on
in Zend's hash tables.
Since I only had this problem in 64-bit SPARC, I decided to play around
with some of the compiler optimizations. I found out that adding
-xdepend to CFLAGS and rebuilding PHP makes this problem go away.
Previous Comments:
[2006-06-06 18:11:24] john dot cecere at sun dot com
Description:
When I build PHP 5.1.4 with OpenLDAP (2.3.23) support in 64-bit mode in
Solaris 10 using SunStudio (10 or 11) on SPARC (I haven't tested AMD64
yet), PHP core dumps when I try to run this program:
PHP works!!!';
$ds=ldap_connect("ldap-server");
?>
(ldap-server is the name of a valid ldap server)
# php tst.php
PHP works!!!Segmentation Fault(coredump)
#
mdb in Solaris reveals this as the last call in the stacktrace:
libldap-2.3.so.0.2.11`ldap_unbind_ext+0x74(8c75d0, 0, 0, 0, 0, 0)
One mig
#37716 [NEW]: PHP + OpenLDAP crash
From: john dot cecere at sun dot com
Operating system: Solaris 10
PHP version: 5.1.4
PHP Bug Type: Reproducible crash
Bug description: PHP + OpenLDAP crash
Description:
When I build PHP 5.1.4 with OpenLDAP (2.3.23) support in 64-bit mode in
Solaris 10 using SunStudio (10 or 11) on SPARC (I haven't tested AMD64
yet), PHP core dumps when I try to run this program:
PHP works!!!';
$ds=ldap_connect("ldap-server");
?>
(ldap-server is the name of a valid ldap server)
# php tst.php
PHP works!!!Segmentation Fault(coredump)
#
mdb in Solaris reveals this as the last call in the stacktrace:
libldap-2.3.so.0.2.11`ldap_unbind_ext+0x74(8c75d0, 0, 0, 0, 0, 0)
One might conclude that this is a problem with OpenLDAP. However, if I do
nothing else (i.e. use the same SunStudio-built OpenLDAP) but rebuild PHP
in 64-bit mode using gcc (3.4.3), the problem goes away. My general
conclusion is that this is either a compiler bug or a PHP bug. This
happens whether I build LDAP support directly into PHP or as an extension.
Changes to how I build OpenLDAP have no effect on this problem one way or
the other.
I've trimmed the parameters down to remove irrelevant variables for the
purpose of simplifying this bug report. This may or may not be a PHP bug,
but it's worth investigating. I will also pursue the course of opening a
bug against the C compiler and attempt to keep this bug updated with the
results.
The versions of software used in building PHP with parameters used to
build them:
Berkeley DB 4.4.20:
CC="/opt/SUNWspro/bin/cc"
CFLAGS="-xarch=v9"
export CC CFLAGS
cd build_unix
../dist/configure
libxml2 2.6.23:
CC="/opt/SUNWspro/bin/cc"
CFLAGS="-xarch=v9"
export CC CFLAGS
./configure --without-python
OpenLDAP 2.3.23:
CC="/opt/SUNWspro/bin/cc"
CFLAGS="-xarch=v9"
CPPFLAGS="-I/usr/local/BerkeleyDB.4.4/include"
LDFLAGS="-L/usr/local/BerkeleyDB.4.4/lib
-R/usr/local/BerkeleyDB.4.4/lib"
export CC CFLAGS CPPFLAGS LDFLAGS
./configure
PHP 5.1.4:
CC="/opt/SUNWspro/bin/cc"
CFLAGS="-xarch=v9"
CPPFLAGS="-I/usr/local/BerkeleyDB.4.4/include
-I/usr/local/include/libxml2"
LDFLAGS="-L/usr/local/BerkeleyDB.4.4/lib
-R/usr/local/BerkeleyDB.4.4/lib"
export CC CFLAGS CPPFLAGS LDFLAGS
./configure \
--with-libxml-dir=/usr/local \
--enable-dba=/usr/local \
--with-db4=/usr/local/BerkeleyDB.4.4 \
--with-ldap=/usr/local
Reproduce code:
---
Contents of tst.php:
PHP works!!!';
$ds=ldap_connect("ldap-server");
?>
Expected result:
I expected it not to core dump.
Actual result:
--
Stack trace of core file generated by php using mdb utility in Solaris
10:
# file core
core: ELF 64-bit MSB core file SPARCV9 Version 1, from 'php'
# mdb core
Loading modules: [ libc.so.1 ld.so.1 ]
> $c
libldap-2.3.so.0.2.11`ldap_unbind_ext+0x74(8c75d0, 0, 0, 0, 0, 0)
libldap-2.3.so.0.2.11`ldap_unbind_s+0x10(8c75d0, 10084b330, 10088d260,
7d5f2df0, 2, 10072eaa8)
ldap.so`_close_ldap_link+0x24(1008c0dc8, 17, 7fffec88, 0,
1008c7878,
1008c0c88)
0x10045dcbc(1008c0dc8, 1008c0dc8, 1008c7808, 0, 0, 1008c0dc8)
0x1004594d0(100735be0, 0, 0, 4, 1, 1008c7808)
0x10045d7b4(4, 77d8, 0, 0, 0, 0)
0x1004418d0(1008c0d88, 7d9f3f38, 100040670, 7d75a0a0,
7a7014f8, 1)
0x100426208(1008c0d88, 1003d4ca8, 40, 8, 1, 1008c0590)
0x1004286bc(1008c7890, 10020ded0, 10, 0, 1, 0)
0x100459870(100735a88, 1008c7878, 21d8, 7d5f2df0, 2, 10072eaa8)
0x100459b00(100735a88, 100427298, 0, 0, 1008c7878, 0)
0x100427aa0(100735b18, 74a0, 0, 0, 0, 0)
0x10044645c(100735b18, 75c0, 0, 0, 0, 0)
php_request_shutdown+0x4b4(0, 77d8, 0, 0, 0, 0)
0x1004f76e8(2, 79a8, 79c0, 7d4491e8,
7f400140, 7f400180)
_start+0x17c(0, 0, 0, 0, 0, 0)
--
Edit bug report at http://bugs.php.net/?id=37716&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37716&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37716&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37716&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37716&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37716&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37716&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37716&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37716&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37716&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37716&r=notwrong
Not enough info:
