#32564 [Com]: unset session in foreach

[duh at dowebwedo dot com]

 ID:   32564
 Comment by:   duh at dowebwedo dot com
 Reported By:  echenavaz at mengine dot fr
 Status:   Feedback
 Bug Type: Session related
 Operating System: debian 2.6.9
 PHP Version:  5.0.4
 New Comment:

I did not experience any problems with Apache/1.3.29 (Unix) PHP/5.0.4
on Debian stable.
Code:
?php
  $_SESSION['one'] = 1;
  $_SESSION['two'] = 2;
  $_SESSION['three'] = 3;

  print_r($_SESSION);

  foreach ($_SESSION as $key_session = $session)
unset($_SESSION[$key_session]);

  print_r($_SESSION);
?

Result is as expected:
Array ( [DF_debug] = 1 [one] = 1 [two] = 2 [three] = 3 ) Array ( )


Previous Comments:


[2005-04-04 10:23:51] [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 ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2005-04-04 10:17:18] echenavaz at mengine dot fr

Description:

work fine whith 5.0.0
do not work whith 5.0.4

(whith zlib.output_compression = On)

Reproduce code:
---
foreach($_SESSION as $key_session = $session)
{
if(substr($key_session, 0, 17) == session_pm_search)
{
unset($_SESSION[$key_session]);
}
}
$forward_url =
https://.$_SERVER['HTTP_HOST'].$_SERVER['SCRIPT_NAME'];
header(location:$forward_url);
die();



Expected result:

$_SESSION['session_pm_searchX'] are unset

Actual result:
--
$_SESSION['session_pm_searchX'] are not unset





-- 
Edit this bug report at http://bugs.php.net/?id=32564edit=1

#32568 [NEW]: session data is not available

[duh at dowebwedo dot com]

From: duh at dowebwedo dot com
Operating system: Debian stable
PHP version:  5.0.4
PHP Bug Type: Session related
Bug description:  session data is not available

Description:

Session data stored in the session is not available when reloading the
page again. This problem occured after upgrading from php 5.0.3 to 5.0.4;
in 5.0.3 we do not experience this problem.

The last (append.inc) session listing in the first page request shows the
session variables added to the session. One would expect these variables
to show in the first (prepend.inc) session listing in the second page
request. However, they do not show?

The same situation using php 5.0.3 returns the expected result, so it can
safely be assumed that modifications made in php 5.0.3 to php 5.0.4 has
introduced this session problem. 

Reproduce code:
---
Example source:
---
prepend.inc
?php
  print_r($_SESSION);
  ...
  $db = new debugger();
  ...
?

---application---

append.inc
?php
  $db-show();
  ...
  print_r($_SESSION);
?


Info:
-
The application reads and writes to the session which means the session in
the prepend can contain different values than in the append. Reading and
Writing is done in classes (in this example: class debugger). 


Expected result:

Output first page request:
--
Array ( ) 
...
Array ( [DF_debug] = 1 [DF] = Array ( [debugger] = Array (
[debug_script] = [debug_php] = [debug_debugging] = [debug_queries] =
[debug_get] = [debug_post] = [debug_cookie] = [debug_session] = ) ) )


Output second page request:
---
Array ( [DF_debug] = 1 [DF] = Array ( [debugger] = Array (
[debug_script] = [debug_php] = [debug_debugging] = [debug_queries] =
[debug_get] = [debug_post] = [debug_cookie] = [debug_session] = ) ) )

...
Array ( [DF_debug] = 1 [DF] = Array ( [debugger] = Array (
[debug_script] = [debug_php] = [debug_debugging] = [debug_queries] =
[debug_get] = [debug_post] = [debug_cookie] = [debug_session] = ) ) )




Actual result:
--
Output first page request:
--
Array ( ) 
...
Array ( [DF_debug] = 1 [DF] = Array ( [debugger] = Array (
[debug_script] = [debug_php] = [debug_debugging] = [debug_queries] =
[debug_get] = [debug_post] = [debug_cookie] = [debug_session] = ) ) )


Output second page request:
---
Array ( [DF_debug] = 1 ) 
...
Array ( [DF_debug] = 1 [DF] = Array ( [debugger] = Array (
[debug_script] = [debug_php] = [debug_debugging] = [debug_queries] =
[debug_get] = [debug_post] = [debug_cookie] = [debug_session] = ) ) )




