#32568 [Opn]: session data is not available
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 ---application--- append.inc 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=32568&edit=1
#32568 [NEW]: session data is not available
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 ---application--- append.inc 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=32568&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32568&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32568&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32568&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32568&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32568&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32568&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32568&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32568&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32568&r=support Expected behavior: http://bugs.php.net/fix.php?id=32568&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32568&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32568&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32568&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32568&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32568&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32568&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32568&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32568&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32568&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32568&r=mysqlcfg
#32564 [Com]: unset session in foreach
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: $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 , 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=32564&edit=1
#28263 [Com]: PNG image generation causes Segmentation Fault
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=28263&edit=1
#25777 [Fbk->Opn]: char and varchar fields are being rtrimmed (and also ltrimmed?) using freetds
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=25777&edit=1
#25777 [NEW]: char and varchar fields are being rtrimmed (and also ltrimmed?) using freetds
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=25777&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25777&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25777&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25777&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25777&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25777&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25777&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25777&r=support Expected behavior: http://bugs.php.net/fix.php?id=25777&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25777&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25777&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25777&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25777&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25777&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25777&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25777&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25777&r=float