#21699 [NEW]: include() fails
From: [EMAIL PROTECTED] Operating system: XP Pro, SP1 PHP version: 4.3.0 PHP Bug Type: Scripting Engine problem Bug description: include() fails XP PRO, SP1 Apache 2.0.43 mySQL 3.23.54 PHP 4.3.0 - When attempting to use include() as in the following: include $DOCUMENT_ROOT."/php_includes/pagetimer_start.php"; or include ($DOCUMENT_ROOT."/php_includes/pagetimer_start.php"); I get the following errors: - Warning: main(/php_includes/pagetimer_start.php) [function.main]: failed to create stream: No such file or directory in Z:\htdocs\contact.php on line 3 Warning: main() [function.main]: Failed opening '/php_includes/pagetimer_start.php' for inclusion (include_path='.;c:\php4\pear') in Z:\htdocs\contact.php on line 3 - This works on my live site, not sure of the config, without errors. I have searched every corner of my dusty little web and can find nothing to indicate that this shouldn't work. Is this truly a bug or am I just missing something? -- Edit bug report at http://bugs.php.net/?id=21699&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21699&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21699&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21699&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21699&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21699&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21699&r=support Expected behavior: http://bugs.php.net/fix.php?id=21699&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21699&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21699&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21699&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21699&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21699&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21699&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21699&r=gnused
#21699 [Bgs]: include() fails
ID: 21699 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: XP Pro, SP1 PHP Version: 4.3.0 New Comment: doh! Thanks for the quick response. Could have sworn that I had this turned on. Previous Comments: [2003-01-16 18:31:51] [EMAIL PROTECTED] In PHP 4.2.0, the 'register_globals' setting default changed to 'off'. See http://www.php.net/release_4_2_0.php for more info. We are sorry about the inconvenience, but this change was a necessary part of our efforts to make PHP scripting more secure and portable. [2003-01-16 18:29:39] [EMAIL PROTECTED] XP PRO, SP1 Apache 2.0.43 mySQL 3.23.54 PHP 4.3.0 - When attempting to use include() as in the following: include $DOCUMENT_ROOT."/php_includes/pagetimer_start.php"; or include ($DOCUMENT_ROOT."/php_includes/pagetimer_start.php"); I get the following errors: - Warning: main(/php_includes/pagetimer_start.php) [function.main]: failed to create stream: No such file or directory in Z:\htdocs\contact.php on line 3 Warning: main() [function.main]: Failed opening '/php_includes/pagetimer_start.php' for inclusion (include_path='.;c:\php4\pear') in Z:\htdocs\contact.php on line 3 - This works on my live site, not sure of the config, without errors. I have searched every corner of my dusty little web and can find nothing to indicate that this shouldn't work. Is this truly a bug or am I just missing something? -- Edit this bug report at http://bugs.php.net/?id=21699&edit=1
#28373 [NEW]: Backslashes no longer escaped in $_SERVER variables
From: phpbugreport at thedigitalnetwork dot com Operating system: Windows XP SP1 PHP version: 5CVS-2004-05-12 (dev) PHP Bug Type: Apache2 related Bug description: Backslashes no longer escaped in $_SERVER variables Description: In PHP4.3.4, $_SERVER['HTTP_REFERER'], along with others like PATH, SystemRoot, COMSPEC and WINDIR, have any backslashes escaped. In PHP5RC2 & the current DEV (php5-win32-200405121430.zip) version, the items in $_SERVER are not escaped anymore. I could find no mention in the bug database or change logs, so I wondered if this was a change in the way Super Globals are handled, since $_SERVER is not part of "GPC"? Relevent INI settings: -- register_globals=Off register_argc_argv = Off gpc_order = "GPC" variables_order = "GPCS" magic_quotes_gpc = On magic_quotes_runtime = Off magic_quotes_sybase = Off -- Thanks for your assistance! Reproduce code: --- phpinfo(); Expected result: Expect to see items in _SERVER with backslashes escaped: [HTTP_REFERER] => http://localhost/Browse.php?Category=\\Language%20Arts\\Reading\\Letter%20TV&Level=4 [PATH] => C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\Program Files\\Common Files\\GTK\\2.0\\bin [SystemRoot] => C:\\WINDOWS [COMSPEC] => C:\\WINDOWS\\system32\\cmd.exe Actual result: -- Unescaped backslashes: [HTTP_REFERER] => http://localhost/Browse.php?Category=\Language%20Arts\Reading\Letter%20TV&Level=4 [PATH] => C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Common Files\\TK\2.0\bin [SystemRoot] => C:\WINDOWS [COMSPEC] => C:\WINDOWS\system32\cmd.exe -- Edit bug report at http://bugs.php.net/?id=28373&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28373&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28373&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28373&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28373&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28373&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28373&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28373&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28373&r=support Expected behavior: http://bugs.php.net/fix.php?id=28373&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28373&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28373&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28373&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28373&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28373&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28373&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28373&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28373&r=float
#29074 [Com]: mssql_connect fails under heavy load
ID: 29074 Comment by: phpbugreport at workboy dot com Reported By: david dot blair at nsi1 dot com Status: Open Bug Type: MSSQL related Operating System: MS 2003 PHP Version: 4.3.7 New Comment: We are currently running apache_1.3.28, freetds-0.61.2 and php-4.3.3 on linux 2.4.x kernels and experiencing the same problem connecting to a SQL 2000E SP3 database. Modifying our PHP db connection classes to immediately try mssql_connect again when it fails produces the desired results most of the time. However not always. I will be upgrading to the latest and greatest in the current major version for all of the components on the Linux side and testing more. I will post a follow up then. Charles Bennington Oddcast, Inc. Previous Comments: [2004-08-31 16:13:34] david dot blair at nsi1 dot com I've never had Apache hang before but I'm also not running through TDS. I just tried upgrading the production server to 5.0.1 last night. I've been running 5.0.0 on the development server and 5.0.1 on my laptop for two weeks/one week with no problems. The database connection failed 6 times last night after we brought everything back up. After 2 more failures this morning I rolled everything back. Oh hell, I just remembered I left php_mssql.dll from the 5.0.1 build in the windows directory...I think I'm going to leave it in there and see what happens...two of us have tested the system with no crashes so far... More info as it comes in... [2004-08-27 01:43:36] jochen dot daum at cabletalk dot co dot nz Hi, I have the same experience with mssql_select_db. I use PHP 4.3.2 as a module with FreeTDS. The mssql extension is patched though with a datetime extension that reads the milliseconds as well (as mentioned in some early bugs) The problem does not seem to occur with heavy load, but after a certain amount of mssql_select_db. According to the documentation: "In case a second call is made to mssql_connect() with the same arguments, no new link will be established, but instead, the link identifier of the already opened link will be returned." (mssql_connect) and "Every subsequent call to mssql_query() will be made on the active database." (mssql_select_db) I have modified my database access layer to call mssql_select_db() before each mssql_query(). After a number of mssql_select_db, I get an instant failure. Retrying helps for some more queries, but then the process hangs with Apache running at 100%. HTH, Jochen [2004-07-26 16:14:25] david dot blair at nsi1 dot com I should probably note that fmk and I have exchanged 2 emails outside of this bug report (just so it's part of this paper trail). He brought me up to speed on the thread safety issues of the dblib library. This next part can be taken with a grain of salt. I'm not sure if it's a seperate issue or something that will help fmk in debugging...I upgraded our development server to PHP 5. It's still showing the intermittent problems of the failed connection, but it's not happening at mssql_connect. It happens at mssql_select_db. The error that's returned is: Warning: mssql_select_db() [function.mssql-select-db]: Unable to select database: blah blah blah... I dunno fmk if you made a fix in the 5 version that's not present in the 4.3.7 version? Wondering if you created some magic code that fixes the mssql_connect issue that needs to be applied to the other mssql functions... DB [2004-07-12 23:58:22] david dot blair at nsi1 dot com Today at 4:22 the production server just informed me that it took 15 attempts to get a connection. Normally it's alot lower than this when mssql_connect fails...but on the 15th connect it caught. How am I doing this? for-loop until mssql_connect returns a connection. Since it instantaneously fails the user doesn't even know it occurs. Is this a good solution. No. Hence this bug report. What failover would there be in mssql to cause it to fail right away without even looking for the server? Should I have my error email send me any information? I'm not sure what function is out there that would report on the state of mssql. In fact I don't see any reporting functions...I really need someone that knows the workings of this module to work with me on this... [2004-07-09 19:51:39] david dot blair at nsi1 dot com We have mssql.max_procs set to 250. So what does that mean; processes? Is a process a single SQL connection? Or is it all events running through mssql? Would: mssql_connect(yada yada); mssql_close(y
#29074 [Com]: mssql_connect fails under heavy load
ID: 29074 Comment by: phpbugreport at workboy dot com Reported By: david dot blair at nsi1 dot com Status: Open Bug Type: MSSQL related Operating System: MS 2003 PHP Version: 4.3.7 New Comment: Upgrading seems to make things worse. I upgraded to freetds-0.62.4, php-4.3.9RC2 (4.3.8 has a compile issue with freetds-0.62.4 according to bug reports), and apache 1.3.31. Now in addition to mssql_connect failures I also get mssql_select_db failures for one of our busier databases. Could it be that php/freetds is getting too fast and giving up before a response is received from SQL 2000? Charles Bennigton Oddcast, Inc. Previous Comments: [2004-09-11 22:13:08] phpbugreport at workboy dot com We are currently running apache_1.3.28, freetds-0.61.2 and php-4.3.3 on linux 2.4.x kernels and experiencing the same problem connecting to a SQL 2000E SP3 database. Modifying our PHP db connection classes to immediately try mssql_connect again when it fails produces the desired results most of the time. However not always. I will be upgrading to the latest and greatest in the current major version for all of the components on the Linux side and testing more. I will post a follow up then. Charles Bennington Oddcast, Inc. [2004-08-31 16:13:34] david dot blair at nsi1 dot com I've never had Apache hang before but I'm also not running through TDS. I just tried upgrading the production server to 5.0.1 last night. I've been running 5.0.0 on the development server and 5.0.1 on my laptop for two weeks/one week with no problems. The database connection failed 6 times last night after we brought everything back up. After 2 more failures this morning I rolled everything back. Oh hell, I just remembered I left php_mssql.dll from the 5.0.1 build in the windows directory...I think I'm going to leave it in there and see what happens...two of us have tested the system with no crashes so far... More info as it comes in... [2004-08-27 01:43:36] jochen dot daum at cabletalk dot co dot nz Hi, I have the same experience with mssql_select_db. I use PHP 4.3.2 as a module with FreeTDS. The mssql extension is patched though with a datetime extension that reads the milliseconds as well (as mentioned in some early bugs) The problem does not seem to occur with heavy load, but after a certain amount of mssql_select_db. According to the documentation: "In case a second call is made to mssql_connect() with the same arguments, no new link will be established, but instead, the link identifier of the already opened link will be returned." (mssql_connect) and "Every subsequent call to mssql_query() will be made on the active database." (mssql_select_db) I have modified my database access layer to call mssql_select_db() before each mssql_query(). After a number of mssql_select_db, I get an instant failure. Retrying helps for some more queries, but then the process hangs with Apache running at 100%. HTH, Jochen [2004-07-26 16:14:25] david dot blair at nsi1 dot com I should probably note that fmk and I have exchanged 2 emails outside of this bug report (just so it's part of this paper trail). He brought me up to speed on the thread safety issues of the dblib library. This next part can be taken with a grain of salt. I'm not sure if it's a seperate issue or something that will help fmk in debugging...I upgraded our development server to PHP 5. It's still showing the intermittent problems of the failed connection, but it's not happening at mssql_connect. It happens at mssql_select_db. The error that's returned is: Warning: mssql_select_db() [function.mssql-select-db]: Unable to select database: blah blah blah... I dunno fmk if you made a fix in the 5 version that's not present in the 4.3.7 version? Wondering if you created some magic code that fixes the mssql_connect issue that needs to be applied to the other mssql functions... DB [2004-07-12 23:58:22] david dot blair at nsi1 dot com Today at 4:22 the production server just informed me that it took 15 attempts to get a connection. Normally it's alot lower than this when mssql_connect fails...but on the 15th connect it caught. How am I doing this? for-loop until mssql_connect returns a connection. Since it instantaneously fails the user doesn't even know it occurs. Is this a good solution. No. Hence this bug report. What failover would there be in mssql to cause it to fail right away without even looking for the server? Should I have my error email send me any information
#29074 [Com]: mssql_connect fails under heavy load
ID: 29074 Comment by: phpbugreport at workboy dot com Reported By: david dot blair at nsi1 dot com Status: Open Bug Type: MSSQL related Operating System: MS 2003 PHP Version: 4.3.7 New Comment: This bug should probably be closed. The problem is on the MSSQL end and ban be resolved by changing the value of the winsocklistenbacklog registry entry. For those who are experiencing this problem, please see http://support.microsoft.com/default.aspx?kbid=328476 I don't know why this also affects mssql_select_db, but they do appear to go together. Previous Comments: [2004-09-13 00:42:39] phpbugreport at workboy dot com Upgrading seems to make things worse. I upgraded to freetds-0.62.4, php-4.3.9RC2 (4.3.8 has a compile issue with freetds-0.62.4 according to bug reports), and apache 1.3.31. Now in addition to mssql_connect failures I also get mssql_select_db failures for one of our busier databases. Could it be that php/freetds is getting too fast and giving up before a response is received from SQL 2000? Charles Bennigton Oddcast, Inc. [2004-09-11 22:13:08] phpbugreport at workboy dot com We are currently running apache_1.3.28, freetds-0.61.2 and php-4.3.3 on linux 2.4.x kernels and experiencing the same problem connecting to a SQL 2000E SP3 database. Modifying our PHP db connection classes to immediately try mssql_connect again when it fails produces the desired results most of the time. However not always. I will be upgrading to the latest and greatest in the current major version for all of the components on the Linux side and testing more. I will post a follow up then. Charles Bennington Oddcast, Inc. [2004-08-31 16:13:34] david dot blair at nsi1 dot com I've never had Apache hang before but I'm also not running through TDS. I just tried upgrading the production server to 5.0.1 last night. I've been running 5.0.0 on the development server and 5.0.1 on my laptop for two weeks/one week with no problems. The database connection failed 6 times last night after we brought everything back up. After 2 more failures this morning I rolled everything back. Oh hell, I just remembered I left php_mssql.dll from the 5.0.1 build in the windows directory...I think I'm going to leave it in there and see what happens...two of us have tested the system with no crashes so far... More info as it comes in... [2004-08-27 01:43:36] jochen dot daum at cabletalk dot co dot nz Hi, I have the same experience with mssql_select_db. I use PHP 4.3.2 as a module with FreeTDS. The mssql extension is patched though with a datetime extension that reads the milliseconds as well (as mentioned in some early bugs) The problem does not seem to occur with heavy load, but after a certain amount of mssql_select_db. According to the documentation: "In case a second call is made to mssql_connect() with the same arguments, no new link will be established, but instead, the link identifier of the already opened link will be returned." (mssql_connect) and "Every subsequent call to mssql_query() will be made on the active database." (mssql_select_db) I have modified my database access layer to call mssql_select_db() before each mssql_query(). After a number of mssql_select_db, I get an instant failure. Retrying helps for some more queries, but then the process hangs with Apache running at 100%. HTH, Jochen [2004-07-26 16:14:25] david dot blair at nsi1 dot com I should probably note that fmk and I have exchanged 2 emails outside of this bug report (just so it's part of this paper trail). He brought me up to speed on the thread safety issues of the dblib library. This next part can be taken with a grain of salt. I'm not sure if it's a seperate issue or something that will help fmk in debugging...I upgraded our development server to PHP 5. It's still showing the intermittent problems of the failed connection, but it's not happening at mssql_connect. It happens at mssql_select_db. The error that's returned is: Warning: mssql_select_db() [function.mssql-select-db]: Unable to select database: blah blah blah... I dunno fmk if you made a fix in the 5 version that's not present in the 4.3.7 version? Wondering if you created some magic code that fixes the mssql_connect issue that needs to be applied to the other mssql functions... DB The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug
#29074 [Com]: mssql_connect fails under heavy load
ID: 29074 Comment by: phpbugreport at workboy dot com Reported By: david dot blair at nsi1 dot com Status: Open Bug Type: MSSQL related Operating System: MS 2003 PHP Version: 4.3.7 New Comment: If you have access to a packet sniffer and the basic knowhow, I would recommend sniffing the connection to and from port 1433 of your MSSQL server (if you are using 1433 that is) and the web server having the connect problems. I was able to determine that this problem was on the SQL side of things by looking at the packet trace. I would log mssql_connect failures that were corrected by a second attempt and matched their times exactly to TCP RESET packets being sent from the MSSQL server back to the web server requesting a connection to port 1433. This allowed me to rule out PHP as the source of the failure. As to why newer versions of PHP cause this more than older versions, all I can assume is that the newer PHP is more efficient in some way in opening TCP connections and this is causing greater concurrency in TCP connection requests to the SQL server. With a listen backlog of 25 on my SQL server I still see occasional failures but that is within an acceptable range now as they are handled by trying again immediately. If the number starts to go up, I will try increasing my listen backlog. I also observed that an entirely separate problem on my SQL server related to the RAID card increased the failure rate so there appear to be other mitigating factors on the SQL end. Fixing the RAID issue make the connect failures rate drop down to zero again. Charles Previous Comments: [2004-09-29 20:29:38] david dot blair at nsi1 dot com (In response to two posts ago) Charles, I tried your fix by setting the winsocklistenbacklog to 16. Didn't work. Had three more incidents today where the first connection was refused but on an instant reconnect it worked. [2004-09-22 07:37:08] pretenda at pretenda dot com I am also having the same problem. I have been searching high and low for an answer, but have found none. I ended up creating a loop in my PHP connect code too, and it has attempted to connect more than once, 27 times on my development server in the past week. I am running the following: Windows 2003 Server IIS6 PHP 5.01 SQL Server 2000 SP3 A also previously had the issue on 4.3.8, which didn't fail as often. Unfortunately I need some of the features of PHP5 on my new website. Cheers, Matt [2004-09-21 23:57:14] david dot blair at nsi1 dot com Charles, this doesn't explain why newer versions of PHP cause the error more frequently than older versions, when everything else about our systems remains the same. This also doesn't explain why PHP is the only thing having issues that contacts my SQL server. I'll try your work-around tomorrow and monitor the server for a few weeks to see what happens. It's a step in the right direction to finding a solution if it does help, but I still see it as a work-around, not a solution. ---- [2004-09-21 23:36:13] phpbugreport at workboy dot com This bug should probably be closed. The problem is on the MSSQL end and ban be resolved by changing the value of the winsocklistenbacklog registry entry. For those who are experiencing this problem, please see http://support.microsoft.com/default.aspx?kbid=328476 I don't know why this also affects mssql_select_db, but they do appear to go together. ---- [2004-09-13 00:42:39] phpbugreport at workboy dot com Upgrading seems to make things worse. I upgraded to freetds-0.62.4, php-4.3.9RC2 (4.3.8 has a compile issue with freetds-0.62.4 according to bug reports), and apache 1.3.31. Now in addition to mssql_connect failures I also get mssql_select_db failures for one of our busier databases. Could it be that php/freetds is getting too fast and giving up before a response is received from SQL 2000? Charles Bennigton Oddcast, Inc. 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/29074 -- Edit this bug report at http://bugs.php.net/?id=29074&edit=1
[PHP-BUG] Bug #65357 [NEW]: get_object_vars behavior changed unexpected after version upgrade from php 5.3
From: phpbugreport at darkaura dot de
Operating system:
PHP version: 5.4.17
Package: Reflection related
Bug Type: Bug
Bug description:get_object_vars behavior changed unexpected after version
upgrade from php 5.3
Description:
---
>From manual page: http://www.php.net/function.get-object-vars
---
get_object_vars exposes more than it should if you wrap it in a closure.
Not only $this but every variable pointing to the object the closure is in
is put
in a state where the prototected and private variables can be read.
Test script:
---
showMyPublicsOnly() //Outputs array('publicSetting' => 'public');
Actual result:
--
//PHP 5.3
$example->showMyPublicsOnly() //Outputs array('publicSetting' =>
'public');
//PHP 5.4 and up
$example->showMyPublicsOnly() //Outputs array('publicSetting' => 'public',
'protectedSetting' => 'protected', 'privateSetting' => 'private');
This change is not mentioned on the manual page.
--
Edit bug report at https://bugs.php.net/bug.php?id=65357&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65357&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65357&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65357&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65357&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65357&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65357&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65357&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65357&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65357&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65357&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65357&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65357&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65357&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65357&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65357&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65357&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65357&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65357&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65357&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65357&r=mysqlcfg
Bug #65357 [Opn]: get_object_vars behavior changed unexpected after version upgrade from php 5.3
Edit report at https://bugs.php.net/bug.php?id=65357&edit=1
ID: 65357
User updated by:phpbugreport at darkaura dot de
Reported by:phpbugreport at darkaura dot de
Summary:get_object_vars behavior changed unexpected after
version upgrade from php 5.3
Status: Open
Type: Bug
Package:Reflection related
PHP Version:5.4.17
Block user comment: N
Private report: N
New Comment:
in the example the line should be:
return $analyse($this);
Previous Comments:
[2013-07-30 09:40:34] phpbugreport at darkaura dot de
Description:
---
>From manual page: http://www.php.net/function.get-object-vars
---
get_object_vars exposes more than it should if you wrap it in a closure.
Not only $this but every variable pointing to the object the closure is in is
put
in a state where the prototected and private variables can be read.
Test script:
---
showMyPublicsOnly() //Outputs array('publicSetting' => 'public');
Actual result:
--
//PHP 5.3
$example->showMyPublicsOnly() //Outputs array('publicSetting' => 'public');
//PHP 5.4 and up
$example->showMyPublicsOnly() //Outputs array('publicSetting' => 'public',
'protectedSetting' => 'protected', 'privateSetting' => 'private');
This change is not mentioned on the manual page.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65357&edit=1
#47344 [NEW]: php variables and session variables may not have the same name
From: phpbugreport at growyouthful dot com Operating system: Apache 20051115 PHP version: 5.2.9RC1 PHP Bug Type: Session related Bug description: php variables and session variables may not have the same name Description: I wanted to carry the value of $newsletter from page to page. When I saved it as $_SESSION['newsletter']= $newsletter; and then got the value of the session variable later, it was not what was saved previously. It seemed to be empty or null. This bug may also have caused the page to hang, and numerous invocations of the script - my web stats showed that the script had been run several thousand times by me. However, an ob_flush() seemed to fix this problem of hanging. When I changed the session variable name to xnewsletter, it fixed the problem. Note: my php host is using php 5.2.6 and I do not have the option of asking them to change that Reproduce code: --- session_start(); $_SESSION['newsletter']= $newsletter; ...later... session_start(); $newsletter=$_SESSION['newsletter']; Expected result: see Description -- Edit bug report at http://bugs.php.net/?id=47344&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47344&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47344&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47344&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47344&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47344&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47344&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47344&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47344&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47344&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47344&r=support Expected behavior: http://bugs.php.net/fix.php?id=47344&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47344&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47344&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47344&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47344&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47344&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47344&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47344&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47344&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47344&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47344&r=mysqlcfg
#28285 [Com]: php_mysql.dll unclear on module installation
ID: 28285 Comment by: phpbugreport at southportnews dot com Reported By: pburden98 at yahoo dot com Status: No Feedback Bug Type: *Configuration Issues Operating System: windows 98 2nd Edition PHP Version: 5.0.0RC2 New Comment: On windows 2000 , This bug started happening for me "PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\PHP\\ext\\php_mysql.dll' - The specified module could not be found.\r\n in Unknown on line 0" Turned out that I needed my 'User variables' Path to include 'C:/php' rather than the 'System Variables' section of the Environment variables. I'd installed something that screwed up my paths. Previous Comments: [2007-03-25 18:52:19] _saber_ at mail dot ru hi error on start apache2 log.. PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\php5\\php_mysql.dll' - \xcd\xe5 \xed\xe0\xe9\xe4\xe5\xed \xf3\xea\xe0\xe7\xe0\xed\xed\xfb\xe9 \xec\xee\xe4\xf3\xeb\xfc.\r\n in Unknown on line 0 [Mon Mar 26 02:49:07 2007] [notice] Apache/2.0.59 (Win32) PHP/5.1.2 configured -- resuming normal operations [Mon Mar 26 02:49:07 2007] [notice] Server built: Jul 27 2006 15:55:03 [Mon Mar 26 02:49:07 2007] [notice] Parent: Created child process 2360 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\php5\\php_mysql.dll' - \xcd\xe5 \xed\xe0\xe9\xe4\xe5\xed \xf3\xea\xe0\xe7\xe0\xed\xed\xfb\xe9 \xec\xee\xe4\xf3\xeb\xfc.\r\n in Unknown on line 0 [Mon Mar 26 02:49:07 2007] [notice] Child 2360: Child process is running [Mon Mar 26 02:49:07 2007] [notice] Child 2360: Acquired the start mutex. [Mon Mar 26 02:49:07 2007] [notice] Child 2360: Starting 250 worker threads. [2007-02-08 02:26:48] sprite at zatokapucka dot pl I've expierienced the same problem with PHP 5.0.5 and 5.2.0 on Windows XP and Apache 2.0.48. I'be installed recently some programming stuff (Delphi 2005, .NET SDK and some other) and after restart I've got warnings: PHP Warning: PHP Startup: Unable to load dynamic library 'c:\\Program Files\\php\\ext\\php_mysql.dll' - Nie mo\xbfna odnale\x9f\xe6 okre\x9clonego modu\xb3u.\r\n in Unknown on line 0 Copy libmysql.dll to Apache's bin directory solved the problem for me too. Thanks for your comments! [2006-08-26 15:22:50] charles dot wicksteed at lycos dot com I have reproduced this problem with Windows 98, and have some more information to put into the documentation. In the Apache error log: PHP Warning: PHP Startup: Unable to load dynamic library 'd:\\php\\ext\\php_mysql.dll' - A device attached to the system is not functioning.\r\n in Unknown on line 0 Environment: Apache/2.0.54 (Win32) PHP/5.1.6 Windows 98 (4.10.1998) I followed all the instructions about setting my PATH (C:\WINDOWS;C:\WINDOWS\COMMAND;D:\PHP). Command line PHP loads the MySQL extension OK (comes up in phpinfo). It works if I copy libmysql.dll to Apache's bin directory, so that is my chosen workround. It looks as though this version of Windows does not use the PATH for DLLs, but looks in the directory where the original executable (apache.exe) lives. I expect it would have worked if I had copied the DLL to the central DLL location, which is C:\WINDOWS\SYSTEM on Windows 98, but I don't want to do that. This is a documentation problem, affecting Windows 98 users. [2004-05-21 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-13 19:29:13] [EMAIL PROTECTED] Please try these simplified instructions (and don't copy any files anywhere except for php.ini). 1. Unpack snap to say c:\php 2. Make sure c:\php is in your system path 3. Adjust apache config accordingly (load c:\php\php5apache.dll directly) This should work. Please remember to remove any remains of old php installs. 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/28285 -- Edit this bug report at http://bugs.php.net/?id=28285&edit=1
#36011 [NEW]: Strict errormsg wrong for call_user_func() and the likes
From: phpbugreport at elexer dot com Operating system: * PHP version: 5CVS-2006-01-14 (snap) PHP Bug Type: Class/Object related Bug description: Strict errormsg wrong for call_user_func() and the likes Description: With error_reporting(E_ALL | E_STRICT) and usage of call_user_func(), array_map() on a static function returns "Strict Standards: Non-static method TestClass::test() cannot be called statically, assuming $this from compatible context TestClass" while the called method is static. Reproduce code: --- whee(); $a->whee4(); $a->whee5(); TestClass::whee5(); Expected result: No strict warnings Actual result: -- Strict Standards: Non-static method TestClass::test() cannot be called statically, assuming $this from compatible context TestClass in test2.php on line 11 test() called -- Edit bug report at http://bugs.php.net/?id=36011&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36011&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36011&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36011&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36011&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36011&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36011&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36011&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36011&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36011&r=support Expected behavior:http://bugs.php.net/fix.php?id=36011&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36011&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36011&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36011&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36011&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36011&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36011&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36011&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36011&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36011&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36011&r=mysqlcfg
#34064 [NEW]: arr[] as param to function in class gives invalid opcode
From: phpbugreport at elexer dot com Operating system: WinXP PHP version: 5CVS-2005-08-10 (dev) PHP Bug Type: Scripting Engine problem Bug description: arr[] as param to function in class gives invalid opcode Description: PHP 5.1.0-dev (cli) (built: Aug 9 2005 00:41:59) from http://snaps.php.net - compiling below code generates an Invalid opcode error. Works fine when you take the "test()" function out of the class. Reproduce code: --- test($ar[]); } } $o = new XmlTest(); $o->run(); ?> Expected result: No "Invalid opcode" error Actual result: -- Fatal error: Invalid opcode 93/16/8. in D:\php5\a.php on line 14 -- Edit bug report at http://bugs.php.net/?id=34064&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34064&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34064&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34064&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34064&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34064&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34064&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34064&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34064&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34064&r=support Expected behavior: http://bugs.php.net/fix.php?id=34064&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34064&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34064&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34064&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34064&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34064&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34064&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34064&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34064&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34064&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34064&r=mysqlcfg
#22371 [NEW]: ereg_replace moving ! to start of string
From: phpbugreport at webfroot dot co dot nz
Operating system: Windows XP
PHP version: 4.3.0
PHP Bug Type: Regexps related
Bug description: ereg_replace moving ! to start of string
Running Apache 1.3 as a service on Windows XP
$text = ereg_replace ("]+href *= *([^ ]+)[^>]*>", "",
$text);
The above line of code is supposed to find all a tags and strip any
attributes except href. However:
$text = "bacon hello";
will be set to:
bacon !hello
How in the hell did that exclaim get to the start of the a tag? Maybe I'm
just doing something wrong, but it looks like a bug to me.
--
Edit bug report at http://bugs.php.net/?id=22371&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22371&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22371&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22371&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22371&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22371&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22371&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22371&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22371&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22371&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22371&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22371&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22371&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22371&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22371&r=gnused