-- 
Edit bug report at http://bugs.php.net/?id=32568edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=32568r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=32568r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=32568r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32568r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32568r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=32568r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=32568r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=32568r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32568r=support
Expected behavior:   http://bugs.php.net/fix.php?id=32568r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=32568r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=32568r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32568r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=32568r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32568r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=32568r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32568r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=32568r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=32568r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=32568r=mysqlcfg

#32568 [Opn]: session data is not available

[duh at dowebwedo dot com]

 ID:   32568
 User updated by:  duh at dowebwedo dot com
 Reported By:  duh at dowebwedo dot com
 Status:   Open
 Bug Type: Session related
 Operating System: Debian stable
 PHP Version:  5.0.4
 New Comment:

In addition to my bugreport some additional information:

The session file appearantly does not contain the last session
information that is shown through the print_r($_SESSION):
cat sess_9ces9k67hse393stv6dns4t964 
DF_debug|b:1;

At first I wanted to use the class destructor (__destruct(..) ) with my
debugger but appearantly sessions are not available when destructing.
Adding $db-show() to my append.inc instead solved that problem.
Perhaps the behaviour of __destruct and append.inc are now based on the
same rules?


Previous Comments:


[2005-04-04 15:28:16] duh at dowebwedo dot com

Description:

Session data stored in the session is not available when reloading the
page again. This problem occured after upgrading from php 5.0.3 to
5.0.4; in 5.0.3 we do not experience this problem.

The last (append.inc) session listing in the first page request shows
the session variables added to the session. One would expect these
variables to show in the first (prepend.inc) session listing in the
second page request. However, they do not show?

The same situation using php 5.0.3 returns the expected result, so it
can safely be assumed that modifications made in php 5.0.3 to php 5.0.4
has introduced this session problem. 

Reproduce code:
---
Example source:
---
prepend.inc
?php
  print_r($_SESSION);
  ...
  $db = new debugger();
  ...
?

---application---

append.inc
?php
  $db-show();
  ...
  print_r($_SESSION);
?


Info:
-
The application reads and writes to the session which means the session
in the prepend can contain different values than in the append. Reading
and Writing is done in classes (in this example: class debugger). 


Expected result:

Output first page request:
--
Array ( ) 
...
Array ( [DF_debug] = 1 [DF] = Array ( [debugger] = Array (
[debug_script] = [debug_php] = [debug_debugging] = [debug_queries]
= [debug_get] = [debug_post] = [debug_cookie] = [debug_session] =
) ) ) 

Output second page request:
---
Array ( [DF_debug] = 1 [DF] = Array ( [debugger] = Array (
[debug_script] = [debug_php] = [debug_debugging] = [debug_queries]
= [debug_get] = [debug_post] = [debug_cookie] = [debug_session] =
) ) ) 
...
Array ( [DF_debug] = 1 [DF] = Array ( [debugger] = Array (
[debug_script] = [debug_php] = [debug_debugging] = [debug_queries]
= [debug_get] = [debug_post] = [debug_cookie] = [debug_session] =
) ) ) 



Actual result:
--
Output first page request:
--
Array ( ) 
...
Array ( [DF_debug] = 1 [DF] = Array ( [debugger] = Array (
[debug_script] = [debug_php] = [debug_debugging] = [debug_queries]
= [debug_get] = [debug_post] = [debug_cookie] = [debug_session] =
) ) ) 

Output second page request:
---
Array ( [DF_debug] = 1 ) 
...
Array ( [DF_debug] = 1 [DF] = Array ( [debugger] = Array (
[debug_script] = [debug_php] = [debug_debugging] = [debug_queries]
= [debug_get] = [debug_post] = [debug_cookie] = [debug_session] =
) ) ) 







-- 
Edit this bug report at http://bugs.php.net/?id=32568edit=1

#28263 [Com]: PNG image generation causes Segmentation Fault

[duh at dowebwedo dot com]

 ID:   28263
 Comment by:   duh at dowebwedo dot com
 Reported By:  Rich dot West at wesmo dot com
 Status:   No Feedback
 Bug Type: GD related
 Operating System: Fedora Core 1
 PHP Version:  4.3.6
 Assigned To:  pajoye
 New Comment:

I am experiencing the same bug since we upgraded from php 4.3.5 tot
4.3.6, 4.3.7 and the latest snapshot (php4-STABLE-200405270830). I have
backtraced the point to where php crashes and that is the
imagecreatefrompng function:

...
eval(sprintf(\$this-image =
imagecreatefrom%s(\$this-image_file);,$this-ext2func[$image_type]));
...

(note: i use eval in my class to dynamically open images; however
without the evaluation the function still kills my application)

However downgrading back to php-4.3.5 does not seem to solve the
problem.

We are running debian stable with all recent upgrades (libpng etc) with
apache (1.3.29) and php and compiled php with the following configure
command:

'./configure' '--with-pgsql' '--with-apxs=/www/bin/apxs' '--with-gd'
'--with-png-dir' '--with-freetype-dir' '--with-jpeg-dir' '--with-pear'
'--with-zlib-dir' '--enable-track-vars' '--enable-trans-sid'
'--disable-posix-threads' '--enable-shared' '--enable-exif'
'--enable-memory-limit' 

I hope this bug will be fixed soon.

Grtz, Jeroen


Previous Comments:


[2004-05-23 01:00:09] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



[2004-05-15 06:30:06] [EMAIL PROTECTED]

Change status when you give the feedback asked for.



[2004-05-15 01:47:52] Rich dot West at wesmo dot com

Still open.  I was at a training class and unable to test.

I will test it this weekend.



[2004-05-15 01:00:06] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



[2004-05-07 11:04:39] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Hello,

Cannot reproduce, please try with a snapshot.

I also use libpng-1.2.2 (which is available since this week through yum
in fdc1).

--Pierre



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/28263

-- 
Edit this bug report at http://bugs.php.net/?id=28263edit=1

#25777 [Fbk-Opn]: char and varchar fields are being rtrimmed (and also ltrimmed?) using freetds

[duh at dowebwedo dot com]

 ID:   25777
 User updated by:  duh at dowebwedo dot com
 Reported By:  duh at dowebwedo dot com
-Status:   Feedback
+Status:   Open
 Bug Type: MSSQL related
 Operating System: Debian GNU/Linux 3.0
 PHP Version:  4.3.4RC1
 New Comment:

the configure line is:

'./configure' '--with-mysql' '--with-apxs=/www/bin/apxs'
'--with-gd=/usr/local' '--with-png-dir' '--with-freetype-dir'
'--with-pear' '--with-zlib-dir' '--enable-track-vars'
'--enable-trans-sid' '--disable-posix-threads' '--enable-shared'
'--with-pgsql=/usr' '--with-unixODBC=/usr/local/easysoft/unixODBC'
'--with-mssql=/usr/local'


Previous Comments:


[2003-10-07 19:09:27] [EMAIL PROTECTED]

What was the configure line used to configure PHP?




[2003-10-07 09:43:10] duh at dowebwedo dot com

Description:

I am busy developing a new improved version of our intranet running on
Apache/php/Debian and moved in this version from ODBC to MSSQL/Sybase
connections (ODBC gave a lot of overhead and appeared being quite
slow).

In several intranet functions we aquire data from the Exact financial
suite (http://www.exactsoftware.com) which is largely used in The
Netherlands and abroad and which currently uses MSSQL as a database
backend. In the most recent versions of exact you can still see their
MS-DOS history (exact used btrieve and several other MS-DOS databases
in the old days) because several columns are still padded to the
maximum column width. Hence the word hi in a varchar(8) would be
stored as hi   (hi+6 spaces). 

Now when using mssql_* functions in php over freetds all selected
values are right trimmed, so SELECT hi FROM table will return hi
instead of the actual data in the table hi  . I have currently
only tried selecting, i don't know what happens when inserting
(probably the same?).

Obviously, this is not what I want since this would lead to data
inconsistency (in your financial system!) and an unuseable financial
system (which ofcourse is the worst that could happen to a company).

At first I thought it was due to the fact that sybase used to right
trim these values so freetds does it as well for compatibility's sake.
But when I executed a query command line through the tsql
(/usr/local/bin/tsql) application it appeared that then the values were
NOT being right trimmed. So appearantly the interface between freetds
and my application (which in my opinion can only be php) does the
trimming of values with spaces.

Ofcourse one could say that I need to trim or append spaces to these
values myself, but since most data and software is dynamic and only
some (var)char fields will get appended and some don't, there is no way
of telling which columns should be appended (or prepended) and which
shouldn't.

For the sake of data consistency I would either like to see this bug
fixed, or -if it is no bug but a feature- see a configuration option
being introduced to overrule this trimming.

Reproduce code:
---
In php the following code will return trimmed values:
$db= mssql_connect('server','user','pass'); 
$result= mssql_query(SELECT TOP 1 medewerker FROM Efw_001.[dbo].Prres1
WHERE medewerker IS NOT NULL AND medewerker LIKE '%  %');
$a  = mssql_fetch_assoc($result); 
print_r($a);

but commandline this values are not being trimmed:
# tsql -S server -U user -P pass
locale is C
charset is ANSI_X3.4-1968
Msg 5703, Level 0, State 1, Server NTS1, Line 0
Changed language setting to us_english.
1 SELECT TOP 1 medewerker FROM Efw_001.[dbo].Prres1 WHERE medewerker
IS NOT NULL AND medewerker LIKE '%  %'
2 go
medewerker
'100 ' (size=8)
1 SELECT TOP 1 rtrim(medewerker) as trimmed_medewerker FROM
Efw_001.[dbo].Prres1 WHERE medewerker IS NOT NULL AND medewerker LIKE
'%  %'
2 go
trimmed_medewerker
'100' (size=3)

(I added single quotes around the results and wrote the sizes behind it
so you can see the difference between the two queries)

Expected result:

Obviously I expect to get exactly the same data that is stored in the
database instead of modified (trimmed) data.






-- 
Edit this bug report at http://bugs.php.net/?id=25777edit=1

#25777 [NEW]: char and varchar fields are being rtrimmed (and also ltrimmed?) using freetds

[duh at dowebwedo dot com]

From: duh at dowebwedo dot com
Operating system: Debian GNU/Linux 3.0
PHP version:  4.3.4RC1
PHP Bug Type: MSSQL related
Bug description:  char and varchar fields are being rtrimmed (and also ltrimmed?) 
using freetds

Description:

I am busy developing a new improved version of our intranet running on
Apache/php/Debian and moved in this version from ODBC to MSSQL/Sybase
connections (ODBC gave a lot of overhead and appeared being quite slow).

In several intranet functions we aquire data from the Exact financial
suite (http://www.exactsoftware.com) which is largely used in The
Netherlands and abroad and which currently uses MSSQL as a database
backend. In the most recent versions of exact you can still see their
MS-DOS history (exact used btrieve and several other MS-DOS databases in
the old days) because several columns are still padded to the maximum
column width. Hence the word hi in a varchar(8) would be stored as hi  
(hi+6 spaces). 

Now when using mssql_* functions in php over freetds all selected values
are right trimmed, so SELECT hi FROM table will return hi instead of the
actual data in the table hi  . I have currently only tried
selecting, i don't know what happens when inserting (probably the same?).

Obviously, this is not what I want since this would lead to data
inconsistency (in your financial system!) and an unuseable financial
system (which ofcourse is the worst that could happen to a company).

At first I thought it was due to the fact that sybase used to right trim
these values so freetds does it as well for compatibility's sake. But when
I executed a query command line through the tsql (/usr/local/bin/tsql)
application it appeared that then the values were NOT being right trimmed.
So appearantly the interface between freetds and my application (which in
my opinion can only be php) does the trimming of values with spaces.

Ofcourse one could say that I need to trim or append spaces to these
values myself, but since most data and software is dynamic and only some
(var)char fields will get appended and some don't, there is no way of
telling which columns should be appended (or prepended) and which
shouldn't.

For the sake of data consistency I would either like to see this bug
fixed, or -if it is no bug but a feature- see a configuration option being
introduced to overrule this trimming.

Reproduce code:
---
In php the following code will return trimmed values:
$db= mssql_connect('server','user','pass'); 
$result= mssql_query(SELECT TOP 1 medewerker FROM Efw_001.[dbo].Prres1
WHERE medewerker IS NOT NULL AND medewerker LIKE '%  %');
$a  = mssql_fetch_assoc($result); 
print_r($a);

but commandline this values are not being trimmed:
# tsql -S server -U user -P pass
locale is C
charset is ANSI_X3.4-1968
Msg 5703, Level 0, State 1, Server NTS1, Line 0
Changed language setting to us_english.
1 SELECT TOP 1 medewerker FROM Efw_001.[dbo].Prres1 WHERE medewerker IS
NOT NULL AND medewerker LIKE '%  %'
2 go
medewerker
'100 ' (size=8)
1 SELECT TOP 1 rtrim(medewerker) as trimmed_medewerker FROM
Efw_001.[dbo].Prres1 WHERE medewerker IS NOT NULL AND medewerker LIKE '% 
%'
2 go
trimmed_medewerker
'100' (size=3)

(I added single quotes around the results and wrote the sizes behind it so
you can see the difference between the two queries)

Expected result:

Obviously I expect to get exactly the same data that is stored in the
database instead of modified (trimmed) data.


-- 
Edit bug report at http://bugs.php.net/?id=25777edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25777r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25777r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25777r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25777r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25777r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25777r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25777r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25777r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25777r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25777r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=25777r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25777r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=25777r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=25777r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25777r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25777r=float