#21527 [NEW]: undefined symbols not allowed
From: [EMAIL PROTECTED] Operating system: CygWin/WinXP PHP version: 4.3.0 PHP Bug Type: Sybase (dblib) related Bug description: undefined symbols not allowed Hi, I tried compiling PHP 4.3.0 under CygWin/Windows XP with the following options --disable-cgi --disable-cli --with-apxs=/usr/sbin/apxs --with-mysql --with-sybase=/usr/local/freetds and I got this during make: ** *** Warning: This library needs some functionality provided by /usr/local/freetd s/lib/libsybdb.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Therefore, libtool will create a static module, that should work *** as long as the dlopening application is linked with the -dlopen flag. libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries ** In this case, I have already successfully installed FreeTDS in /usr/local/freetds However, make did not give any errors (except for the above warning) so I tried to "make install" but I got the following: $ make install Installing PHP SAPI module apxs:Error: file libs/libphp4.so is not a DSO make: *** [install-sapi] Error 1 Anything wrong with what I'm doing? httpd -l returns mod_so under its list. Thanks in advance. Mike Lopez -- Edit bug report at http://bugs.php.net/?id=21527&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21527&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21527&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21527&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21527&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21527&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21527&r=support Expected behavior: http://bugs.php.net/fix.php?id=21527&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21527&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21527&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21527&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21527&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21527&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21527&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21527&r=gnused
#21527 [Bgs]: undefined symbols not allowed
ID: 21527 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Sybase (dblib) related Operating System: CygWin/WinXP PHP Version: 4.3.0 New Comment: Rather than compiling a shared version of tds, what I did was remove the option for sybase just to see if libphp4.so will be created. So now configure is as follows: ./configure --disable-cgi --disable-cli --disable-xml --with-apxs=/usr/sbin/apxs --with-mysql Sad to say during make install it still gave me: Installing PHP SAPI module apxs:Error: file libs/libphp4.so is not a DSO make: *** [install-sapi] Error 1 I checked the libs folder and did not find libphp4.so there. The only files there are: libphp4.a libphp4.la Any other idea? Please. I need to get this working. :-) Previous Comments: [2003-01-08 17:51:50] [EMAIL PROTECTED] Just read the warning..and do what it says: compile a shared version of the freetds libs. [2003-01-08 14:30:55] [EMAIL PROTECTED] Hi, I tried compiling PHP 4.3.0 under CygWin/Windows XP with the following options --disable-cgi --disable-cli --with-apxs=/usr/sbin/apxs --with-mysql --with-sybase=/usr/local/freetds and I got this during make: ** *** Warning: This library needs some functionality provided by /usr/local/freetd s/lib/libsybdb.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Therefore, libtool will create a static module, that should work *** as long as the dlopening application is linked with the -dlopen flag. libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries ** In this case, I have already successfully installed FreeTDS in /usr/local/freetds However, make did not give any errors (except for the above warning) so I tried to "make install" but I got the following: $ make install Installing PHP SAPI module apxs:Error: file libs/libphp4.so is not a DSO make: *** [install-sapi] Error 1 Anything wrong with what I'm doing? httpd -l returns mod_so under its list. Thanks in advance. Mike Lopez -- Edit this bug report at http://bugs.php.net/?id=21527&edit=1
#21450 [Com]: File Posts from Microsoft Web Publishing Wizard don't work.
ID: 21450 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Feature/Change Request Operating System: Windows 2000 Pro PHP Version: 4CVS-2003-01-05 (dev) Assigned To: sesser New Comment: Thanks. Works fine now :-) Previous Comments: [2003-01-07 03:48:00] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-01-06 02:15:56] [EMAIL PROTECTED] Content-disposition: form-data; filename="etc\root.hint" This line of the rfc1867 fileupload lacks a name="whatever" attribute. PHP cannot handle anonymous fileuploads for now... (I will implement that) [2003-01-05 22:29:03] [EMAIL PROTECTED] Here is a capture of a complete request made by WPW: POST /temp/fb.php HTTP/1.1 Accept: */* Content-Type: Multipart/Form-Data,boundary=19359@23195#13275 User-Agent: Microsoft HTTP Post (RFC1867) Host: 10.0.0.7 Connection: Keep-Alive Cache-Control: no-cache Content-Length: 3002 --19359@23195#13275 Content-disposition: form-data; filename="etc\root.hint" Content-type: application/octet-stream ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . " ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC registration services ; under anonymous FTP as ; file/domain/named.root ; on server FTP.RS.INTERNIC.NET ; -OR- under Gopher atRS.INTERNIC.NET ; under menu InterNIC Registration Services (NSI) ; submenu InterNIC Registration Archives ; filenamed.root ; ; last update:Aug 22, 1997 ; related version of root zone: 1997082200 ; ; ; formerly NS.INTERNIC.NET ; .360 IN NSA.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 360 A 198.41.0.4 ; ; formerly NS1.ISI.EDU ; .360 NSB.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 360 A 128.9.0.107 ; ; formerly C.PSI.NET ; .360 NSC.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 360 A 192.33.4.12 ; ; formerly TERP.UMD.EDU ; .360 NSD.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 360 A 128.8.10.90 ; ; formerly NS.NASA.GOV ; .360 NSE.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 360 A 192.203.230.10 ; ; formerly NS.ISC.ORG ; .360 NSF.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 360 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL ; .360 NSG.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 360 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL ; .360 NSH.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 360 A 128.63.2.53 ; ; formerly NIC.NORDU.NET ; .360 NSI.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 360 A 192.36.148.17 ; ; temporarily housed at NSI (InterNIC) ; .360 NSJ.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 360 A 198.41.0.10 ; ; housed in LINX, operated by RIPE NCC ; .360 NSK.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 360 A 193.0.14.129 ; ; temporarily housed at ISI (IANA) ; .360 NSL.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 360 A 198.32.64.12 ; ; housed in Japan, operated by WIDE ; .360 NSM.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 360 A 202.12.27.33 ; End of File --19359@23195#13275-- [2003-01-05 21:47:40] [EMAIL PROTECTED] When using microsoft web publishing wizard to post files to a php script $_FILES is always empty. Logged in my php error log is: [06-Jan-2003 16:46:49] PHP Warning: File Upload Mime headers garbled
#21450 [Com]: File Posts from Microsoft Web Publishing Wizard don't work.
ID: 21450 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Feature/Change Request Operating System: Windows 2000 Pro PHP Version: 4CVS-2003-01-05 (dev) Assigned To: sesser New Comment: Is there any chance of mergeing this one into 4.3? Thanks - Mike :-) Previous Comments: [2003-01-07 05:26:35] [EMAIL PROTECTED] Thanks. Works fine now :-) [2003-01-07 03:48:00] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-01-06 02:15:56] [EMAIL PROTECTED] Content-disposition: form-data; filename="etc\root.hint" This line of the rfc1867 fileupload lacks a name="whatever" attribute. PHP cannot handle anonymous fileuploads for now... (I will implement that) [2003-01-05 22:29:03] [EMAIL PROTECTED] Here is a capture of a complete request made by WPW: POST /temp/fb.php HTTP/1.1 Accept: */* Content-Type: Multipart/Form-Data,boundary=19359@23195#13275 User-Agent: Microsoft HTTP Post (RFC1867) Host: 10.0.0.7 Connection: Keep-Alive Cache-Control: no-cache Content-Length: 3002 --19359@23195#13275 Content-disposition: form-data; filename="etc\root.hint" Content-type: application/octet-stream ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . " ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC registration services ; under anonymous FTP as ; file/domain/named.root ; on server FTP.RS.INTERNIC.NET ; -OR- under Gopher atRS.INTERNIC.NET ; under menu InterNIC Registration Services (NSI) ; submenu InterNIC Registration Archives ; filenamed.root ; ; last update:Aug 22, 1997 ; related version of root zone: 1997082200 ; ; ; formerly NS.INTERNIC.NET ; .360 IN NSA.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 360 A 198.41.0.4 ; ; formerly NS1.ISI.EDU ; .360 NSB.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 360 A 128.9.0.107 ; ; formerly C.PSI.NET ; .360 NSC.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 360 A 192.33.4.12 ; ; formerly TERP.UMD.EDU ; .360 NSD.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 360 A 128.8.10.90 ; ; formerly NS.NASA.GOV ; .360 NSE.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 360 A 192.203.230.10 ; ; formerly NS.ISC.ORG ; .360 NSF.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 360 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL ; .360 NSG.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 360 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL ; .360 NSH.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 360 A 128.63.2.53 ; ; formerly NIC.NORDU.NET ; .360 NSI.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 360 A 192.36.148.17 ; ; temporarily housed at NSI (InterNIC) ; .360 NSJ.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 360 A 198.41.0.10 ; ; housed in LINX, operated by RIPE NCC ; .360 NSK.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 360 A 193.0.14.129 ; ; temporarily housed at ISI (IANA) ; .360 NSL.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 360 A 198.32.64.12 ; ; housed in Japan, operated by WIDE ; .360 NSM.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 360 A 202.12.27.33 ; End of File --19359@23195#13275-- [2003
#14255 [Com]: setcookie bug (Cookie is destroyed/Inaccessible)
ID: 14255 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: HTTP related Operating System: Debian 2.2.19 PHP Version: 4.0.6 Assigned To: shiflett New Comment: I have a PHP script that sets a cookie as follows: $cookie_expire = time()+3600; $cookie_name= "loginpipoclub"; $value= "mike"; setcookie ($cookie_name, $value, $cookie_expire); THis IS NOT WORKING anymore (I swear it did work !). So I have finally tried to find out why the cookie is not being set by using Telnet. The response I get in the header shows that the cookie is expired, but I cannot understand WHY!!! THE server time shows the correct time/date according to my system and my watch BUT THE COOKIE IS MARKED AS DELETED (SEE SetCookie: header below) despite the fact that I have set it to expire at time() + 3600. In fact, the expiry date is marked to be last year. HERE IS THE RESPONSE FROM THE SERVER USING TELNET ON PORT 80: HTTP/1.1 200 OK Date: Wed, 05 Feb 2003 19:40:29 GMT Server: Apache/1.3.22 (Unix) mod_ssl/2.8.5 OpenSSL/0.9.6a PHP/4.0.6 mod_perl/1.0 X-Powered-By: PHP/4.0.6 Set-Cookie: loginpipoclub=deleted; expires=Tue, 05-Feb-02 19:40:39 GMT; path=/;m Transfer-Encoding: chunked Content-Type: text/html PLEASE, CAN ANYONE SHED SOME LIGHT ON THIS. I have been looking all over the internet on various forums BUT i cannot get a solution to the problem, I am using PHP/MYSQL on a unix system in the US, which i am accessing from telnet in spain. My browser is Internet Explorer 6.0.128 (initially i thought it was a browser issue since I had this working on other browsers, but the telnet proof shows that it is not a browser issue, the cookie has in fact been marked as DELETED!!!!). regards Mike Ferrer Previous Comments: [2002-03-07 00:00:05] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, 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". [2002-02-06 14:00:02] [EMAIL PROTECTED] I'm changing the category to HTTP and status to feedback. I do not think this is a bug but want to give the submitter time to respond to my inquiry. [2002-02-06 12:33:40] [EMAIL PROTECTED] Is this even a bug? It's under documentation problem. Do I need to change something in the documentation? [2002-02-03 22:47:01] [EMAIL PROTECTED] A couple of comments. Kris, in regards to your comment on NOV-27-2001 at 1:48PM, that code will fail because you cannot set a cookie and give a Location header in the same HTTP response. Well, you *can*, but your cookie will not be set. Since the server would not be able to identify the client without the cookie, you get the unexpected behavior. This is a protocol-level situation, but is generally *not* considered a bug in HTTP (in case you got the feeling I was supporting that idea). Basically, PHP gives you the freedom to specify your own headers in the HTTP response, but you need to have a clear grasp of what they do to use them. So, if this example was a clear illustration of the problem you've been having, it's not a bug in PHP. You can spread that around to others who are having the same problems. Also, in regards to the time/date discussion, it is correct to say that the browser uses the client time (obviously) to determine whether to send a cookie along with subsequent HTTP requests. It is also correct to say that the setcookie function uses the server time to set the expiration date. However, since both are in GMT as [EMAIL PROTECTED] explained (sorry, I don't know your name), this only matters if both clocks are considerably out of sync or if the expiration time of the cookie is extremely small. If this is a concern, consider using client-side scripting to set the cookie, so that the browser itself creates the cookie based on its own time. You can create the client-side script itself using PHP, so that the cookie's value can still be dynamically generated by your PHP scripts. Hope that clears a few things up. If this didn't solve your problem,
#14255 [Com]: setcookie bug (Cookie is destroyed/Inaccessible)
ID: 14255 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: HTTP related Operating System: Debian 2.2.19 PHP Version: 4.0.6 Assigned To: shiflett New Comment: Oh, I forgot to mention IN THE PREVIOUS POSTING, MY SETUP IS AS FOLLOWS: PHP/4.0.6 APACHE 1.3.22 (Unix) Previous Comments: [2003-02-05 13:44:51] [EMAIL PROTECTED] I have a PHP script that sets a cookie as follows: $cookie_expire = time()+3600; $cookie_name= "loginpipoclub"; $value= "mike"; setcookie ($cookie_name, $value, $cookie_expire); THis IS NOT WORKING anymore (I swear it did work !). So I have finally tried to find out why the cookie is not being set by using Telnet. The response I get in the header shows that the cookie is expired, but I cannot understand WHY!!! THE server time shows the correct time/date according to my system and my watch BUT THE COOKIE IS MARKED AS DELETED (SEE SetCookie: header below) despite the fact that I have set it to expire at time() + 3600. In fact, the expiry date is marked to be last year. HERE IS THE RESPONSE FROM THE SERVER USING TELNET ON PORT 80: HTTP/1.1 200 OK Date: Wed, 05 Feb 2003 19:40:29 GMT Server: Apache/1.3.22 (Unix) mod_ssl/2.8.5 OpenSSL/0.9.6a PHP/4.0.6 mod_perl/1.0 X-Powered-By: PHP/4.0.6 Set-Cookie: loginpipoclub=deleted; expires=Tue, 05-Feb-02 19:40:39 GMT; path=/;m Transfer-Encoding: chunked Content-Type: text/html PLEASE, CAN ANYONE SHED SOME LIGHT ON THIS. I have been looking all over the internet on various forums BUT i cannot get a solution to the problem, I am using PHP/MYSQL on a unix system in the US, which i am accessing from telnet in spain. My browser is Internet Explorer 6.0.128 (initially i thought it was a browser issue since I had this working on other browsers, but the telnet proof shows that it is not a browser issue, the cookie has in fact been marked as DELETED!!!!). regards Mike Ferrer [2002-03-07 00:00:05] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, 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". [2002-02-06 14:00:02] [EMAIL PROTECTED] I'm changing the category to HTTP and status to feedback. I do not think this is a bug but want to give the submitter time to respond to my inquiry. [2002-02-06 12:33:40] [EMAIL PROTECTED] Is this even a bug? It's under documentation problem. Do I need to change something in the documentation? [2002-02-03 22:47:01] [EMAIL PROTECTED] A couple of comments. Kris, in regards to your comment on NOV-27-2001 at 1:48PM, that code will fail because you cannot set a cookie and give a Location header in the same HTTP response. Well, you *can*, but your cookie will not be set. Since the server would not be able to identify the client without the cookie, you get the unexpected behavior. This is a protocol-level situation, but is generally *not* considered a bug in HTTP (in case you got the feeling I was supporting that idea). Basically, PHP gives you the freedom to specify your own headers in the HTTP response, but you need to have a clear grasp of what they do to use them. So, if this example was a clear illustration of the problem you've been having, it's not a bug in PHP. You can spread that around to others who are having the same problems. Also, in regards to the time/date discussion, it is correct to say that the browser uses the client time (obviously) to determine whether to send a cookie along with subsequent HTTP requests. It is also correct to say that the setcookie function uses the server time to set the expiration date. However, since both are in GMT as [EMAIL PROTECTED] explained (sorry, I don't know your name), this only matters if both clocks are considerably out of sync or if the expiration time of the cookie is extremely small. If this is a concern, consider using client-side scripting to set the cookie, so that the browser itself creates the cookie based on its own time.
#14255 [Com]: setcookie bug (Cookie is destroyed/Inaccessible)
ID: 14255 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: HTTP related Operating System: Debian 2.2.19 PHP Version: 4.0.6 Assigned To: shiflett New Comment: Oh, I forgot to mention IN THE PREVIOUS POSTING, MY SETUP IS AS FOLLOWS: PHP/4.0.6 APACHE 1.3.22 (Unix) Previous Comments: [2003-02-05 13:50:17] [EMAIL PROTECTED] Oh, I forgot to mention IN THE PREVIOUS POSTING, MY SETUP IS AS FOLLOWS: PHP/4.0.6 APACHE 1.3.22 (Unix) [2003-02-05 13:44:51] [EMAIL PROTECTED] I have a PHP script that sets a cookie as follows: $cookie_expire = time()+3600; $cookie_name= "loginpipoclub"; $value= "mike"; setcookie ($cookie_name, $value, $cookie_expire); THis IS NOT WORKING anymore (I swear it did work !). So I have finally tried to find out why the cookie is not being set by using Telnet. The response I get in the header shows that the cookie is expired, but I cannot understand WHY!!! THE server time shows the correct time/date according to my system and my watch BUT THE COOKIE IS MARKED AS DELETED (SEE SetCookie: header below) despite the fact that I have set it to expire at time() + 3600. In fact, the expiry date is marked to be last year. HERE IS THE RESPONSE FROM THE SERVER USING TELNET ON PORT 80: HTTP/1.1 200 OK Date: Wed, 05 Feb 2003 19:40:29 GMT Server: Apache/1.3.22 (Unix) mod_ssl/2.8.5 OpenSSL/0.9.6a PHP/4.0.6 mod_perl/1.0 X-Powered-By: PHP/4.0.6 Set-Cookie: loginpipoclub=deleted; expires=Tue, 05-Feb-02 19:40:39 GMT; path=/;m Transfer-Encoding: chunked Content-Type: text/html PLEASE, CAN ANYONE SHED SOME LIGHT ON THIS. I have been looking all over the internet on various forums BUT i cannot get a solution to the problem, I am using PHP/MYSQL on a unix system in the US, which i am accessing from telnet in spain. My browser is Internet Explorer 6.0.128 (initially i thought it was a browser issue since I had this working on other browsers, but the telnet proof shows that it is not a browser issue, the cookie has in fact been marked as DELETED!!!!). regards Mike Ferrer [2002-03-07 00:00:05] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, 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". [2002-02-06 14:00:02] [EMAIL PROTECTED] I'm changing the category to HTTP and status to feedback. I do not think this is a bug but want to give the submitter time to respond to my inquiry. [2002-02-06 12:33:40] [EMAIL PROTECTED] Is this even a bug? It's under documentation problem. Do I need to change something in the documentation? 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/14255 -- Edit this bug report at http://bugs.php.net/?id=14255&edit=1
#17991 [Com]: getlastmod() does not function with apache2filter SAPI
ID: 17991 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache2 related Operating System: Confirmed on Solaris & Linux PHP Version: 4.2.1 New Comment: I'm using Apache2 + php4.2.3 and getlastmod still doesn't work (14th November 2002). Noticed that some of the php doc pages also have this problem (they show 1/1/70 as lastmod). I'm using filemtime instead which works fine. Previous Comments: [2002-09-13 09:30:27] [EMAIL PROTECTED] In version 4.2.3 as well as in the latest snapshot, getlastmod() still appears not to be functional with apache2filter sapi (always returns false). [2002-06-26 06:59:30] [EMAIL PROTECTED] This is fixed in CVS< can you please try the latest non-stable snapshot from snaps.php.net? Derick [2002-06-26 06:57:40] [EMAIL PROTECTED] getlastmod() and possibly other get_stat interfaces to not appear to be functional with apache2filter sapi. -- Edit this bug report at http://bugs.php.net/?id=17991&edit=1
#21181 [NEW]: MySQL extension is failing to compile on snaps.php.net
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4CVS-2002-12-25 (stable) PHP Bug Type: Compile Failure Bug description: MySQL extension is failing to compile on snaps.php.net The MySQL extension is failing to compile on snaps.php.net for all branchs. Wed Dec 25 10:00:01 2002 CET Starting snapshot 200212250930 -r PHP_4_3 branch, appending -STABLE to the filename >From Stable compile.log Configuration: mysql - Win32 Release_TS Compiling... php_mysql.c c:\php4build\snap\ext\mysql\php_mysql.c(32) : fatal error C1083: Cannot open include file: 'php.h': No such file or directory Error executing cl.exe. php_mysql.dll - 1 error(s), 0 warning(s) -- Edit bug report at http://bugs.php.net/?id=21181&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21181&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21181&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21181&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21181&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21181&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21181&r=support Expected behavior: http://bugs.php.net/fix.php?id=21181&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21181&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21181&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21181&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21181&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21181&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21181&r=isapi
#11468 [Com]: Cannot execute stored procedures
ID: 11468 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: InterBase related Operating System: Win32, Linux PHP Version: 4.0.5 New Comment: This feature is still missing in PHP 4.3.0. Patch is available and working (I am using it for more than one year by now). Is there a reason why this should not be implemented? Previous Comments: [2002-08-13 23:49:58] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. [2002-02-13 12:12:47] [EMAIL PROTECTED] Stored procedures may be executed, but if stored procedure return some data, I don't want how to get it. Yes some way is by select SQL command and SUSPEND in procedure, but it is not ideal way. May someone tell me how do it? [2001-06-13 12:25:03] [EMAIL PROTECTED] Hello, when I wrote some scripts that inserting some data to database, I must call stored procedures for getting some data (typically id from generator). I want execute stored procedures, that return next row id. I add some code to interbase PHP module, that support execution of stored procedures. With my patch, procedure is executed by $res = ibase_query($db, "execute procedure procedure_name"); $row = ibase_fetch_row($res); In $row is row returned by procedure. Patch may be found on http://www.penguin.cz/~michlv/software/phpibase/ If any question write me. Vladimir Michl <[EMAIL PROTECTED]> PS: Patch is ported from 4.0.3pl1 where is functional. -- Edit this bug report at http://bugs.php.net/?id=11468&edit=1
#21450 [NEW]: File Posts from Microsoft Web Publishing Wizard don't work.
From: [EMAIL PROTECTED]
Operating system: Windows 2000 Pro
PHP version: 4CVS-2003-01-05 (dev)
PHP Bug Type: Unknown/Other Function
Bug description: File Posts from Microsoft Web Publishing Wizard don't work.
When using microsoft web publishing wizard to post files to a php script
$_FILES is always empty. Logged in my php error log is:
[06-Jan-2003 16:46:49] PHP Warning: File Upload Mime headers garbled in
Unknown on line 0
It is able to reteive some of the post values but not the files. Is this
really a Microsoft RFC compliance problem or a PHP problem?
Using the following script:
$value) {
fwrite($fp, "$header: $value\n");
}
fclose($fp);
echo $content;
I set WPW to HTTP Post files to the URL of this script and the files are
never available. A common entry in fb.log looks like this:
New Hit
**
$_SERVER:
array (
'COMSPEC' => 'C:WINNTsystem32cmd.exe',
'CONTENT_LENGTH' => '189',
'CONTENT_TYPE' => 'Multipart/Form-Data,boundary=23264@18686#20663',
'DOCUMENT_ROOT' => 'i:/httpd/www.graftonhall.co.nz/htdocs',
'HTTP_ACCEPT' => '*/*',
'HTTP_CACHE_CONTROL' => 'no-cache',
'HTTP_CONNECTION' => 'Keep-Alive',
'HTTP_HOST' => 'www.graftonhall.co.nz',
'HTTP_USER_AGENT' => 'Microsoft HTTP Post (RFC1867)',
'PATH' => 'C:Program Filessapdbwebpgm;C:Program
Filessapdbindep_progpgm;C:Program
Filessapdbindep_progbin;C:Program
Filessapdbindep_progpgm;C:Program
FilesNetworkSimplicityssh;C:WINNTsystem32;C:WINNT;C:WINNTSystem32Wbem;C:Program
FilesJ2SDKbin',
'REMOTE_ADDR' => '10.0.0.4',
'REMOTE_PORT' => '1231',
'SCRIPT_FILENAME' =>
'i:/httpd/www.graftonhall.co.nz/htdocs/temp/fb.php',
'SERVER_ADDR' => '10.0.0.4',
'SERVER_ADMIN' => '[EMAIL PROTECTED]',
'SERVER_NAME' => 'www.graftonhall.co.nz',
'SERVER_PORT' => '80',
'SERVER_SIGNATURE' => 'Apache/1.3.26 Server at
www.graftonhall.co.nz Port 80
',
'SERVER_SOFTWARE' => 'Apache/1.3.26 (Win32) PHP/4.4.0-dev',
'SystemRoot' => 'C:WINNT',
'WINDIR' => 'C:WINNT',
'GATEWAY_INTERFACE' => 'CGI/1.1',
'SERVER_PROTOCOL' => 'HTTP/1.1',
'REQUEST_METHOD' => 'POST',
'QUERY_STRING' => '',
'REQUEST_URI' => '/temp/fb.php',
'SCRIPT_NAME' => '/temp/fb.php',
'PATH_TRANSLATED' =>
'i:/httpd/www.graftonhall.co.nz/htdocs/temp/fb.php',
'PHP_SELF' => '/temp/fb.php',
'argv' =>
array (
),
'argc' => 0,
)
$_REQUEST:
array (
'TargetURL' => 'http://www.graftonhall.co.nz/temp/fb.php',
)
$_FILES:
array (
)
$_GET:
array (
)
$_POST:
array (
'TargetURL' => 'http://www.graftonhall.co.nz/temp/fb.php',
)
Request:
Accept: */*
Cache-Control: no-cache
Connection: Keep-Alive
Content-Length: 189
Content-Type: Multipart/Form-Data,boundary=23264@18686#20663
Host: www.graftonhall.co.nz
User-Agent: Microsoft HTTP Post (RFC1867)
--
Edit bug report at http://bugs.php.net/?id=21450&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21450&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21450&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21450&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21450&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21450&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21450&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21450&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21450&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21450&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21450&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21450&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21450&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21450&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21450&r=gnused
#21450 [Com]: File Posts from Microsoft Web Publishing Wizard don't work.
ID: 21450
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Unknown/Other Function
Operating System: Windows 2000 Pro
PHP Version: 4CVS-2003-01-05 (dev)
New Comment:
Here is a capture of a complete request made by WPW:
POST /temp/fb.php HTTP/1.1
Accept: */*
Content-Type: Multipart/Form-Data,boundary=19359@23195#13275
User-Agent: Microsoft HTTP Post (RFC1867)
Host: 10.0.0.7
Connection: Keep-Alive
Cache-Control: no-cache
Content-Length: 3002
--19359@23195#13275
Content-disposition: form-data; filename="etc\root.hint"
Content-type: application/octet-stream
; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . "
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC registration services
; under anonymous FTP as
; file/domain/named.root
; on server FTP.RS.INTERNIC.NET
; -OR- under Gopher atRS.INTERNIC.NET
; under menu InterNIC Registration Services (NSI)
; submenu InterNIC Registration Archives
; filenamed.root
;
; last update:Aug 22, 1997
; related version of root zone: 1997082200
;
;
; formerly NS.INTERNIC.NET
;
.360 IN NSA.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 360 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
.360 NSB.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 360 A 128.9.0.107
;
; formerly C.PSI.NET
;
.360 NSC.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 360 A 192.33.4.12
;
; formerly TERP.UMD.EDU
;
.360 NSD.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 360 A 128.8.10.90
;
; formerly NS.NASA.GOV
;
.360 NSE.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 360 A 192.203.230.10
;
; formerly NS.ISC.ORG
;
.360 NSF.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 360 A 192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
.360 NSG.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 360 A 192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
.360 NSH.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 360 A 128.63.2.53
;
; formerly NIC.NORDU.NET
;
.360 NSI.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 360 A 192.36.148.17
;
; temporarily housed at NSI (InterNIC)
;
.360 NSJ.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 360 A 198.41.0.10
;
; housed in LINX, operated by RIPE NCC
;
.360 NSK.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 360 A 193.0.14.129
;
; temporarily housed at ISI (IANA)
;
.360 NSL.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 360 A 198.32.64.12
;
; housed in Japan, operated by WIDE
;
.360 NSM.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 360 A 202.12.27.33
; End of File
--19359@23195#13275--
Previous Comments:
[2003-01-05 21:47:40] [EMAIL PROTECTED]
When using microsoft web publishing wizard to post files to a php
script $_FILES is always empty. Logged in my php error log is:
[06-Jan-2003 16:46:49] PHP Warning: File Upload Mime headers garbled
in Unknown on line 0
It is able to reteive some of the post values but not the files. Is
this really a Microsoft RFC compliance problem or a PHP problem?
Using the following script:
$value) {
fwrite($fp, "$header: $value\n");
}
fclose($fp);
echo $content;
I set WPW to HTTP Post files to the URL of this script and the files
are never available. A common entry in fb.log looks like this:
New Hit
**
$_SERVER:
array (
'COMSPEC' => 'C:WINNTsystem32cmd.exe',
'CONTENT_LENGTH' => '189',
'CONTENT_TYPE' => 'Multipart/Form-Data,boundary=23264@18686#20663',
'DOCUMENT_ROOT' => 'i:/httpd/www.graftonhall.co.nz/htdocs',
'HTTP_ACCEPT' => '*/*',
'HTTP_CACHE_CONTROL' => 'no-cache',
'HTTP_CONNECTION' => 'Keep-Alive',
'HTTP_HOST' => 'www.graftonhall.co.nz',
'HTTP_USER_AGENT' => 'Microsoft HTTP Post (RFC1867)',
'PATH' => 'C:Program Filessapdbwebpgm;C:Program
Filessapdbindep_progpgm;C:Program
Filessapdbindep_progbin;C:Program
Filessapdbindep_progpgm;C:Program
FilesNetwor
Bug #16569: pg_close($conn2) closes all connections?
From: [EMAIL PROTECTED]
Operating system: RedHat 7.0
PHP version: 4.1.1
PHP Bug Type: PostgreSQL related
Bug description: pg_close($conn2) closes all connections?
/* TWO CONNECTIONS TO SAME SERVER, SAME DATABASE */
$conn1=pg_Connect("host=172.15.15.1 user=me dbname=mydb");
$conn2=pg_Connect("host=172.15.15.1 user=me dbname=mydb");
/* QUERIES HERE OK ON EITHER CONNECTION */
$result=pg_exec($conn1, "select stuff from table");
$result=pg_exec($conn2, "select stuff from table");
/* CLOSE conn2, conn1 SHOULD STILL BE OPEN */
$conn2=pg_close($conn2);
$result=pg_exec($conn1, "select stuff from table");
// ERROR! $conn1 seems to have been closed!
// MAYBE YOU ASK WHY WE DO TWO CONNS TO SAME db?
// NORMALLY, THEY ARE TWO DIFFERENT db's, MAIN and
// BACKUP. IN A failover SITUATION, BACKUP DB IS
// DOING BOTH JOBS, SO BOTH CONNS TO SAME MACHINE
// OUR PROBLEM FIXED WITH CONDITIONAL CODE: EG: IF
// MAIN AND BACKUP DBS ARE SAME, DON'T MAKE SECOND
// CONNECTION, BUT THOUGHT YOU SHOULD KNOW
// ABOUT THIS.
--
Edit bug report at http://bugs.php.net/?id=16569&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16569&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16569&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16569&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16569&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16569&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16569&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16569&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16569&r=submittedtwice
Bug #17218 Updated: PHP 4.2.1 doesn't compile after ./configure
ID: 17218 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.2.1 New Comment: Same goes hereIf ya need any other testing on Solaris 8 or Solaris 7, please let me know. 4.2.1 compiled fine on Linux :) - Mike Previous Comments: [2002-05-15 09:21:57] [EMAIL PROTECTED] Copying the 4.2.0 configure script over did the trick here as well. Let me know if you'd like me to run any other tests to help track down where the problem is. Thanks -- Dave [2002-05-14 19:04:47] [EMAIL PROTECTED] Great. At least we have the problem diagnosed. [2002-05-14 18:56:11] [EMAIL PROTECTED] I copied the configure script from the 4.2.0 tarball and it seems to work, thanks for the hint. [2002-05-14 18:44:02] [EMAIL PROTECTED] I've just checked, and there were no changes made in configure script between 4.2.0 and 4.2.1 appart from version number and the register globals warning. The only significant thing is that the configure was built using autoconf 2.53 in 4.2.0 tarball, and with autoconf 2.13 in 4.2.1 due to some probles we were having with the latest version. Could you please try to copy configure script from 4.2.0 tarball over in 4.2.1 source and see if the build works? [2002-05-14 18:23:17] [EMAIL PROTECTED] Same problem here... after commenting out "#define HAVE_UNIX_H 1" I get a lot of warnings when compiling: In file included from ../main/php_config.h:2084, from zend_config.h:1, from zend.h:48, from zend_compile.h:24, from zend_language_parser.c:147: /usr/include/stdlib.h:79: warning: empty declaration In file included from ../main/php_config.h:2088, from zend_config.h:1, from zend.h:48, from zend_compile.h:24, from zend_language_parser.c:147: /usr/include/sys/types.h:339: warning: empty declaration /usr/include/sys/types.h:480: warning: empty declaration /usr/include/sys/types.h:481: warning: empty declaration and so on 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/17218 -- Edit this bug report at http://bugs.php.net/?id=17218&edit=1
Bug #15177 Updated: Informix Shared Module will not compile
ID: 15177 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Compile Failure Operating System: RH Linux 7.2 PHP Version: 4.1.1 New Comment: OK, I made it compile, but I don't know how to change the things that generate the makefiles and such. I just did the configure, compiled it until it gave an error, and then modified the line and manually ran it until it worked. There were 2 problems. 2 libs were specified with relative paths, I was in /home/mike/php..., and on the line, they were /etc/..., so I changed them to /home/mike/etc... See the /home/mike in the line below. I haven't tested weather it actually works, but it finished compiling properly after that. /bin/sh /home/mike/php-4.2.1/libtool --silent --mode=link gcc -I. -I/home/mike/php-4.2.1/ext/informix -I/home/mike/php-4.2.1/main -I/home/mike/php-4.2.1 -I/home/mike/php-4.2.1/Zend -I/opt/informix/incl/esql -I/home/mike/php-4.2.1/ext/mysql/libmysql -I/home/mike/php-4.2.1/ext/xml/expat -I/home/mike/php-4.2.1/TSRM -g -O2 -o informix.la -avoid-version -module -rpath /home/mike/php-4.2.1/modules ifx.lo -R/home/mike/php-4.2.1/ext/informix -L/home/mike/php-4.2.1/ext/informix -R/opt/informix/lib/esql -L/opt/informix/lib/esql -R/opt/informix/lib -L/opt/informix/lib -lifsql -lifasf -lifgen -lifos -lifgls -ldl -lcrypt -lifglx Previous Comments: [2002-05-07 22:50:57] [EMAIL PROTECTED] Still busted in 4.2! I thought this was marked critical for 4.2? Same exact error for me (same platform): /bin/sh /home/zhamm/php-4.2.0/libtool --silent --mode=compile gcc -I. -I/home/zhamm/php-4.2.0/ext/informix -I/home/zhamm/php-4.2.0/main -I/home/zhamm/php-4.2.0 -I/home/zhamm/php-4.2.0/Zend -I/opt/informix/incl/esql -I/home/zhamm/php-4.2.0/TSRM -g -O2 -prefer-pic -c ifx.c && touch ifx.slo /bin/sh /home/zhamm/php-4.2.0/libtool --silent --mode=link gcc -I. -I/home/zhamm/php-4.2.0/ext/informix -I/home/zhamm/php-4.2.0/main -I/home/zhamm/php-4.2.0 -I/home/zhamm/php-4.2.0/Zend -I/opt/informix/incl/esql -I/home/zhamm/php-4.2.0/TSRM -g -O2 -o informix.la -avoid-version -module -rpath /home/zhamm/php-4.2.0/modules ifx.lo -Rext/informix -Lext/informix -R/opt/informix/lib/esql -L/opt/informix/lib/esql -R/opt/informix/lib -L/opt/informix/lib -lifsql -lifasf -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx libtool: link: only absolute run-paths are allowed make[3]: *** [informix.la] Error 1 make[3]: Leaving directory `/home/zhamm/php-4.2.0/ext/informix' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/zhamm/php-4.2.0/ext/informix' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/zhamm/php-4.2.0/ext' make: *** [all-recursive] Error 1 [2002-04-02 20:36:35] [EMAIL PROTECTED] This is still broken for php-4.2.0RC1: libtool: link: only absolute run-paths are allowed make[3]: *** [informix.la] Error 1 Ran configure with: # ./configure --with-apxs=/usr/sbin/apxs --enable-shared --with-informix=shared --without-mysql --without-xml Does anyone know how to fix this in libtool? [2002-03-07 12:12:10] [EMAIL PROTECTED] This might possibly be related to bug number 15803 as this is the last time (php-4.0.4pl1) I was able to compile Informix with IBM DB2 support at the same time as well... [2002-03-03 05:34:47] [EMAIL PROTECTED] Marking as Critical for release 4.2.0 [2002-03-03 05:30:06] [EMAIL PROTECTED] The last version where compile with-informix worked was php4-4.0.4pl1 None after that work, I've tryed them all, including snapshots 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/15177 -- Edit this bug report at http://bugs.php.net/?id=15177&edit=1
#19507 [NEW]: incorrect parsing of POST/GET variables
From: [EMAIL PROTECTED]
Operating system:
PHP version: 4.2.3
PHP Bug Type: mbstring related
Bug description: incorrect parsing of POST/GET variables
When compiling php with the mbstring extension, parsing of POST and GET
variables which contain url-encoded keys is not done correctly. this
especially effects array input variables in GET/POST request. for
example:
let's say we have a page only containing:
invoking this page like info.php?tld[]=.com&tld[]=.name&tld[]=.us
shows the correct result:
_GET["tld"] = Array
(
[0] => .com
[1] => .name
[2] => .us
)
but the browser usually encodes [ with %5B and ] with %5D in the url, so
let's try that:
info.php?tld%5B%5D=.com&tld%5B%5D=.name&tld%5B%5D=.us
shows an incorrect result:
_GET["tld"] = Array
(
[0] =>
[1] => e
[2] => .us
)
To be frankly :) I already tracked down the problem by reviewing the
source code of PHP and noticed that it was introduced specifically in
4.2.3. Around line 1030 of mbstring.c, the code which parses the URL
variables was, it looks like, cleaned up a bit. it was in 4.2.2:
while (var && n < num) {
val = strchr(var, '=');
if (val) { /* have a value */
*val++ = '\0';
val_list[n] = var;
len_list[n] = php_url_decode(var, strlen(var));
n++;
val_list[n] = val;
len_list[n] = php_url_decode(val, strlen(val));
} else {
val_list[n] = var;
len_list[n] = php_url_decode(var, strlen(var));
n++;
val_list[n] = NULL;
len_list[n] = 0;
}
n++;
var = php_strtok_r(NULL, separator, &strtok_buf);
}
num = n;
and in 4.2.3 changed to:
/* split and decode the query */
n = 0;
strtok_buf = NULL;
var = php_strtok_r(res, separator, &strtok_buf);
while (var) {
val = strchr(var, '=');
val_list[n] = var;
len_list[n] = php_url_decode(var, strlen(var));
n++;
if (val) { /* have a value */
*val++ = '\0';
val_list[n] = val;
len_list[n] = php_url_decode(val, strlen(val));
} else {
val_list[n] = "";
len_list[n] = 0;
}
n++;
var = php_strtok_r(NULL, separator, &strtok_buf);
}
num = n; /* make sure to process initilized vars only */
the problem with the code change is that the equal sign is not overwritten
with the string terminator \0 before php_url_decode is called on the
GET/POST variable name, so the GET/POST variable value is urldecoded in
the same step. but the code following the first php_url_decode assumes
that the equal sign is still on the same place, which is not the case if
the key contained characters that were url-encoded (had characters in the
%## syntax), because the string gets smaller and the equal sign moves in
this case.
one url-encoded character causes the string to get two characters smaller,
so we can explain our example from the top:
[ and ] are url-encoded, two characters, for each of them the equal sign
(and with it the GET/POST variable value) moves two characters. so, it
moves four characters at total:
_GET["tld"] = Array
(
[0] =>// .com are four characters, after four
disappear to the left, none remains
[1] => e // .name are five characters, after four
disappear to the left, only the last remains
[2] => .us// php_url_decode does place the end-of line
character of the decoded string just before the dot, so .us does not get
shortened
)
Maybe it's better to rewind this code part to what it was in 4.2.2. just a
suggestion, i don't want tell anyone how to do their work :)
You can also use the patch below. It is against PHP 4.2.3.
I already verified that the patch works, it fixes the problem.
--- php-4.2.3/ext/mbstring/mbstring.c.org 2002-09-19 22:32:22.0
+0200
+++ php-4.2.3/ext/mbstring/mbstring.c 2002-09-19 22:29:32.0 +0200
@@ -1031,15 +1031,18 @@
var = php_strtok_r(res, separator, &strtok_buf);
while (var) {
val = strchr(var, '=');
- val_list[n] = var;
- len_list[n] = php_url_decode(var, strlen(var));
- n++;
if (val) { /* have a value */
*val++ = '\0';
+ val_list[n] = var;
+ len_list[n] = php_url_decode(var, strlen(var));
+ n++;
val_l
#19511 [NEW]: snaps.php.net CVS HEAD build failing.
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4CVS-2002-09-19 PHP Bug Type: Compile Failure Bug description: snaps.php.net CVS HEAD build failing. It appears the changes to the php_info display is causing the build of the HEAD branch to fail on snaps.php.net Fri Sep 20 04:00:01 2002 CET Starting snapshot 200209200200 HEAD Branch === Checking out current cvs Building base package = Base build failed -- Edit bug report at http://bugs.php.net/?id=19511&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19511&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19511&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19511&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19511&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19511&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19511&r=support Expected behavior: http://bugs.php.net/fix.php?id=19511&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19511&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19511&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19511&r=globals
#3263 [Com]: Bad things with NULs in arrays
ID: 3263
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Won\'t fix
Bug Type: Other
Operating System: GNU/Linux
PHP Version: 3.0.14
New Comment:
The bug is from 1999! I thought it was pretty funny to get something on
it now, I can only assume you're clearing out old unresolved bug
reports :-)
Previous Comments:
[2002-10-01 15:11:56] [EMAIL PROTECTED]
We are sorry, but can not support PHP 3 related problems anymore.
Momentum is gathering for PHP 5, and we think supporting PHP 3 will
lead to a waste of resources which we want to put into getting PHP 5
ready. Ofcourse PHP 4 will will continue to be supported for the
forseeable future.
works in php4
[2000-01-20 17:59:18] [EMAIL PROTECTED]
$forwards=sprintf("%s%c%s", "bob@", 0, "[EMAIL PROTECTED]");
$forward[]=$forwards;
$debug=fopen("/tmp/output", "w");
fwrite ($debug, implode("", $forward), 255);
print "Hello";
Produces the output:
bob@<00>
--
Edit this bug report at http://bugs.php.net/?id=3263&edit=1
#19981 [NEW]: Posted Array loses variables
From: [EMAIL PROTECTED]
Operating system: Linux Redhat 7.3
PHP version: 4.2.3
PHP Bug Type: Arrays related
Bug description: Posted Array loses variables
script below.
When posting the form with the array variables, the
receiving function 'loses' the first 4 characters of posted
information, whether numbers or letters.
-start script-
";
$counter++;
}
addInventory();
}
function addInventory() {
global $ZONES;
//number of inventory slots to show at a time.
$maxslots=20;
print "
Date
Time Slot
Zone
Inventory
";
for($x=1;$x<=$maxslots;$x++) {
print "
10am to 12pm
12pm to 2pm
2pm to 4pm
4pm to 6pm
6pm to 8pm
";
for($y=1;$y<=$ZONES;$y++) {
print "Zone $y";
}
print "
";
}
print "
<
/td>
";
}
switch($action) {
case "saveinventory":
saveInventory();
break;
default:
addInventory();
break;
}
?>
-end script-
configure line
'./configure' '--with-apxs' '--with-mysql' '--with-gd' '--
with-png-dir=/usr/lib' '--with-jpeg-dir=/usr/lib' '--with-
freetype-dir=/usr/lib' '--enable-trans-sid' '--with-xml' '-
-enable-wddx' '--enable-mbstring' '--enable-mbstr-enc-
trans' '--with-config-file-path=/etc' '--with-zlib-dir=/
usr/lib' '--enable-bcmath' '--with-curl'
--
Edit bug report at http://bugs.php.net/?id=19981&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19981&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=19981&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=19981&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19981&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=19981&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19981&r=support
Expected behavior: http://bugs.php.net/fix.php?id=19981&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19981&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19981&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=19981&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19981&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=19981&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=19981&r=isapi
#14547 [Com]: Informix as shared module libtool rpath problem
ID: 14547 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Informix related Operating System: RH Linux 7.1 PHP Version: 4.1.0 New Comment: /bin/sh /home/mike/php-4.2.3/libtool --silent --mode=link gcc -I. -I/home/mike/php-4.2.3/ext/informix -I/home/mike/php-4.2.3/main -I/home/mike/php-4.2.3 -I/home/mike/php-4.2.3/Zend -I/opt/informix/incl/esql -I/home/mike/php-4.2.3/ext/mysql/libmysql -I/home/mike/php-4.2.3/ext/xml/expat -I/home/mike/php-4.2.3/TSRM -g -O2 -o informix.la -avoid-version -module -rpath /home/mike/php-4.2.3/modules ifx.lo -R/home/mike/php-4.2.3/ext/informix -L/home/mike/php-4.2.3/ext/informix -R/opt/informix/lib/esql -L/opt/informix/lib/esql -R/opt/informix/lib -L/opt/informix/lib -lifsql -lifasf -lifgen -lifos -lifgls -ldl -lcrypt -lifglx Made it work, I had to remove -lphpifx and add absolute paths to some of the stuff. I don't understand why this can't be fixed, the bug and fix have been documented for months now, what gives? 1. Change makefile to use absolute paths for libtool. 2. Remove -lphpfix from the buld line. Previous Comments: [2002-10-21 09:45:19] [EMAIL PROTECTED] ./configure --with-informix=shared Still fails, with: /php-4.2.3 -I/home/mike/php-4.2.3/Zend -I/opt/informix/incl/esql -I/home/mike/php-4.2.3/ext/mysql/libmysql -I/home/mike/php-4.2.3/ext/xml/expat -I/home/mike/php-4.2.3/TSRM -g -O2 -o informix.la -avoid-version -module -rpath /home/mike/php-4.2.3/modules ifx.lo -Rext/informix -Lext/informix -R/opt/informix/lib/esql -L/opt/informix/lib/esql -R/opt/informix/lib -L/opt/informix/lib -lifsql -lifasf -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx libtool: link: only absolute run-paths are allowed make[3]: *** [informix.la] Error 1 This can be fixed easily by hand, but I don't know how to fix it with the configure stuff. It is still a bug. [2002-07-16 01:00:08] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, 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". [2002-06-16 00:31:43] [EMAIL PROTECTED] Works just fine as shared too. Please let us know if the snapshot works for you or not. [2002-06-15 23:56:08] [EMAIL PROTECTED] Please try compiling it as shared. I'll try the same from the snapshot. [2002-06-15 20:37:09] [EMAIL PROTECTED] This snapshot: http://snaps.php.net/php4-latest.tar.gz Works for me with Informix CSDK 2.70.UC3. Although I did only compile it as static module, not shared. But it _should_ work fine as shared too. --Jani 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/14547 -- Edit this bug report at http://bugs.php.net/?id=14547&edit=1
#14547 [Com]: Informix as shared module libtool rpath problem
ID: 14547 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Informix related Operating System: RH Linux 7.1 PHP Version: 4.1.0 New Comment: ./configure --with-informix=shared Still fails, with: /php-4.2.3 -I/home/mike/php-4.2.3/Zend -I/opt/informix/incl/esql -I/home/mike/php-4.2.3/ext/mysql/libmysql -I/home/mike/php-4.2.3/ext/xml/expat -I/home/mike/php-4.2.3/TSRM -g -O2 -o informix.la -avoid-version -module -rpath /home/mike/php-4.2.3/modules ifx.lo -Rext/informix -Lext/informix -R/opt/informix/lib/esql -L/opt/informix/lib/esql -R/opt/informix/lib -L/opt/informix/lib -lifsql -lifasf -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx libtool: link: only absolute run-paths are allowed make[3]: *** [informix.la] Error 1 This can be fixed easily by hand, but I don't know how to fix it with the configure stuff. It is still a bug. Previous Comments: [2002-07-16 01:00:08] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, 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". [2002-06-16 00:31:43] [EMAIL PROTECTED] Works just fine as shared too. Please let us know if the snapshot works for you or not. [2002-06-15 23:56:08] [EMAIL PROTECTED] Please try compiling it as shared. I'll try the same from the snapshot. [2002-06-15 20:37:09] [EMAIL PROTECTED] This snapshot: http://snaps.php.net/php4-latest.tar.gz Works for me with Informix CSDK 2.70.UC3. Although I did only compile it as static module, not shared. But it _should_ work fine as shared too. --Jani [2002-02-12 08:47:04] [EMAIL PROTECTED] The same happens with the latest snapshot from today. 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/14547 -- Edit this bug report at http://bugs.php.net/?id=14547&edit=1
Bug #15113 Updated: PHP4,javabeans, libphp_java.so
ID: 15113 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Java related Operating System: Redhat Linux7.2 PHP Version: 4.1.1 New Comment: I am having the same problemI'm running Solaris 8, JDK1.2, Apache 1.2.23, Php 4.1.2 and gcc 2.95.2. No matter what I can't get it to build libphp_java.so. It always builds libphp_java.a. Any help would be great. - Mike Previous Comments: [2002-02-24 06:19:58] [EMAIL PROTECTED] Please test with PHP 4.1.1+JDK 1.2 and report the result back Please do not forget updating PHP version. Thanks. [2002-01-19 05:41:03] [EMAIL PROTECTED] Hi, I want to setup a php with javabeans support. My versions is Redhat Linux7.2+jdk1.3.1+php4.1.1 when i finished all the setup job, i found haven't the 'libphp_java.so' file. I searched all the directories, only found a libphp_java.la and libphp_java.a file. Who can tell me why? my /etc/profile file relation setting is below: PATH=$PATH:/usr/local/jdk1.3.1_02/bin:/usr/local/jdk1.3.1_02/jre/bin PATH=$PATH:/usr/local/mysql/bin:/usr/local/etc/httpd/bin CLASSPATH=/usr/local/jdk1.3.1_02/jre/lib/rt.jar JAVA_HOME=/usr/local/jdk1.3.1_02 My php.ini file is at /usr/local/lib/php.ini java.class.path = /usr/local/etc/php4/ext/java/php_java.jar:/usr/local/jdk1.3.1_02/jre/lib /rt.jar java.home = /usr/local/jdk1.3.1_02 java.library = libjava.so java.library.path = /usr/local/jdk1.3.1_02/jre/lib/i386:/usr/local/jdk1.3.1_02/jre/lib/i386/ classic:/usr/local/jdk1.3.1_02/jre/lib/i386/native_threads ;extension_dir = /usr/local/lib/php/20010901 ;extension = libphp_java.so [2002-01-19 05:38:45] [EMAIL PROTECTED] Hi, I want to setup a php with javabeans support. My versions is Redhat Linux7.2+jdk1.3.1+php4.1.1 when i finished all the setup job, i found haven't the 'libphp_java.so' file. I searched all the directories, only found a libphp_java.la and libphp_java.a file. Who can tell me why? my /etc/profile file relation setting is below: PATH=$PATH:/usr/local/jdk1.3.1_02/bin:/usr/local/jdk1.3.1_02/jre/bin PATH=$PATH:/usr/local/mysql/bin:/usr/local/etc/httpd/bin CLASSPATH=/usr/local/jdk1.3.1_02/jre/lib/rt.jar JAVA_HOME=/usr/local/jdk1.3.1_02 java.class.path = /usr/local/etc/php4/ext/java/php_java.jar:/usr/local/jdk1.3.1_02/jre/lib/rt.jar java.home = /usr/local/jdk1.3.1_02 java.library = libjava.so java.library.path = /usr/local/jdk1.3.1_02/jre/lib/i386:/usr/local/jdk1.3.1_02/jre/lib/i386/classic:/usr/local/jdk1.3.1_02/jre/lib/i386/native_threads ;extension_dir = /usr/local/lib/php/20010901 ;extension = libphp_java.so -- Edit this bug report at http://bugs.php.net/?id=15113&edit=1
Bug #15821: imap_fetchbody fails on subparts
From: [EMAIL PROTECTED] Operating system: Windows 2000 SP2 PHP version: 4.1.1 PHP Bug Type: IMAP related Bug description: imap_fetchbody fails on subparts imap_fetchbody does not return anything when I try to get a subpart of a multipart message. IE a multipart/mixed message with part 1 text/plain and part 2 with type text/html. If I pass either 1.1 or 1.2 I get an empty string. Passing either 1 or 2 fetches the plain and html parts respectively. Obtaining the struct with or without FT_PREFETCHTEXT makes no difference. I suspect the problem is in the client lib. In looking at the server logs no FETCH request is issued in the 1.1 and 1.2 part cases. Mike. -- Edit bug report at http://bugs.php.net/?id=15821&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15821&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15821&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15821&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15821&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15821&r=support Expected behavior: http://bugs.php.net/fix.php?id=15821&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15821&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15821&r=submittedtwice
Bug #15821 Updated: imap_fetchbody fails on subparts
ID: 15821 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: IMAP related Operating System: Windows 2000 SP2 PHP Version: 4.1.1 New Comment: No bug, bogus developer. Previous Comments: [2002-03-01 15:02:33] [EMAIL PROTECTED] imap_fetchbody does not return anything when I try to get a subpart of a multipart message. IE a multipart/mixed message with part 1 text/plain and part 2 with type text/html. If I pass either 1.1 or 1.2 I get an empty string. Passing either 1 or 2 fetches the plain and html parts respectively. Obtaining the struct with or without FT_PREFETCHTEXT makes no difference. I suspect the problem is in the client lib. In looking at the server logs no FETCH request is issued in the 1.1 and 1.2 part cases. Mike. -- Edit this bug report at http://bugs.php.net/?id=15821&edit=1
Bug #15890: MSSQL 2000 with php_mssql.dll - will not function
From: [EMAIL PROTECTED] Operating system: Windows 2000 advanced server PHP version: 4.1.1 PHP Bug Type: MSSQL related Bug description: MSSQL 2000 with php_mssql.dll - will not function OK, php_mssql.dll will not function on a MSSQL 2000 SP2 server. I just get timeouts with the smallest SQL querys. Well I just get timouts no matter what. All I do get is the phpinfo module information that seems fine and shows everything correctly except the 7.0 part. Looking at the library information it is designed for a version 7... Now I may be wrong here, but, SQL2000 and SQL7 were entirely different engines. SQL7 was a psudo SQL engine more like an ODBC where-as SQL2000 is more of a true SQL engine more like MySQL. Config, IIS 5, PHP 4.1.1, SQL2000 SP2. (Single box) -- Edit bug report at http://bugs.php.net/?id=15890&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15890&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15890&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15890&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15890&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15890&r=support Expected behavior: http://bugs.php.net/fix.php?id=15890&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15890&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15890&r=submittedtwice
Bug #15890 Updated: MSSQL 2000 with php_mssql.dll - will not function
ID: 15890 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MSSQL related Operating System: Windows 2000 advanced server PHP Version: 4.1.1 New Comment: OK SOMEPLACE SOMEWHERE, THERE NEEEDS to be some documentation about this. you HAVE to do it like this or it won't work and nothing out there has is; [MSSQL] extension=php_mssql.dll mssql.allow_persistent = On mssql.max_persistent = -1 mssql.max_links = -1 mssql.min_error_severity = 10 mssql.min_message_severity = 10 mssql.compatability_mode = Off I found this out outta pure accident. Throw it into some module information SOMEPLACE please for the rest of the people out there with MSSQL2000 Previous Comments: [2002-03-05 18:57:43] [EMAIL PROTECTED] OK, php_mssql.dll will not function on a MSSQL 2000 SP2 server. I just get timeouts with the smallest SQL querys. Well I just get timouts no matter what. All I do get is the phpinfo module information that seems fine and shows everything correctly except the 7.0 part. Looking at the library information it is designed for a version 7... Now I may be wrong here, but, SQL2000 and SQL7 were entirely different engines. SQL7 was a psudo SQL engine more like an ODBC where-as SQL2000 is more of a true SQL engine more like MySQL. Config, IIS 5, PHP 4.1.1, SQL2000 SP2. (Single box) -- Edit this bug report at http://bugs.php.net/?id=15890&edit=1
Bug #13834 Updated: SID already defined
ID: 13834
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Session related
Operating System: FreeBSD 4.2
PHP Version: 4.0.6
New Comment:
This is still broken in 4.1.2
Using Horde 2.0 & IMP 3.0 wiht an SQL session handler, we get the
following error:
[Sun Mar 10 15:16:29 2002] [error] PHP Warning: Constant sid already
defined in /home/secure/public_html/horde/lib/Prefs.php on line 91
[Sun Mar 10 15:16:29 2002] [error] PHP Fatal error: Failed to
initialize session module in
/home/secure/public_html/horde/lib/Prefs.php on line 91
The code causing the error is the usual destory/start:
if ($registry->getMethod('auth/logout') == $registry->getApp())
{
include_once HORDE_BASE . '/lib/Auth.php';
Auth::clearAuth();
session_destroy();
@session_start();
}
Execution stops immediately after the session_start or better put
inside session_start as no debug msg immediately after the
session_start is ever printed.
Previous Comments:
[2002-01-09 02:09:30] [EMAIL PROTECTED]
No feedback. Closing.
[2001-12-19 22:53:16] [EMAIL PROTECTED]
Please test with 4.1.0 and latest CVS snapshot.
CVS snapshot source can be found
http://snaps.php.net/
(No windows binary)
If you don't have problem with latest CVS snapshot,
you can close your bug report by yourself.
Please report the result. When you update your bug
report, do not forget updating PHP version also.
Thank you
--
Yasuo
[2001-10-26 01:30:56] [EMAIL PROTECTED]
This is intended as more information for Bug id #11643. I could not
make comments directly as I am not the creator of the bug and I don't
have Dev Edit privilegdes either.
In any case, the redefinition is apparently session_start(). If I do
more than one session_start(), separated by a session_destroy(), then I
get warning:
Warning: Constant sid already defined in
/usr/home/smoore/php-include/Session_class.php on line 80
I am sure it is session_start() because the following makes the warning
go away:
$save = error_reporting( E_ERROR ); // temporarily turn off warnings
session_start();
error_reporting( $save );
Obviously the fix is to undefine SID in session_destroy. However,
there is no undefine in PHP is there?
It must be redefined because the original session has been destroyed
and the new one has a new session_id().
This doesn't bother my code because I don't use SID.
Hope this helps...
--
Edit this bug report at http://bugs.php.net/?id=13834&edit=1
Bug #16417: session_id() not working
From: [EMAIL PROTECTED] Operating system: WinXP/Win2K PHP version: 4.1.1 PHP Bug Type: Session related Bug description: session_id() not working Using my own session id doesn't appear to work Causes Apache (1.3.22) to crash on Win2K/4.1.1 and produces "Warning: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (c:\\windows\\temp) in Unknown on line 0" on WinXP/4.2.0RC1 Without calling changing the session id, there are no problems -- Edit bug report at http://bugs.php.net/?id=16417&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16417&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16417&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16417&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16417&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16417&r=support Expected behavior: http://bugs.php.net/fix.php?id=16417&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16417&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16417&r=submittedtwice
Bug #16417 Updated: session_id() not working
ID: 16417 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: WinXP/Win2K PHP Version: 4.1.1 New Comment: How do you know I don't have a reason to change the session id? :-) Why claim to provide the functionality, then refuse to support it? I *do* need to change the session id. It is unavoidable. Previous Comments: [2002-04-04 00:03:55] [EMAIL PROTECTED] You really don't have any reason to change the session id. [2002-04-03 18:10:21] [EMAIL PROTECTED] Using my own session id doesn't appear to work Causes Apache (1.3.22) to crash on Win2K/4.1.1 and produces "Warning: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (c:\\windows\\temp) in Unknown on line 0" on WinXP/4.2.0RC1 Without calling changing the session id, there are no problems -- Edit this bug report at http://bugs.php.net/?id=16417&edit=1
Bug #16417 Updated: session_id() not working
ID: 16417 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Session related Operating System: WinXP/Win2K PHP Version: 4.1.1 New Comment: No, it causes the same problem. I've tried it on Win2K/4.1.2, Win2K/4.2.0RC1 now too. I don't see how you can reset the session_id after calling session start anyway. When session_start() is called, the SID constant is set, cookie sent to the client etc. You must have to set a custom session_id before this happens. Previous Comments: [2002-04-04 04:11:55] [EMAIL PROTECTED] Maybe you have to call session_id AFTER session_start()? This is what the docs say: "session_id() returns the session id for the current session. If id is specified, it will replace the current session id." If the session hasn't been started yet, there's no session id to replace. Does it work now? [2002-04-04 02:58:30] [EMAIL PROTECTED] How do you know I don't have a reason to change the session id? :-) Why claim to provide the functionality, then refuse to support it? I *do* need to change the session id. It is unavoidable. [2002-04-04 00:03:55] [EMAIL PROTECTED] You really don't have any reason to change the session id. [2002-04-03 18:10:21] [EMAIL PROTECTED] Using my own session id doesn't appear to work Causes Apache (1.3.22) to crash on Win2K/4.1.1 and produces "Warning: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (c:\\windows\\temp) in Unknown on line 0" on WinXP/4.2.0RC1 Without calling changing the session id, there are no problems -- Edit this bug report at http://bugs.php.net/?id=16417&edit=1
Bug #16425: Undefined symbol in libphp4.so
From: [EMAIL PROTECTED] Operating system: RH 6.2 PHP version: 4.1.2 PHP Bug Type: Apache related Bug description: Undefined symbol in libphp4.so I was trying to upgrade PHP from 3 to 4; downloaded php-4.1.2 from php.net, then did as was discribed in manual. Compilation/installation gave OK responce. Conf string: ./configure --with-apxs=... --with-pgsql=... Strting apache gave an error like Undefined symbol "pcre_XXX" in libphp4.so I've checked that i've got no pcre lib installed. So, i did install it. Then i've listed some reports here and tried the solution like updating Makefile after "./configure" adding parameter -lpcre to ld commandline. Nothing changed (just another "pcre_ was reported). I've added -lpcreposix - the same. I've adder --without-pcre-regex option to configure. Again the same, but now: php_pcre_replace reported as undefined symbol (was php_pcre_compile). I've downloaded the latest 1.x Apache (1.24) and installed it. Then tried again - nothing changed. What was i doing wrong ??? -- Edit bug report at http://bugs.php.net/?id=16425&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16425&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16425&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16425&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16425&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16425&r=support Expected behavior: http://bugs.php.net/fix.php?id=16425&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16425&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16425&r=submittedtwice
Bug #16417 Updated: session_id() not working
ID: 16417 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: WinXP/Win2K PHP Version: 4.1.1 New Comment: Aha! It appears that it is the underscore causing the problem. Previous Comments: [2002-04-04 04:20:48] [EMAIL PROTECTED] No, it causes the same problem. I've tried it on Win2K/4.1.2, Win2K/4.2.0RC1 now too. I don't see how you can reset the session_id after calling session start anyway. When session_start() is called, the SID constant is set, cookie sent to the client etc. You must have to set a custom session_id before this happens. [2002-04-04 04:11:55] [EMAIL PROTECTED] Maybe you have to call session_id AFTER session_start()? This is what the docs say: "session_id() returns the session id for the current session. If id is specified, it will replace the current session id." If the session hasn't been started yet, there's no session id to replace. Does it work now? [2002-04-04 02:58:30] [EMAIL PROTECTED] How do you know I don't have a reason to change the session id? :-) Why claim to provide the functionality, then refuse to support it? I *do* need to change the session id. It is unavoidable. [2002-04-04 00:03:55] [EMAIL PROTECTED] You really don't have any reason to change the session id. [2002-04-03 18:10:21] [EMAIL PROTECTED] Using my own session id doesn't appear to work Causes Apache (1.3.22) to crash on Win2K/4.1.1 and produces "Warning: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (c:\\windows\\temp) in Unknown on line 0" on WinXP/4.2.0RC1 Without calling changing the session id, there are no problems -- Edit this bug report at http://bugs.php.net/?id=16417&edit=1
#31056 [Opn]: php_std_date() returns invalid formatted date if y2k_compliance is On
ID: 31056 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Date/time related Operating System: Linux 2.4 (Debian) PHP Version: 5.0.1 New Comment: It's just a matter of changing 2 hyphens to spaces at http://lxr.php.net/source/php-src/ext/standard/datetime.c#952 Michael Previous Comments: [2004-12-10 20:45:47] [EMAIL PROTECTED] Description: If INI directive "y2k_compliance" is set to "On", php_std_date() returns an invalid HTTP date: Sun, 06-Nov-1994 08:49:37 GMT - which should be: Sun, 06 Nov 1994 08:49:37 GMT - (RFC 822/1123) If "y2k_compliance" is set to "Off", php_std_date() returns a valid RFC850 HTTP date, though(like: Fri, 10-Dec-04 19:38:00 GMT). http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1 -- Edit this bug report at http://bugs.php.net/?id=31056&edit=1
#31583 [Opn]: php_std_date() uses short day names in non-y2k_compliance mode
ID: 31583
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Date/time related
Operating System: N/A
PHP Version: Irrelevant
New Comment:
Here's the patch against HEAD:
--- php-src/ext/standard/datetime.c 12 Dec 2004 15:50:06 -
1.125
+++ php-src/ext/standard/datetime.c 17 Jan 2005 12:14:02 -
@@ -957,7 +957,7 @@
tm1->tm_hour, tm1->tm_min,
tm1->tm_sec);
} else {
snprintf(str, 80, "%s, %02d-%s-%02d %02d:%02d:%02d
GMT",
- day_short_names[tm1->tm_wday],
+ day_full_names[tm1->tm_wday],
tm1->tm_mday,
mon_short_names[tm1->tm_mon],
((tm1->tm_year) % 100),
... and PHP4:
--- php4/ext/standard/datetime.c16 Dec 2004 00:10:55 -
1.96.2.17
+++ php4/ext/standard/datetime.c17 Jan 2005 12:24:30 -
@@ -781,7 +781,7 @@
tm1->tm_hour, tm1->tm_min,
tm1->tm_sec);
} else {
snprintf(str, 80, "%s, %02d-%s-%02d %02d:%02d:%02d
GMT",
- day_short_names[tm1->tm_wday],
+ day_full_names[tm1->tm_wday],
tm1->tm_mday,
mon_short_names[tm1->tm_mon],
((tm1->tm_year) % 100),
Previous Comments:
[2005-01-17 12:43:55] [EMAIL PROTECTED]
Description:
http://cvs.php.net/co.php/php-src/ext/standard/datetime.c#999
should use day_long_names[] to be RFC850 compliant
Expected result:
Sunday, 06-Nov-94 08:49:37 GMT
Actual result:
--
Sun, 06-Nov-94 08:49:37 GMT
--
Edit this bug report at http://bugs.php.net/?id=31583&edit=1
#31583 [Opn]: php_std_date() uses short day names in non-y2k_compliance mode
ID: 31583
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Date/time related
Operating System: N/A
PHP Version: Irrelevant
New Comment:
The following patches should fix this issue additionally to bug
#31689:
http://dev.iworks.at/patches/PHP_4_3_datetime_PHPAPI.patch.txt
http://dev.iworks.at/patches/PHP_5_0_datetime_PHPAPI.patch.txt
http://dev.iworks.at/patches/PHP_HEAD_datetime_PHPAPI.patch.txt
Previous Comments:
[2005-01-17 13:25:12] [EMAIL PROTECTED]
Here's the patch against HEAD:
--- php-src/ext/standard/datetime.c 12 Dec 2004 15:50:06 -
1.125
+++ php-src/ext/standard/datetime.c 17 Jan 2005 12:14:02 -
@@ -957,7 +957,7 @@
tm1->tm_hour, tm1->tm_min,
tm1->tm_sec);
} else {
snprintf(str, 80, "%s, %02d-%s-%02d %02d:%02d:%02d
GMT",
- day_short_names[tm1->tm_wday],
+ day_full_names[tm1->tm_wday],
tm1->tm_mday,
mon_short_names[tm1->tm_mon],
((tm1->tm_year) % 100),
... and PHP4:
--- php4/ext/standard/datetime.c16 Dec 2004 00:10:55 -
1.96.2.17
+++ php4/ext/standard/datetime.c17 Jan 2005 12:24:30 -
@@ -781,7 +781,7 @@
tm1->tm_hour, tm1->tm_min,
tm1->tm_sec);
} else {
snprintf(str, 80, "%s, %02d-%s-%02d %02d:%02d:%02d
GMT",
- day_short_names[tm1->tm_wday],
+ day_full_names[tm1->tm_wday],
tm1->tm_mday,
mon_short_names[tm1->tm_mon],
((tm1->tm_year) % 100),
[2005-01-17 12:43:55] [EMAIL PROTECTED]
Description:
http://cvs.php.net/co.php/php-src/ext/standard/datetime.c#999
should use day_long_names[] to be RFC850 compliant
Expected result:
Sunday, 06-Nov-94 08:49:37 GMT
Actual result:
--
Sun, 06-Nov-94 08:49:37 GMT
--
Edit this bug report at http://bugs.php.net/?id=31583&edit=1
#31689 [Opn]: PHPAPI missing for php_std_date() and php_parse_date()
ID: 31689 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Win32 PHP Version: Irrelevant New Comment: The following patches should fix this issue additionally to bug #31583: http://dev.iworks.at/patches/PHP_4_3_datetime_PHPAPI.patch.txt http://dev.iworks.at/patches/PHP_5_0_datetime_PHPAPI.patch.txt http://dev.iworks.at/patches/PHP_HEAD_datetime_PHPAPI.patch.txt Previous Comments: [2005-01-25 17:54:52] [EMAIL PROTECTED] Description: php_std_date() and php_parse_date() are missing PHPAPI, so that extensions using this functions cannot be built as shared extensions on Win32. -- Edit this bug report at http://bugs.php.net/?id=31689&edit=1
Bug #65481 [Asn->Csd]: Shutdown segfault due to serialize
Edit report at https://bugs.php.net/bug.php?id=65481&edit=1 ID: 65481 Updated by: m...@php.net Reported by:m...@php.net Summary:Shutdown segfault due to serialize -Status: Assigned +Status: Closed Type: Bug Package:Variables related PHP Version:5.4Git-2013-08-19 (Git) Assigned To:mike Block user comment: N Private report: N New Comment: Automatic comment on behalf of mike Revision: http://git.php.net/?p=php-src.git;a=commit;h=1ac4d8f2c632f5be5a02d49c1e0d3b1fb515e4a8 Log: fix bug #65481 (shutdown segfault due to serialize) Previous Comments: [2013-08-19 21:59:46] m...@php.net Description: See the bottom of bug #63481 -- Edit this bug report at https://bugs.php.net/bug.php?id=65481&edit=1
Bug #63481 [Asn]: Segmentation fault caused by unserialize()
Edit report at https://bugs.php.net/bug.php?id=63481&edit=1
ID: 63481
Updated by: m...@php.net
Reported by:aurelijus at astdev dot lt
Summary:Segmentation fault caused by unserialize()
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: RHEL 6 & Mac OS X 10.7.4
PHP Version:5.4.8
Assigned To:mike
Block user comment: N
Private report: N
New Comment:
See bug #65481
Previous Comments:
[2013-07-29 18:11:56] m...@php.net
Yes, please. I already have a possible fix for the second issue.
[2013-06-06 09:57:11] arjen at react dot com
I believe these are different issues, the backtrace is quite different.
Got the following results using php-5.4.15 from php.net:
Original report: https://gist.github.com/anonymous/5720457
Backtrace of https://gist.github.com/aurelijus/4713758:
https://gist.github.com/anonymous/5720464
I tried reducing the original testcase, got a segfault but again the backtrace
is quite different.
Testscript http://3v4l.org/3WCpP (crashes >= 5.4.0)
Backtrace at https://gist.github.com/anonymous/5720491
Should I create a seperate issue for it?
[2013-03-08 15:44:18] zach dot quintana at gmail dot com
I'm also experiencing a similar bug, but will unserializing a class that
doesn't
implement serializable. Need the code?
[2013-02-06 10:07:49] m...@php.net
Yep, avoiding parent::serialize() helps:
diff --git a/serialize.php b/serialize.php
index 14ae4c8..4def326 100644
--- a/serialize.php
+++ b/serialize.php
@@ -58,13 +58,12 @@ class UsernamePasswordToken extends AbstractToken {
public function serialize()
{
-return serialize(array($this->credentials, $this->providerKey,
parent::serialize()));
+return serialize(array($this->credentials, $this->providerKey, $this-
>roles));
}
public function unserialize($str)
{
-list($this->credentials, $this->providerKey, $parentStr) =
unserialize($str);
-parent::unserialize($parentStr);
+list($this->credentials, $this->providerKey, $this->roles) =
unserialize($str);
}
}
[2013-02-06 09:54:10] m...@php.net
Looks like an excellent test case.
I suspect the problem is calling parent::(un)serialize() within a
(un)serialize()
callback.
I'll try to find out.
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
https://bugs.php.net/bug.php?id=63481
--
Edit this bug report at https://bugs.php.net/bug.php?id=63481&edit=1
Bug #65416 [Nab]: output buffering autostart setting php.ini
Edit report at https://bugs.php.net/bug.php?id=65416&edit=1 ID: 65416 Updated by: m...@php.net Reported by:jwestbrook at gmail dot com Summary:output buffering autostart setting php.ini Status: Not a bug Type: Bug Package:Output Control Operating System: linux 64bit AWS ami PHP Version:5.4.17 Block user comment: N Private report: N New Comment: Looks like when this is logged, there actually is no output buffer active, so ob_get_length() returns false. Previous Comments: [2013-08-19 22:07:01] jwestbrook at gmail dot com I also tried the settings of On and 1. I also understand that #!/usr/bin/php means nothing to output buffering but is output that I want to capture if the php file is being run from a browser and discard. >From what I understand that is not how the output buffering works. The way I >understand it the output buffer fills then dumps everything when it is full. In this instance before the output buffer fills I want to discard the first 15 characters because it will corrupt any binary files that the browser is trying to download. Based on the test script attached ob_get_length() should ALWAYS return 15 characters - however at least 12 times a day PHP fails to start the output buffer and I get the error shown. [2013-08-18 06:52:49] yohg...@php.net "#!" does not have special meaning for Web server SAPI. I think you are sending data larger than output buffer size. Then this is the way supposed to be. output_buffering=On or 1 is special. It enables unlimited buffering. Anything other values set buffer chunk size and PHP tries to send data larger than chunk size. Check your buffer size (i.e. output_buffering setting of php.ini file) I guess you have very small output_buffering. Old output buffer increases size automatically, IIRC. New output buffer does not increase buffer size. [2013-08-07 19:47:35] jwestbrook at gmail dot com Description: We recently upgraded from php 5.3 to php 5.4 and when the php.ini output_buffering setting is set to ON or anything greater than zero the output buffering does not always reliably start. This is a problem for some scripts that have a shebang as the first line to make the script easily executable. But if you send a header or anything else after that first line it will fail. based on the script attached the contents of the error log are buffer statues : Array\n(\n)\n Test script: --- #!/usr/bin/php -- Edit this bug report at https://bugs.php.net/bug.php?id=65416&edit=1
Bug #62189 [Opn->Nab]: Behavior of serialize has changed
Edit report at https://bugs.php.net/bug.php?id=62189&edit=1 ID: 62189 Updated by: m...@php.net Reported by:mg at ovos dot at Summary:Behavior of serialize has changed -Status: Open +Status: Not a bug Type: Bug Package:Variables related Operating System: Win64 PHP Version:5.4.3 Block user comment: N Private report: N New Comment: So, nothing I can do here, sorry. Previous Comments: [2013-08-20 06:11:17] mg at ovos dot at I come accross it from time to time, but i'm unable to extract a standalone test case. In general some strings are broken when using unserialize on objects, I usually fix it by using another value :/ It happend on both Linux and Windows servers. [2013-08-19 20:59:21] m...@php.net Duh, well, I'm lost :) So do we have a bug here, or not? And if so, what is it? [2012-06-24 09:04:31] Sjon at hortensius dot net Maybe you misread my comment, or misinterpreted the results demonstrated. I can reproduce your described behavior perfectly using the script I posted. In the results I posted, 5.4 references only Placeholder#8 and #10, while 5.3 and earlier contains references to Placeholder#8, #10, #12 and #14; demonstrating what was fixed in 5.4 again, this behaviour is better in 5.4 and there is no bug demonstrated in that script [2012-06-23 21:13:52] mg at ovos dot at Dear Sjon, You stripped it from the key lines, no wonder you cannot reproduce it. It is all about the lines that you removed. Cheers, Marcin [2012-06-23 14:25:15] Sjon at hortensius dot net Have a look at this example (based on your code): http://3v4l.org/D7HIa Before 5.4, the Placeholder instances were actually different objects. This was fixed in 5.4, therefore the properties correctly reference to the same objects. Regarding your bug, where objects are NOT properly recreated, I am afraid you will need to create an actual reproducable testcase before expecting anyone to take a look at it :) 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 https://bugs.php.net/bug.php?id=62189 -- Edit this bug report at https://bugs.php.net/bug.php?id=62189&edit=1
Bug #63631 [Opn->Fbk]: PDO_PGSQL: bindParam and bindValue not working
Edit report at https://bugs.php.net/bug.php?id=63631&edit=1 ID: 63631 Updated by: m...@php.net Reported by:mamatkazin at spb dot orw dot ru Summary:PDO_PGSQL: bindParam and bindValue not working -Status: Open +Status: Feedback Type: Bug Package:PDO related Operating System: linux PHP Version:5.4.9 Block user comment: N Private report: N New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2012-11-28 07:31:41] mamatkazin at spb dot orw dot ru Description: OS Linux, PHP 5.4.8 and 5.4.9, PostgreSQL 9.2.1, Probably, bindParam and bindValue not working. Code: $stmt=$dbh->prepare(âquery_with_param_?â); $stmt->bindParam(1, $param, PDO::PARAM_STR); // or bindValue $stmt->execute(); $result=$stmt->fetchAll(PDO::FETCH_NUM|PDO::FETCH_COLUMN); Expected result: $result - is not empty; Actual result: $result - empty Test script: --- $stmt=$dbh->prepare(âquery_with_param_?â); $stmt->bindParam(1, $param, PDO::PARAM_STR); // or bindValue $stmt->execute(); $result=$stmt->fetchAll(PDO::FETCH_NUM|PDO::FETCH_COLUMN); Expected result: $result - is not empty; Actual result: -- $result - empty -- Edit this bug report at https://bugs.php.net/bug.php?id=63631&edit=1
Bug #64035 [Opn->Fbk]: In constructing \PDO an empty Fatal Error appears
Edit report at https://bugs.php.net/bug.php?id=64035&edit=1 ID: 64035 Updated by: m...@php.net Reported by:lionishy at gmail dot com Summary:In constructing \PDO an empty Fatal Error appears -Status: Open +Status: Feedback Type: Bug Package:PDO related Operating System: Windows 8 PHP Version:5.4.11 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Cannot reproduce. Previous Comments: [2013-01-21 11:14:08] lionishy at gmail dot com Description: When I construct an object I expect an exception to be thrown when there's any problem. Still, on Windows 8 I get the Fatal Error with no message, while expecting Fatal Error: Uncaught Exception. Moreover, if \PDOException is caught and any other type exception is thrown, normal Fatal Error: Uncaught Exception appears. Test script: --- getMessage()); } Expected result: Fatal Error: Uncaught Exception '\PDOException' with message '' in test.php on line 5 Actual result: -- Fatal Error: in test.php on line 5 -- Edit this bug report at https://bugs.php.net/bug.php?id=64035&edit=1
Bug #64953 [Opn->Ana]: Postgres prepared statement positional parameter casting
Edit report at https://bugs.php.net/bug.php?id=64953&edit=1
ID: 64953
Updated by: m...@php.net
Reported by:goetas at lignano dot it
Summary:Postgres prepared statement positional parameter
casting
-Status: Open
+Status: Analyzed
Type: Bug
Package:PDO related
Operating System: ubuntu 10.04
PHP Version:5.3.25
Block user comment: N
Private report: N
New Comment:
The problem rather is, that PDO contains an SQL parser (or, erm, such) which
implements named parameters like ":argname". The result is then discovered by
people not only using MySQL: havoc.
Previous Comments:
[2013-05-31 09:46:44] goetas at lignano dot it
Description:
Using a prepared statement with positional parameters will produce unexpected
behaviour when casting these parameters.
Test script:
---
// pdo
$pdo = new \PDO("pgsql:host=localhost;dbname=db", "user", "pwd");
$pdo->setAttribute (\PDO::ATTR_ERRMODE, \PDO::ERRMODE_EXCEPTION);
$st = $pdo->prepare('SELECT ?::char as i');
$st->bindValue(1, '1');
$st->execute();
var_dump($st->fetch()); // return false
$st = $pdo->prepare('SELECT (?)::char as i');
$st->bindValue(1, '1');
$st->execute();
var_dump($st->fetch()); // return array(1) { ["i"]=> string(1) "1" }
// old pg extension
$dbconn = pg_connect("host=localhost dbname=superdpi user=postgres
password=df54tb70");
$result = pg_prepare($dbconn, "my_query", 'SELECT $1::char as i');
$result = pg_execute($dbconn, "my_query", array("1"));
var_dump(pg_fetch_assoc ( $result)); // return array(1) { ["i"]=> string(1) "1"
}
Expected result:
array(2) {
["i"]=>
string(1) "1"
[0]=>
string(1) "1"
}
array(2) {
["i"]=>
string(1) "1"
[0]=>
string(1) "1"
}
array(1) {
["i"]=>
string(1) "1"
}
Actual result:
--
bool(false)
array(2) {
["i"]=>
string(1) "1"
[0]=>
string(1) "1"
}
array(1) {
["i"]=>
string(1) "1"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=64953&edit=1
Bug #64953 [Ana->Csd]: Postgres prepared statement positional parameter casting
Edit report at https://bugs.php.net/bug.php?id=64953&edit=1
ID: 64953
Updated by: m...@php.net
Reported by:goetas at lignano dot it
Summary:Postgres prepared statement positional parameter
casting
-Status: Analyzed
+Status: Closed
Type: Bug
Package:PDO related
Operating System: ubuntu 10.04
PHP Version:5.3.25
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of mike
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=27c803aaed259f76a66db1278eea05f30a8ec956
Log: Fix bug #64953 (Postgres prepared statement positional parameter casting)
Previous Comments:
[2013-08-20 13:07:08] m...@php.net
The problem rather is, that PDO contains an SQL parser (or, erm, such) which
implements named parameters like ":argname". The result is then discovered by
people not only using MySQL: havoc.
[2013-05-31 09:46:44] goetas at lignano dot it
Description:
Using a prepared statement with positional parameters will produce unexpected
behaviour when casting these parameters.
Test script:
---
// pdo
$pdo = new \PDO("pgsql:host=localhost;dbname=db", "user", "pwd");
$pdo->setAttribute (\PDO::ATTR_ERRMODE, \PDO::ERRMODE_EXCEPTION);
$st = $pdo->prepare('SELECT ?::char as i');
$st->bindValue(1, '1');
$st->execute();
var_dump($st->fetch()); // return false
$st = $pdo->prepare('SELECT (?)::char as i');
$st->bindValue(1, '1');
$st->execute();
var_dump($st->fetch()); // return array(1) { ["i"]=> string(1) "1" }
// old pg extension
$dbconn = pg_connect("host=localhost dbname=superdpi user=postgres
password=df54tb70");
$result = pg_prepare($dbconn, "my_query", 'SELECT $1::char as i');
$result = pg_execute($dbconn, "my_query", array("1"));
var_dump(pg_fetch_assoc ( $result)); // return array(1) { ["i"]=> string(1) "1"
}
Expected result:
array(2) {
["i"]=>
string(1) "1"
[0]=>
string(1) "1"
}
array(2) {
["i"]=>
string(1) "1"
[0]=>
string(1) "1"
}
array(1) {
["i"]=>
string(1) "1"
}
Actual result:
--
bool(false)
array(2) {
["i"]=>
string(1) "1"
[0]=>
string(1) "1"
}
array(1) {
["i"]=>
string(1) "1"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=64953&edit=1
Bug #44597 [Opn->Fbk]: [PATCH] Postgres driver does not prepare booleans correctly
Edit report at https://bugs.php.net/bug.php?id=44597&edit=1 ID: 44597 Updated by: m...@php.net Reported by:kenaniah at gmail dot com Summary:[PATCH] Postgres driver does not prepare booleans correctly -Status: Open +Status: Feedback Type: Bug Package:PDO related Operating System: Red Hat 4.1.1 PHP Version:5.2.6 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Seems to work correctly in recent versions. Previous Comments: [2010-10-12 12:20:14] ddebernardy at yahoo dot com I'm in agreement with the last commenter. The PGSQL driver handles booleans that are typecast as integers properly, but not the actual booleans. These really ought to work out of the box. [2009-10-05 06:08:33] kenaniah at gmail dot com *Sjoerd My apologies on the incorrect spelling. [2009-10-05 06:07:07] kenaniah at gmail dot com In response to sjored, I believe there is huge disagreement over that issue, and I can personally speak for many of my colleagues in saying that. While I understand the repercussions of the patch, I would also like to point out that the example cited depends on buggy functionality in the first place. For that reason alone, I humbly submit that such a case should not be considered when weighing the implementation of the patch. On the second point, I believe we have another difference of opinion. All DBMSs perform their own casting on query parameters to match internal data types. For example, certain DBs honor the *string* 'False' as a boolean value, whereas a simple boolean cast performed in PHP would result in the said parameter evaluating to TRUE. In addition, other transformations may be applied to a passed parameter based on localization, custom data types, complex data types, etc. which vary from vendor to vendor and schema to schema. The role of PDO should be to transparently forward parameters to queries via their respective PHP and PDO-recognized data types. Now concerning the third point: PHP is a loosely-typed language. There is beauty in being able to provide mixed parameters to functions. There is nothing wrong with allowing a "mixed" parameter to be passed to a query either. Most DBs operate perfectly fine when receiving mixed parameters, and rightfully throw an error when something is amiss. Passing 'True', TRUE, or 1 to a boolean database field is perfectly acceptable in many systems. And concerning your last statement: PHP should never under any circumstance attempt to think for the programmer. I expect a database abstraction layer to pass parameters along transparently *because* it is an abstraction layer. A programming language is not smarter than the one who implements it, and it is impossible to mitigate an error in logic. Rather, it is better for an error to be returned in order so that the erroneous logic be corrected, as their may be an even greater issue at hand. In closing, I believe that the implementation of a patch for this issue would be more inline with the general philosophy and design patterns that govern PHP than the current functionality today, to the point that I maintain my position that the current functionality is in fact buggy. I merely ask that PDO -- true to the form and function of an abstraction layer -- would pass parameters along in their respective data types without casting them to "string" of all things. I thank everyone who has participated in this issue thus far (especially sjored for the patch submitted), and am looking forward to this issue being resolved in an upcoming release. [2009-10-04 18:46:07] sjo...@php.net It is a bad idea to determine the PDO type from the PHP type. First, it would break existing scripts which assume false is cast to an empty string, like this: $a[] = strstr($foo, $bar); // may return false $pdo->execute($a); Secondly, the correct type to use is the type of the column, not the type of the PHP parameter. Consider the following query: SELECT * FROM foo WHERE a=? If a is a boolean, the parameter to execute() or bindBaram() should be converted to a boolean, no matter what the type of the passed parameter is. Finally, one of PHP features is that it dynamically changes types. The type of a variable should be transparent to the user. Therefore, the behavior of a function should not change when it is passed another type. To solve this, you should always specify the PDO type. Only the programmer knows which types the column i
Bug #65439 [Opn->Nab]: Build fails when compiled
Edit report at https://bugs.php.net/bug.php?id=65439&edit=1 ID: 65439 Updated by: m...@php.net Reported by:me at umakantpatil dot com Summary:Build fails when compiled -Status: Open +Status: Not a bug Type: Bug Package:PHAR related Operating System: Ubuntu 12.10 PHP Version:5.5.1 Block user comment: N Private report: N New Comment: . Previous Comments: [2013-08-21 07:51:52] me at umakantpatil dot com This is not bug. Sorry for reporting. This was happening because of wrong file permissions. Please close/invalidate this ticket. [2013-08-12 14:10:51] me at umakantpatil dot com Description: When you compile PHP 5.5.1 version build fails with error. I have tried to create build from root user. I'm using maven 2.2.1 for building. I have done many previous versions but this version is somehow not working. Once I say mvn release:prepare it starts compiling PHP and midway it throws error. Details about libs, system are as follows:- OS:- Ubuntu 12.10. Lib:- open-ssl 1.0, bzip2 1.0.6, curl 7.26.0, libjpeg 6b, libpng 1.5.2, freetype 2.4.4, gmp 5.0.1, mhash 0.9.9.9, libmcrypt 2.5.8, tidy 2009-03-25, libiconv 1.14, libxslt 1.2.26, libxml2 2.7.8, get text 0.18, icu 4.8 Enabled:- --with-apxs2=/bin/apxs, --with-libxml-dir=, --disable-short-tags, --with-openssl=, --with-zlib, --with-bz2=, --with-curl=, --with-gd, --with-jpeg-dir=, --with-freetype-dir=, --with-png-dir=, --enable-gd-native-ttf, --with-gettext=, --with-gmp=, --with-mcrypt=, --with-mhash=, --with-tidy=, --with-xmlrpc, --with-iconv=, --with-xsl=, --with-zlib, --enable-bcmath, --enable-calendar, --enable-ftp, --enable-mbstring, --enable-posix=shared, --enable-soap, --enable-wddx, --enable-zip, --enable-exif, --enable-intl, --with-icu-dir=, --without-pear, --enable-zend-signals Expected result: Successful PHP build Actual result: -- [INFO] [INFO] Generating phar.php [INFO] [INFO] /bin/bash: /home/user/php/target/src/build/shtool: Permission denied [INFO] [INFO] /bin/bash: /home/user/php/target/src/build/shtool: Permission denied [INFO] [INFO] /bin/bash: -d: command not found [INFO] [INFO] make: *** [ext/phar/phar.php] Error 127 [INFO] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] [INFO] [INFO] make returned an exit value != 0. Aborting build; see command output above for more information. [INFO] [INFO] [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] [INFO] [INFO] Total time: 20 minutes 12 seconds [INFO] [INFO] Finished at: Mon Aug 12 06:32:09 PDT 2013 [INFO] [INFO] Final Memory: 40M/96M -- Edit this bug report at https://bugs.php.net/bug.php?id=65439&edit=1
Bug #63631 [Fbk]: PDO_PGSQL: bindParam and bindValue not working
Edit report at https://bugs.php.net/bug.php?id=63631&edit=1 ID: 63631 Updated by: m...@php.net Reported by:mamatkazin at spb dot orw dot ru Summary:PDO_PGSQL: bindParam and bindValue not working Status: Feedback Type: Bug Package:PDO related Operating System: linux PHP Version:5.4.9 Block user comment: N Private report: N New Comment: 1.) Please provide a complete reproduce script. 2.) Now is that about PDO_PGSQL or PDO_ODBC? Your subject differs from the error message... Previous Comments: [2013-08-21 09:36:08] pretorian at km dot ru Test: version php 5.4.18 Code: $stmt=$dbh->prepare(âquery_with_param_?â); $stmt->bindParam(1, $param, PDO::PARAM_INT); // or bindValue $stmt->execute(); $result=$stmt->fetchAll(PDO::FETCH_NUM|PDO::FETCH_COLUMN); Error in log: (mod_fastcgi.c.2699) FastCGI-stderr: SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input syntax for integer: ""; Error while executing the query (SQLExecute[7] at /tmp/php-5.4.18/ext/pdo_odbc/odbc_stmt.c:254) [2013-08-20 12:52:00] m...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2012-11-28 07:31:41] mamatkazin at spb dot orw dot ru Description: OS Linux, PHP 5.4.8 and 5.4.9, PostgreSQL 9.2.1, Probably, bindParam and bindValue not working. Code: $stmt=$dbh->prepare(âquery_with_param_?â); $stmt->bindParam(1, $param, PDO::PARAM_STR); // or bindValue $stmt->execute(); $result=$stmt->fetchAll(PDO::FETCH_NUM|PDO::FETCH_COLUMN); Expected result: $result - is not empty; Actual result: $result - empty Test script: --- $stmt=$dbh->prepare(âquery_with_param_?â); $stmt->bindParam(1, $param, PDO::PARAM_STR); // or bindValue $stmt->execute(); $result=$stmt->fetchAll(PDO::FETCH_NUM|PDO::FETCH_COLUMN); Expected result: $result - is not empty; Actual result: -- $result - empty -- Edit this bug report at https://bugs.php.net/bug.php?id=63631&edit=1
Bug #63642 [Asn->Nab]: No "out of memory" error during ->fetchAll() from PostgreSQL
Edit report at https://bugs.php.net/bug.php?id=63642&edit=1
ID: 63642
Updated by: m...@php.net
Reported by:amex at bucksvsbytes dot com
Summary:No "out of memory" error during ->fetchAll() from
PostgreSQL
-Status: Assigned
+Status: Not a bug
Type: Bug
Package:PDO related
Operating System: Ubuntu
PHP Version:5.3.19
Assigned To:willfitch
Block user comment: N
Private report: N
New Comment:
Cannot reproduce. This is probably your kernel OOM killer tricking you.
cli -d error_reporting=-1 -d memory_limit=5M -r '$pdo = new
PDO("pgsql:user=phptest dbname=phptest"); $stm = $pdo->query("select
repeat(\x27a\x27, 5*1024*1025) as data"); var_dump($stm->fetchAll());'
Fatal error: Allowed memory size of 5242880 bytes exhausted at
/home/mike/src/php-5.4/ext/pdo/pdo_stmt.c:641 (tried to allocate 5248001 bytes)
in Command line code on line 1
Previous Comments:
[2012-12-19 00:09:58] amex at bucksvsbytes dot com
Yes, my PHP development system displays every error, warning, and notice on
screen.
[2012-12-18 21:17:38] willfi...@php.net
Without looking into this too far, have you verified that
error_reporting/display_errors are set to levels that are sufficient to display
or
record this error?
[2012-11-29 00:25:41] amex at bucksvsbytes dot com
Description:
In PHP 5.3.10 and PostgreSQL 9.1, when executing PDOStatement::fetchAll(), if
the retrieved data busts the PHP memory limit, the script dies quietly, without
throwing an "out of memory" error.
Test script:
---
//ini_set('memory_limit','256M');
$dsn=;//appropriate Data Source Name string
$sql=;//any query that returns slightly more data than the PHP memory limit
allows (default limit is 128 MB on my server)
$db=new PDO($dsn);
$result=$db->query($sql);
$datarray=$result->fetchAll();//fetch all rows into an array
Expected result:
When fetchAll() retrieves too much data, the script dies quietly, instead of
throwing an "out of memory" error.
When I uncomment the first line, the script runs to completion, thus proving
that the quiet death was due to lack of memory.
The problem seems to relate to the postgresql driver, as the same thing happens
when I use pg_connect/pg_query/pg_fetch_all instead of PDO to get data from the
same query.
This is the only PHP "out of memory" condition I've ever seen where no error is
thrown.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63642&edit=1
Bug #65499 [Opn->Fbk]: json_decode reports invalid literal as valid JSON
Edit report at https://bugs.php.net/bug.php?id=65499&edit=1 ID: 65499 Updated by: m...@php.net Reported by:m dot kurzyna at crystalpoint dot pl Summary:json_decode reports invalid literal as valid JSON -Status: Open +Status: Feedback Type: Bug Package:JSON related Operating System: Linux PHP Version:5.5.2 Block user comment: N Private report: N New Comment: Cannot reproduce. Do you use Debian/Ubuntu/Fedora? Report there. Previous Comments: [2013-08-22 08:15:54] m dot kurzyna at crystalpoint dot pl To be more precise - introduced regression casts the string to integer so technically it takes all first digits just like (int)"123abc" would do. [2013-08-22 08:00:25] m dot kurzyna at crystalpoint dot pl Description: There is a regression in json_decode starting with PHP5.5 (5.4.x works as expected). json_decode() now treats literals staring with an integer as valid JSON consisting only of the first character. Test script: --- https://bugs.php.net/bug.php?id=65499&edit=1
Req #44522 [Opn->Csd]: http upload max_limits and file above 2GB
Edit report at https://bugs.php.net/bug.php?id=44522&edit=1 ID: 44522 Updated by: m...@php.net Reported by:mail2lv at yahoo dot com Summary:http upload max_limits and file above 2GB -Status: Open +Status: Closed Type: Feature/Change Request Package:*Web Server problem Operating System: All PHP Version:5.2.5 -Assigned To: +Assigned To:mike Block user comment: N Private report: N New Comment: The fix for this bug has been committed. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Fixed in master on x86_64 Previous Comments: [2013-07-01 10:32:22] lang at b1-systems dot de Newest Mailing List feedback applied. Pull Request attached. Please pull or comment in github or here. [2013-04-19 20:21:34] azet at azet dot org Could you please add this patch? It MIGHT make seem PHP less an embarrassing language than it is already. Sincerely, The Internet [2013-04-19 09:37:22] scroogie at scroogie dot de In my opinion this is quite an issue. We faced it at an intranet side yesterday. Due to the cast to int at https://github.com/php/php-src/blob/master/main/rfc1867.c#L901 it also has weird side effects, like setting 4G will equal 0 and disable the size check (see https://github.com/php/php-src/blob/master/main/rfc1867.c#L1031), 5G equal 1G etc. [2012-03-26 04:02:16] jason at infininull dot com I have re-rolled the patch against HEAD (b4d078f18c950a4bf7e136443586e348bd54f40c) and attached it to this request. [2012-03-24 18:42:45] jason at infininull dot com I was recently bitten by this bug too. The patch needed a little updating for 11.04 and I also found a couple of other issues. 1) Uploads only work if upload_max_filesize = 0 and 2) The $_FILES[*]['size'] value is an overflowed integer. The attached patch fixes these issues. I am currently in the process of re-rolling the patch against HEAD on master to get this in to upstream. 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 https://bugs.php.net/bug.php?id=44522 -- Edit this bug report at https://bugs.php.net/bug.php?id=44522&edit=1
Bug #65751 [Opn->Nab]: isset() and empty() hides illegal offset warning
Edit report at https://bugs.php.net/bug.php?id=65751&edit=1 ID: 65751 Updated by: m...@php.net Reported by:anton dot polonskiy at gmail dot com Summary:isset() and empty() hides illegal offset warning -Status: Open +Status: Not a bug Type: Bug Package:*General Issues Operating System: Ubuntu 13.04 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2013-09-24 11:03:26] anton dot polonskiy at gmail dot com Description: Manual says: "As of PHP 5.4 string offsets have to either be integers or integer-like strings, otherwise a warning will be thrown. Previously an offset like "foo" was silently cast to 0." That warning will suppressed by wrapping variable in isset() or empty(); http://3v4l.org/MEldp Test script: --- https://bugs.php.net/bug.php?id=65751&edit=1
Bug #65416 [Opn->Fbk]: output buffering autostart setting php.ini
Edit report at https://bugs.php.net/bug.php?id=65416&edit=1 ID: 65416 Updated by: m...@php.net Reported by:jwestbrook at gmail dot com Summary:output buffering autostart setting php.ini -Status: Open +Status: Feedback Type: Bug Package:Output Control Operating System: linux 64bit AWS ami PHP Version:5.4.17 Block user comment: N Private report: N New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2013-08-27 00:42:36] jwestbrook at gmail dot com Extensions string(4) "Core" [1]=> string(4) "date" [2]=> string(4) "ereg" [3]=> string(6) "libxml" [4]=> string(7) "openssl" [5]=> string(4) "pcre" [6]=> string(4) "zlib" [7]=> string(3) "bz2" [8]=> string(8) "calendar" [9]=> string(5) "ctype" [10]=> string(4) "hash" [11]=> string(6) "filter" [12]=> string(3) "ftp" [13]=> string(7) "gettext" [14]=> string(3) "gmp" [15]=> string(3) "SPL" [16]=> string(5) "iconv" [17]=> string(10) "Reflection" [18]=> string(7) "session" [19]=> string(8) "standard" [20]=> string(5) "shmop" [21]=> string(9) "SimpleXML" [22]=> string(7) "sockets" [23]=> string(8) "mbstring" [24]=> string(9) "tokenizer" [25]=> string(3) "xml" [26]=> string(14) "apache2handler" [27]=> string(7) "gearman" [28]=> string(4) "http" [29]=> string(4) "ssh2" [30]=> string(4) "curl" [31]=> string(3) "dom" [32]=> string(8) "fileinfo" [33]=> string(2) "gd" [34]=> string(8) "igbinary" [35]=> string(4) "json" [36]=> string(4) "exif" [37]=> string(6) "mcrypt" [38]=> string(9) "memcached" [39]=> string(7) "mysqlnd" [40]=> string(5) "mysql" [41]=> string(6) "mysqli" [42]=> string(8) "newrelic" [43]=> string(3) "PDO" [44]=> string(9) "pdo_mysql" [45]=> string(10) "pdo_sqlite" [46]=> string(4) "Phar" [47]=> string(5) "posix" [48]=> string(4) "snmp" [49]=> string(4) "soap" [50]=> string(7) "sqlite3" [51]=> string(7) "sysvmsg" [52]=> string(7) "sysvsem" [53]=> string(7) "sysvshm" [54]=> string(4) "wddx" [55]=> string(9) "xmlreader" [56]=> string(9) "xmlwriter" [57]=> string(3) "xsl" [58]=> string(3) "zip" [59]=> string(5) "mhash" [60]=> string(12) "Zend OPcache" } string(14) "apache2handler" 12 requests where I was able to note that the output buffer failed out of 142 requests to that specific script. As a whole I average 150,000 PHP requests per day [2013-08-26 22:45:23] yohg...@php.net I guess there is some kind of memory problem. What modules are loaded in your web server and SAPI? or paste phpinfo() output. > at least 12 times a day PHP fails to start the output buffer and I get the error shown. How many requests a day you have? [2013-08-26 21:35:48] jwestbrook at gmail dot com @mike at php.net Yes that is the bug I'm reporting - the php.ini setting does not start the output buffer on every request. [2013-08-19 22:19:57] m...@php.net Looks like when this is logged, there actually is no output buffer active, so ob_get_length() returns false. [2013-08-19 22:07:01] jwestbrook at gmail dot com I also tried the settings of On and 1. I also understand that #!/usr/bin/php means nothing to output buffering but is output that I want to capture if the php file is being run from a browser and discard. >From what I understand that is not how the output buffering works. The way I >understand it the output buffer fills then dumps everything when it is full. In this instance before the output buffer fills I want to discard the first 15 characters because it will corrupt any binary files that the browser is trying to download. Based on the test script attached ob_get_length() should ALWAYS return 15 characters - however at least 12 times a day PHP fails to start the output buffer and I get the error shown. 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 https://bugs.php.net/bug.php?id=65416 -- Edit this bug report at https://bugs.php.net/bug.php?id=65416&edit=1
Req #42132 [Opn->Wfx]: suggest a fix for global object got destructed in output buffer handler
Edit report at https://bugs.php.net/bug.php?id=42132&edit=1 ID: 42132 Updated by: m...@php.net Reported by:xuefer at gmail dot com Summary:suggest a fix for global object got destructed in output buffer handler -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: gentoo linux PHP Version:5CVS-2007-07-28 (CVS) Block user comment: N Private report: N New Comment: http://3v4l.org/2ZsYF Previous Comments: [2007-07-29 23:41:10] j...@php.net See also bug #39546 and bug #39629 [2007-07-28 14:30:02] xuefer at gmail dot com Description: it seems that the implicit ob_end_flush() is called after object destructions. uncomment any ONE of the comments gives "okay". but this is not the official trick that supported by php. the php bug system suggest me this bug is by design in #39546 #39629 etc. there's many register_xxx arround my php files, which install data into a global object, and the output buffer handler will inject the data into the output in the correct place. if this bug is not fixed, the only way i can do is to rewrite the object into array/functions anyway, i have a suggested fix to change the work flow a bit: 1. flush and pop all OBs but leave 1 top OB on shutdown 2. destruct objects 3. flush the last OB if there's any no matter if this bug is gonna be fixed, there shall be a page that give explanation and work arround to this issue. Reproduce code: --- Expected result: okay Actual result: -- oops -- Edit this bug report at https://bugs.php.net/bug.php?id=42132&edit=1
Bug #61728 [Ver->Csd]: PHP crash when calling ob_start in session_write
Edit report at https://bugs.php.net/bug.php?id=61728&edit=1 ID: 61728 Updated by: m...@php.net Reported by:frederik_php at vanrenterghem dot biz Summary:PHP crash when calling ob_start in session_write -Status: Verified +Status: Closed Type: Bug Package:Reproducible crash Operating System: Linux Debian Wheezy PHP Version:5.4.0 Assigned To:laruence Block user comment: N Private report: N New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2012-04-16 11:19:10] larue...@php.net change the summary [2012-04-14 17:21:22] larue...@php.net assign to me, since I have made a try to fix it. will close this after confirm that fix is okey. [2012-04-14 17:18:02] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=3b42f184cdcf512fdc1f944052bfa296f17a035f Log: Fixed bug #61728 (php-fpm SIGSEGV running friendica on nginx) [2012-04-14 17:16:58] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=3b42f184cdcf512fdc1f944052bfa296f17a035f Log: Fixed bug #61728 (php-fpm SIGSEGV running friendica on nginx) [2012-04-14 16:59:05] larue...@php.net if you try to start a user output handler in session_write. then it will crash. I have attach a simple reproduce script. and also made a simple fix. 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 https://bugs.php.net/bug.php?id=61728 -- Edit this bug report at https://bugs.php.net/bug.php?id=61728&edit=1
Req #51579 [Opn->Fbk]: ob_gzhandler/header("304") incompatibility
Edit report at https://bugs.php.net/bug.php?id=51579&edit=1
ID: 51579
Updated by: m...@php.net
Reported by:boris at povolnam dot ru
Summary:ob_gzhandler/header("304") incompatibility
-Status: Open
+Status: Feedback
Type: Feature/Change Request
Package:Unknown/Other Function
Operating System: irrelevant
PHP Version:5.2.13
-Assigned To:
+Assigned To:mike
Block user comment: N
Private report: N
New Comment:
Please try a newer PHP version, though, usually, your web server should prevent
sending a body with 304 responses.
Previous Comments:
[2010-12-10 16:36:30] roan dot kattouw at gmail dot com
Clarification: the HTTP spec requires 304 responses be empty, and Firefox is
very particular about that. But ob_gzhandler gzips even empty responses, and
gzipping the empty string does not return the empty string (GZIP header, at
least).
Proposed solution: if there was no output (empty buffer), do not compress and
do not send Content-Encoding:gzip
[2010-04-17 01:22:02] boris at povolnam dot ru
Description:
test script below will produce a response with not empty body (it will contain
gzip stream header) which breaks the W3C standart that requires 304 response to
have empty body.
The idea was to speed up things with compression and leveraging client side
caching, but end up firefox (v.3.6.3) prepending with that body some of
conseqent responces (css file in my case, which broken styles rendering - that
was really really hard to find - i just coudn't understand why my server
returns corrupted file and only to firefox)
Test script:
---
Expected result:
ob_gzhandler() to look into response headers and wipe out buffer and disable
compression if 304 is set. Cause it's a subtle thing about 304 header, its body
and the way ob_gzhandler() works and others can run into same problem while
trying to speed up website as compression and client-side caching are 2 main
things to do.
--
Edit this bug report at https://bugs.php.net/bug.php?id=51579&edit=1
Bug #63299 [Opn->Nab]: call to ldap_search returns null
Edit report at https://bugs.php.net/bug.php?id=63299&edit=1
ID: 63299
Updated by: m...@php.net
Reported by:php at monona dot us
Summary:call to ldap_search returns null
-Status: Open
+Status: Not a bug
Type: Bug
Package:LDAP related
Operating System: Windows
PHP Version:5.3.17
Block user comment: N
Private report: N
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Remove the error suppression operator (@) and you'll most probably see an error
message about wrong function arguments.
Previous Comments:
[2012-10-18 05:36:47] php at monona dot us
Description:
---
>From manual page:
>http://www.php.net/function.ldap-search#refsect1-function.ldap-search-returnvalues
---
The documentation for function ldap_search says that it will either return a
resource or it will return a boolean false.
I have successfully bound to a microsoft Active Directory using ldap_connect
and ldap_bind. When I call ldap_search with a null for the forth
parameter($attributes) it returns a null while setting ldap_error() to "Sucess"
and ldap_errno() to zero.
The reason for passing a null for $attributes is so that I can explicity set a
limit using the sixth parameter ($sizelimit) and because I want everything
passed back, as if I had called ldap_search with only three parameters.
Another factor that probably contributes to creating this bug is that if I make
the call to ldap_search with just 3 paramters, it returns false with error set
to "Operations error" and errno set to 1 so there is obviously something else
wrong with the search.
I would prefer that either this condition return false and a specific error
message if there is something about the null $attributes that is an error or
that it return false/1/Operations error because that error is in fact still
true or that the documentation be updated to reflect when/why this function can
return null/o/success when in fact there is nothing successful about the call.
Test script:
---
ldap://xx');
ldap_set_option($ad, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($ad, LDAP_OPT_REFERRALS, 0);
ldap_bind($ad);
// replace xx etc. with your base DN
$result=@ldap_search($ad,'dc=xx,dc=com','(objectClass=*)',null,1,10);
if(!$result){
die('Could not search AD because '.ldap_error($ad).'('.ldap_errno($ad).')');
}
ldap_unbind($ad);
?>
Expected result:
return false
ldap_error() returns 'Operation error'
ldap_error() errno=1
or
return false
ldap_error() returns 'Some message about invalid $attributes parameter'
ldap_errno() returnd unique error number for above
Actual result:
--
Return value of NULL
ldap_error() returns 'Success'
ldap_errno() returns 0
--
Edit this bug report at https://bugs.php.net/bug.php?id=63299&edit=1
Bug #64392 [Opn->Fbk]: ldap_search() fails on base64-encoded entries
Edit report at https://bugs.php.net/bug.php?id=64392&edit=1 ID: 64392 Updated by: m...@php.net Reported by:russ at bluecows dot com Summary:ldap_search() fails on base64-encoded entries -Status: Open +Status: Feedback Type: Bug Package:LDAP related Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2013-03-08 15:53:22] russ at bluecows dot com Description: When using the ldap_search() function to query data from an LDAP database, it would appear that base64-encoded attributes are not decoded before running the search pattern against them. Based on the code snippets below, if the first search is run, no results are returned, even if a DN in the search tree has a postalAddress attribute which matches the given search string. If the second search is run, results are returned, indicating the search can check to see if the attribute exists at all, but the text-based search string is being checked against a base64-encoded attribute. It would appear that ldap_get_entries() decodes base64-encoded attributes, because the output of $entries, when it is not NULL, will show postalAddress as text. In order for ldap_search() to work properly, it should decode base64-encoded attributes before attempting to run the search against them. Test script: --- Failed test: $search = ldap_search( $ldapHandle, $ldapBaseDn, "(postaladdress=*165 Main*)" ); $entries = ldap_get_entries( $ldapHandle, $search ); Successful test: $search = ldap_search( $ldapHandle, $ldapBaseDn, "(postaladdress=*)" ); $entries = ldap_get_entries( $ldapHandle, $search ); Expected result: In the failed test example, I would expect $entries to contain a list of LDAP DNs and associated attributes where the postalAddress attribute matches the search parameter. Currently, it does not. Searches against non-base64-encoded attributes such as mail or telephoneNumber work as expected. Actual result: -- When the failed test example is run, $entries is empty because no matches are returned from the ldap_search(). -- Edit this bug report at https://bugs.php.net/bug.php?id=64392&edit=1
Bug #60614 [Opn->Nab]: Rebinding always results in false return from bind()
Edit report at https://bugs.php.net/bug.php?id=60614&edit=1
ID: 60614
Updated by: m...@php.net
Reported by:david dot kit at cookmedical dot com
Summary:Rebinding always results in false return from bind()
-Status: Open
+Status: Not a bug
Type: Bug
Package:LDAP related
Operating System: Windows XP Pro SP3
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
ldap_unbind/ldap_close are jsut aliases.
Previous Comments:
[2011-12-28 04:42:59] david dot kit at cookmedical dot com
Description:
---
>From manual page: http://www.php.net/function.ldap-bind#refsect1-function.ldap-
bind-description
---
I reproduced a problem where connecting to an LDAP server, and then binding to
an
address I know to exist and work will perform perfectly.
Within the same script, following an unbind (as I don't need the connection to
be
binded any more), using ldap_bind(..) again [even the same user and password as
the original] would result in a fail.
Test script:
---
// Assume variables all set in working order below...
$ldapconn = ldap_connect($ldaphost, $ldapport) or die("Could Not Connect to
$ldaphost");
$ldapbind = ldap_bind($ldapconn, $ldaprdn, $ldappass);
// bind successful
ldap_unbind($ldapconn);
$ldapbind = ldap_bind($ldapconn, $ldaprdn, $ldappass);
// second bind unsuccessful!?
ldap_close($ldapconn);
// close ldap connection
Expected result:
after unbind, the bind function will work normally
Actual result:
--
after unbind, bind function always fails.
if initial bind has not been unbinded, then subsequent bind (even for
same/different user) will work correctly.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60614&edit=1
Bug #51638 [Opn->Fbk]: LDAP and Referrals
Edit report at https://bugs.php.net/bug.php?id=51638&edit=1
ID: 51638
Updated by: m...@php.net
Reported by:marco at forgetaboutit dot net
Summary:LDAP and Referrals
-Status: Open
+Status: Feedback
Type: Bug
Package:LDAP related
Operating System: ALL
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
What LDAP library do you use? Does it support referrals?
Previous Comments:
[2011-02-26 20:19:04] marco at forgetaboutit dot net
I have now spent quite a lot of time working on this issue, and looking at
tcpdumps it is very clear that there are major issues in the way php handles
add, modify and delete referrals. I believe this is due to the fact that the
tests used to validate the code are also wrong, so the code is believed to be
good, when it isn't. I will be submitting an alternative way of doing referrals
by switching off the php method and doing it with three new functions which I
will post on the ldap_set_rebind_proc documentation page once I know it is at
least working. I do not have enough skills to work on php source code but would
be more than happy to assist a programmer with little or no ldap knowledge if
that would help.
[2010-10-23 15:26:14] ka...@php.net
After reviewing this bug some more, it looks more to me like its an actual
issue in the ldap extension in PHP, so moving it to that category where
hopefully one of the maintainers can pick it up and decide if its indeed an
issue in the ldap extension or lacking documentation.
[2010-07-20 15:40:35] art dot vanscheppingen at spilgames dot com
We have the exact same problem.
Referrals do work correctly using the cli ldapmodify and with the exact same
setup it doesn't work under PHP.
I tried setting the LDAP_OPT_REFERRALS to either 1, LDAP_OPT_ON and true, but
neither of them resulted in anything else than the default -1. Setting the
value to 0 does have effect though, but doesn't do anything either.
I set the LDAP server to a read only server, but that resulted in a LDAP error.
[2010-05-21 17:54:05] marco at forgetaboutit dot net
Doing some monitoring with TCPDUMP, I can confirm that the local LDAP server is
returning the correct referral information, and then the web server is
performing a DNS lookup on the ldap referral URL. Then it would seem that PHP
just tries the localhost again without running the procedure specified in
ldap_set_rebind_proc.
[2010-04-22 19:07:20] marco at forgetaboutit dot net
Description:
I am trying to get a php application to follow ldap referrals, specifically
when the local server is a slave, and is used as a read-only server for
performance reasons, but has to write to a master server in order to add,
modify or delete records.
As far as I can tell all I need are three things.
A) Set LDAP_OPT_REFERRALS to 1 using ldap_set_options()
B) Set a callback function using ldap_set_rebind_proc()
C) Create a very simple rebind function.
The problem is that there is no documentation on the subject. For example, when
I check LDAP_OPTS_REFERRALS using ldap_get_options(), I get an answer of either
0 (when I set it to 0 or false), and an answer of -1 (minus or dash 1) for any
other setting, including 1 and TRUE, and it appears that the callback function
isn't called.
If someone can explain how it is supposed to work enough for me to get it
working, I am happy to provide documentation / examples
Test script:
---
ldap_set_option($LDAP_CON, LDAP_OPT_REFERRALS, 1);
ldap_set_rebind_proc($LDAP_CON, rebind_on_referral);
...
function rebind_on_referral ($link_id, $ldap_url) {
$binddn = $_SESSION['ldapab']['binddn'];
$bindpw = $_SESSION['ldapab']['password'];
if (!ldap_bind($link_id,$binddn,$bindpw)) return 1; // Error
else return 0; // Success
}
Expected result:
callback function should be called, application should rebind to new ldap
server and user should notice nothing
Actual result:
--
PHP appears to ignore the referral and ldap_error returns a "referral" message.
--
Edit this bug report at https://bugs.php.net/bug.php?id=51638&edit=1
Bug #47786 [Asn->Fbk]: ldap_list get "Decoding error" on some specific searching attribute
Edit report at https://bugs.php.net/bug.php?id=47786&edit=1
ID: 47786
Updated by: m...@php.net
Reported by:tedc21thc at hotmail dot com
Summary:ldap_list get "Decoding error" on some specific
searching attribute
-Status: Assigned
+Status: Feedback
Type: Bug
Package:LDAP related
Operating System: FreeBSD 7.1
PHP Version:5.2.9
Block user comment: N
Private report: N
New Comment:
There's no difference in what PHP does for ldap_search and ldap_list, except
that ldap_lsit uses LDAP_SCOPE_ONELEVEL.
Previous Comments:
[2012-04-30 07:40:25] tedc21thc at hotmail dot com
please solve this problem for ldap_list(); ( see:#5433 for ldap_search(); )
[2010-12-24 10:41:38] tedc21thc at hotmail dot com
It seems be #5433 only fixed "ldap_search()" function,but not also fix
ldap_list() function.
please check again.
The problem is, it will get Decoding error (-4) when querying some OU and have
attributes.
When I get decoding error, and I use this function again with no argument
4(attributes), It will be fine.
samples:
When
$sr= @ldap_list($this->conn,$dn,$this->filter,$this->attrs);
ldap_errno($this->conn) sometimes will be -4
gets Decoding error, query fails.
Try use
$sr= @ldap_list($this->conn,$dn,$this->filter);
ldap_errno($this->conn) will be 0
and the data entries will be fine
[2010-12-24 10:31:38] tedc21thc at hotmail dot com
Hello there,
It seems be #5433 only fixed "ldap_search()" function,but not also fix
ldap_list() function.
please check again.
The problem is, it will get Decoding error (-4) when querying some OU and have
attributes.
When I get decoding error, and I use this function again with no argument
4(attributes), It will be fine.
samples:
When
$sr= @ldap_list($this->conn,$dn,$this->filter,$this->attrs);
ldap_errno($this->conn) sometimes will be -4
gets Decoding error, query fails.
Try use
$sr= @ldap_list($this->conn,$dn,$this->filter);
ldap_errno($this->conn) will be 0
and the data entries will be fine
[2009-04-08 01:00:00] 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".
[2009-04-01 01:53:45] tedc21thc at hotmail dot com
the problem is when I change the searching attribute from
("cn","mail","proxyaddresses","ou")
to any other
like... ("mail","cn","proxyaddresses","ou") <- only switching sorting
or... ("cn","mail","proxyaddresses","ou","something") <- add something or
remove something
or whatever
the result of ""LDAP_ERROR($ds)"" become success,
and I can get values from
$info = ldap_get_entries($ds, $sr);
and following steps.
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
https://bugs.php.net/bug.php?id=47786
--
Edit this bug report at https://bugs.php.net/bug.php?id=47786&edit=1
Bug #61450 [Opn]: oci8, open ldap not working
Edit report at https://bugs.php.net/bug.php?id=61450&edit=1
ID: 61450
Updated by: m...@php.net
Reported by:pratheeshrajan18 at gmail dot com
Summary:oci8, open ldap not working
Status: Open
Type: Bug
Package:LDAP related
Operating System: Linux
PHP Version:trunk-SVN-2012-03-20 (SVN)
-Assigned To:
+Assigned To:sixd
Block user comment: N
Private report: N
New Comment:
Hi Chris, could you have a quick look on this PR, please?
Previous Comments:
[2012-03-24 01:56:07] s...@php.net
The best solution is to build PHP without OCI8, and then build OCI8 as a shared
extension.
There are hack solutions that may or may not work like editing Makefile,
changing INCLUDES to remove the -I Oracle include directory, and adding that -I
option explicitly to every oci8*.c file.
Also see the patch https://github.com/cjbj/php-
src/commit/68b1abcd789711586c481feb12b985e5807ebeaa
[2012-03-20 10:14:17] pratheeshrajan18 at gmail dot com
changed to right package
[2012-03-20 10:10:18] pratheeshrajan18 at gmail dot com
Description:
ldap functionality is not working when i configure ldap and oci8 together.
I am getting "Out of memory" error while trying ldap. But, when i disabled
oci8, it worked well. Could some one help please..
My configuration looks like
'./configure' '--with-apxs2=/appl/apache3/bin/apxs' '--with-mysql=/appl/mysql/'
'--with-zlib' '--prefix=/appl/php5.2.9' '--enable-sockets' '--with-ldap'
'--with-oci8=instantclient,/usr/lib/oracle/11.1/client64/lib/'
'--enable-mbstring' '--with-mysqli' '--with-xmlrpc' '--with-libxml-dir'
'--with-openssl' '--with-pcre-dir' '--with-pspell' '--enable-soap'
'--with-xmlrpc' '--with-curl' '--enable-exif' '--with-gd'
I tried changing the order of ldap and oci8 in the config, that also didn't
work for me.
All thoughts welcome
Thanks,
Prats
Test script:
---
Sample code
---
ldap://ldap.example.com";;
$ldaprdn = "my user";
$ldappass = "my pass";
$ldap_conn = ldap_connect($ldapServer);
$ldapbind =ldap_bind($ldap_conn);
if($ldapbind) {
echo "success";
} else {
echo "LDAP-Errno: " . ldap_err2str(ldap_errno($ldap_conn)) . "\n";
echo "binding failed"; echo "";
Getting the ldap error no: 10.
Could any one have any idea ?
Thanks in advance :)
Prats.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61450&edit=1
Req #53358 [Opn->Csd]: API queries in php.ini
Edit report at https://bugs.php.net/bug.php?id=53358&edit=1 ID: 53358 Updated by: m...@php.net Reported by:pophal at tubit dot tu-berlin dot de Summary:API queries in php.ini -Status: Open +Status: Closed Type: Feature/Change Request Package:PHP options/info functions PHP Version:* -Assigned To: +Assigned To:mike Block user comment: N Private report: N New Comment: We already have SAPI INIs. Previous Comments: [2010-11-19 17:47:53] pophal at tubit dot tu-berlin dot de Description: I would rather appreciate a php ini section analogous to [HOST=] querying the SAPI, e.g. [SAPI=CLI] extension = php-gtk2.so in order to prevent the extension from being loaded when PHP is running as apache module or cgi. This would be helpful for distributions with like php.ini regardless of SAPI, in contrast to debian with its API-depending php.ini location. A workaround is a modified shebang line: #!/usr/bin/php -d extension=php_gtk2.so but this cannot be considered a good solution. Maybe this is not only php-gtk related. -- Edit this bug report at https://bugs.php.net/bug.php?id=53358&edit=1
Bug #54114 [Opn->Nab]: Output Buffer Dumps Data On Error
Edit report at https://bugs.php.net/bug.php?id=54114&edit=1
ID: 54114
Updated by: m...@php.net
Reported by:danhstevens at gmail dot com
Summary:Output Buffer Dumps Data On Error
-Status: Open
+Status: Not a bug
Type: Bug
Package:Output Control
Operating System: all
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
I'm not sure why this should be security related?
Why even output security sensitive information at all?
Previous Comments:
[2011-08-17 13:44:19] nicolas dot grekas+php at gmail dot com
Here is an other example that can't be workaround using danhstevens' technique:
[2011-03-10 19:41:28] danhstevens at gmail dot com
I've found a viable work-around for this bug (although a patch of the core
would still be ideal so people don't discover this potential security issue the
hard-way).
By registering the following shutdown handler before any output buffering the
dump of data can be prevented:
1)
{
//Prevent data in buffer from dumping
ob_end_clean();
}
}
register_shutdown_function('shutdown_fn');
Now when using the examples above that normally cause the buffer to dump to the
client the buffer data is disposed of. Of course, this can be extended to use
ob_get_contents and redirect the data to file or other means if necessary. This
approach is working for me (on PHP 5.3.5).
~Dan
[2011-03-06 16:51:52] neweracracker at gmail dot com
I've managed to reproduce this in Windows 7 running php 5.2.17 (with
php.ini-dist) and php 5.3.5 (with php.ini-development).
Here is my test script:
I've reported this as bug #54174 which got closed due being a dupe of this one
so I am leaving this comment here for reference purposes.
Regards,
NewEraCracker.
[2011-02-28 21:40:36] danhstevens at gmail dot com
Hi Rasmus,
I was still able to create the problem by calling on a non-existing class to
create a fatal error. Here is a variation of your code:
function eh($errno, $errstr, $errfile, $errline) {
$contents = ob_get_contents();
ob_end_clean();
echo "Error: $errno, $errstr, $errfile, $errline\n";
}
set_error_handler('eh');
ob_start();
echo 123;
nonExistantClass::nonExistantMethod();
echo "After error\n";
Output is:
123
Fatal error: Class 'nonExistantClass' not found in ...
Hopefully the above should more accurately illustrate the issue.
[2011-02-28 19:37:32] ras...@php.net
I am unable to reproduce this. My test script:
https://bugs.php.net/bug.php?id=54114
--
Edit this bug report at https://bugs.php.net/bug.php?id=54114&edit=1
Req #64488 [Opn->Dup]: Allow open tag to "discard the previous shebang"
Edit report at https://bugs.php.net/bug.php?id=64488&edit=1
ID: 64488
Updated by: m...@php.net
Reported by:php at richardneill dot org
Summary:Allow open tag to "discard the previous shebang"
-Status: Open
+Status: Duplicate
Type: Feature/Change Request
Package:CGI/CLI related
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
See req #31563
Previous Comments:
[2013-03-22 23:46:17] bobwei9 at hotmail dot com
It's principally a good idea, but a function is very complicated to realize as
the shebang is already sent when the function will be called.
What I'd prefer is erasing the shebang line every time in a non-cli script when
the two first bytes are '#' and '!'. (I'd wonder if there exist some people who
really begin the content of their websites with a #!...)
[2013-03-22 10:32:27] php at richardneill dot org
Description:
It would be really useful to be able to write single files that would run
cleanly
as *either* CGI or CLI scripts.
At the moment, the closing '?>' tag will eat the trailing newline.
So, similarly, I'd like to request a way for the opening '";
}else{
echo "I am CLI\n";
}
?>
Expected result:
Exactly one line should be printed:
"I am CLI|CGI"
Actual result:
--
In CLI mode, this script cleanly prints:
"I am CLI"
but in Apache mode, the script prints the first line literally:
"#!/usr/bin/php
I am CGI"
It's relatively easy to work around this with a wrapper script, but I'd
appreciate the elegance of having a single file that can operate in both modes.
Thank you for your time.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64488&edit=1
Bug #51749 [Opn->Nab]: header("Location:") changing HTTP status
Edit report at https://bugs.php.net/bug.php?id=51749&edit=1
ID: 51749
Updated by: m...@php.net
Reported by:theimp at iinet dot net dot au
Summary:header("Location:") changing HTTP status
-Status: Open
+Status: Not a bug
Type: Bug
Package:HTTP related
Operating System: Debian Lenny
PHP Version:5.3.2
Block user comment: N
Private report: N
New Comment:
So, nothing new here, closing.
Previous Comments:
[2010-05-30 00:41:43] theimp at iinet dot net dot au
The patch no-http-status-code-overwrite-on-location-header (last revision
2010-05-29 20:00 UTC) is a patch to main/SAPI.c from 5.3.2 (04 Mar 2010).
The relevant changes are lines 661 to 665 (661 to 668 in the original), and 675
to 678 (678 in the original).
I deliberately chose the simplest method I could; it simply checks to see if
the status is currently 200, and if so, then it updates the status code as
before. Otherwise, it does not.
As mentioned, the behavior that is the subject of this bug has been a
non-problem for a very long time. I am more and more inclined to agree with
mike at php dot net that "fixing" it just might not be worth it, when compared
against the possibility of failures related to backwards-compatibility
expectations. But aharvey at php dot net does have a valid point too.
A method I considered, but rejected as too inefficient (considering the
benefit), involved creating a new variable to store the status when set, and
only write it just before the headers are sent.
Another similar method that I considered, which was more efficient, but that I
rejected for being too dangerous and fault-prone, was making the default HTTP
response value 0 (or any other invalid value) and, again, updating it to 200 if
it was still set to 0 (meaning that it hadn't been updated) before the headers
were about to be sent.
These changes involve much more significant modification for very little
additional benefit. The only case where they would improve the patch code is if
you set the HTTP code to some number, and then set the HTTP code back to 200,
and then sent a Location or similar header; you might expect it not to change
(because you've explicitly set it), but it would change (because it's currently
200, and that's the only condition that is checked).
(Also, the code on lines 665-666 of the original is redundant in the current
code because it would always be performed again at 752).
Please note that I am not necessarily saying that I think this patch should be
applied. In fact, after reading the source code, I think that - if anything -
my complaint really should simply be a documentation bug (ie; that setting a
Status header, last, is the preferred method of setting the response code, and
clarifications related to the correct use of http_response_code).
(Should have read the source code first, I guess. For example, it's now
painfully clear that PHP follows RFC 3875 as closely as possible).
Thank you for your consideration.
[2010-05-20 09:17:43] m...@php.net
Heh, you're quite patient either ;)
I think the most SAPI-portable way to set the HTTP status is:
header("Status: NNN", true, NNN);
Still, special headers like Location and WWW-Authenticate might override it
again, so it's best to set the HTTP status at last.
If you want to know more about the "hack", visit sapi_header_op() in main/SAPI.c
Cheers
PS: patches are always welcome, even if the just cause a discussion without
following changes
[2010-05-20 08:51:06] theimp at iinet dot net dot au
> header("HTTP/1.1 XXX") is just a hack
I did not realize this. So does that mean that, per RFC 3875, we're only
supposed to set the Status header and hope that the server does what we expect?
The documentation specifically lists this "hack" as the correct way to supply
the Status-Line and, therefore, the Response Code. But I'm not going to argue
with you about this.
> I see no hard reason to introduce other hacks to support a hack in the first
> place.
Well, that's fair enough.
> You are writing *pages*
I apologize. I tend to use far more words than I have to, in anticipation of
explaining myself poorly otherwise. I will try to be more concise. Many of the
details I felt were essential for understanding how the fix SHOULD be handled,
distinct from my personal preferences.
> about code that's *years* old and worked that way for a long long time, and
> there's very little chance to become that changed.
I understand from this, that you do not want to fix this in the way I have
Bug->Req #54588 [Opn->Dup]: Included files should not output shebang
Edit report at https://bugs.php.net/bug.php?id=54588&edit=1 ID: 54588 Updated by: m...@php.net Reported by:djones109 at gmail dot com Summary:Included files should not output shebang -Status: Open +Status: Duplicate -Type: Bug +Type: Feature/Change Request Package:Output Control Operating System: All PHP Version:5.3SVN-2011-04-21 (snap) Block user comment: N Private report: N New Comment: See req #31563 Previous Comments: [2011-04-21 21:50:21] djones109 at gmail dot com Description: When writing CLI scripts, one typically adds a shebang to the beginning of the script. When the script is executed, the shebang is not outputted. On occasion, it's useful to include another CLI script. When the file is included, the shebang on the included file is outputted, contrary to expected behavior. Test script: --- file1.php: #!/usr/bin/php file2.php: #!/usr/bin/php Expected result: Including file2 Inside file2 Actual result: -- Including file2 #!/usr/bin/php Inside file2 -- Edit this bug report at https://bugs.php.net/bug.php?id=54588&edit=1
Bug #54114 [Nab]: Output Buffer Dumps Data On Error
Edit report at https://bugs.php.net/bug.php?id=54114&edit=1
ID: 54114
Updated by: m...@php.net
Reported by:danhstevens at gmail dot com
Summary:Output Buffer Dumps Data On Error
Status: Not a bug
Type: Bug
Package:Output Control
Operating System: all
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Well, this is pretty much the wrong
way then, IMO. Is this about Symfony 1 or 2?
Previous Comments:
[2013-09-30 14:58:14] danhstevens at gmail dot com
Mike, this is a security issue because users of frameworks like Symfony are
highly
exposed to this bug. Symfony uses OB for parsing configuration files which
often
contain sensitive information. One syntax error in your config file and all
your
config params are on display to the www. It's unexpected behavior, and it can
(and
in my case, has) caused the release of sensitive information.
[2013-09-30 12:11:25] m...@php.net
I'm not sure why this should be security related?
Why even output security sensitive information at all?
[2011-08-17 13:44:19] nicolas dot grekas+php at gmail dot com
Here is an other example that can't be workaround using danhstevens' technique:
[2011-03-10 19:41:28] danhstevens at gmail dot com
I've found a viable work-around for this bug (although a patch of the core
would still be ideal so people don't discover this potential security issue the
hard-way).
By registering the following shutdown handler before any output buffering the
dump of data can be prevented:
1)
{
//Prevent data in buffer from dumping
ob_end_clean();
}
}
register_shutdown_function('shutdown_fn');
Now when using the examples above that normally cause the buffer to dump to the
client the buffer data is disposed of. Of course, this can be extended to use
ob_get_contents and redirect the data to file or other means if necessary. This
approach is working for me (on PHP 5.3.5).
~Dan
[2011-03-06 16:51:52] neweracracker at gmail dot com
I've managed to reproduce this in Windows 7 running php 5.2.17 (with
php.ini-dist) and php 5.3.5 (with php.ini-development).
Here is my test script:
I've reported this as bug #54174 which got closed due being a dupe of this one
so I am leaving this comment here for reference purposes.
Regards,
NewEraCracker.
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
https://bugs.php.net/bug.php?id=54114
--
Edit this bug report at https://bugs.php.net/bug.php?id=54114&edit=1
Bug #61548 [Opn->Csd]: content-type must appear at the end of headers for 201 Location to work in http
Edit report at https://bugs.php.net/bug.php?id=61548&edit=1
ID: 61548
Updated by: m...@php.net
Reported by:david at greenseedtechnologies dot com
Summary:content-type must appear at the end of headers for
201 Location to work in http
-Status: Open
+Status: Closed
Type: Bug
Package:HTTP related
Operating System: linux
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of mike
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=18b04b480ebc41841b2004cc11797eda40fb3958
Log: Fixed bug #61548
Previous Comments:
[2012-03-28 22:14:35] david at greenseedtechnologies dot com
Description:
Line 445 of http_fopen_wrapper.c
only works of the content-type is at the end of a list of header fields in the
context. It fails if it is in the middle, or the beginning.
memmove(tmp, tmp + (s2 + 1 - tmp_c), tmp_c + l - 1 - s2);
To see the problem watch the HTTP stream in something like WireShark.
Test script:
---
null
."AnyHeader: 1\r\n"
// BUG on line 445 of http_fopen_wrapper.c of PHP: content_type cannot be
in the middle of headers.
."Content-type: anythingyouwanthere\r\n"
."SomeOtherHeader: 2\r\n"
);
/*
PHP incorrectly sends across when following the "Location":
GET /services/storm/lead HTTP/1.0
Host: storm
SomeOtherHeader: 2ent-type: anythingyouwanthere
SomeOtherHeader: 2
*/
$http['method'] = 'POST';
$options = array('http' => $http);
$context = stream_context_create($options);
$result =
file_get_contents('http://some/url/that/resturns/201/and/has/a/Location/in/the/header',
false, $context);
Expected result:
GET /services/storm/lead HTTP/1.0
Host: storm
AnyHeader: 1
SomeOtherHeader: 2
Actual result:
--
GET /services/storm/lead HTTP/1.0
Host: storm
SomeOtherHeader: 2ent-type: anythingyouwanthere
SomeOtherHeader: 2
--
Edit this bug report at https://bugs.php.net/bug.php?id=61548&edit=1
Bug #65796 [Opn->Nab]: mkdir creates folders with wrong permissions
Edit report at https://bugs.php.net/bug.php?id=65796&edit=1
ID: 65796
Updated by: m...@php.net
Reported by:cmfcmf dot flach at gmail dot com
Summary:mkdir creates folders with wrong permissions
-Status: Open
+Status: Not a bug
Type: Bug
Package:Directory function related
Operating System: Linux/Ubuntu 13.4
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Check your umask.
Previous Comments:
[2013-10-01 09:48:19] d...@php.net
I get the same on PHP 5.5.3. chmod('test', 0777) then transforms the directory
to
the right chmod.
[2013-10-01 09:44:10] cmfcmf dot flach at gmail dot com
Description:
Creating a directory using mkdir() does not respect the permissions given.
Test script:
---
https://bugs.php.net/bug.php?id=65796&edit=1
Bug #58772 [Opn->Fbk]: PDO::fetchAll() issue with INSERT on view
Edit report at https://bugs.php.net/bug.php?id=58772&edit=1 ID: 58772 Updated by: m...@php.net Reported by:michael dot leuthold at googlemail dot com Summary:PDO::fetchAll() issue with INSERT on view -Status: Open +Status: Feedback Type: Bug -Package:PDO_PGSQL +Package:*General Issues Operating System: Linux / Debian PHP Version:5.2.6 Block user comment: N Private report: N New Comment: Your reproduce scripts are not available anymore and PQresultStatus for an INSERT that that resolves to a RULE with an SELECT as last statement returns PGRES_COMMAND_OK, so the result is freed regardless. Previous Comments: [2009-07-23 11:19:19] michael dot leuthold at googlemail dot com Description: "ON INSERT" rule on view returns rows which cannot be retrieved by PDO::fetchAll(): We have a view that has a ON INSERT DO INSTEAD rule. In this rule the insert on the view is basically split to do the actual inserts into the individual tables. In the end it SELECTs the new row (which has just been created) from that view. Doing this in psql for example behaves like expected: after the INSERT the new row is returned. We haven't managed to retrieve that row into an array via "PDO::fetchAll(PDO::FETCH_ASSOC)" - for some reason PDO seems to ignore that returned data - though PDO::rowCount returns 1 (actually it does always return 1 no matter how many rows are expected to be returned by that INSERT). This scenario works as expected when connected via PHP's pg_connect using pg_fetch_all. Information from phpinfo(): pdo_pgsql PDO Driver for PostgreSQL enabled PostgreSQL(libpq) Version 8.3.7 Module version 1.0.2 Revision$Id: pdo_pgsql.c,v 1.7.2.11.2.2 2007/12/31 07:20:10 sebastian Exp $ Reproduce code: --- For a small schema setup run this file through psql: http://www.byoc.de/pdo-pgsql.sql.txt This script inserts to the created example view and tries to retrieve the values: http://www.byoc.de/pdo-pgsql.php.txt Expected result: the associative array should contain all rows returned by the INSERT statement. Actual result: -- an empty array is returned by PDO::fetchAll though there are rows returned. -- Edit this bug report at https://bugs.php.net/bug.php?id=58772&edit=1
Bug #58580 [Opn->Wfx]: package can not be installed on debian
Edit report at https://bugs.php.net/bug.php?id=58580&edit=1 ID: 58580 Updated by: m...@php.net Reported by:jwspam1 at gmail dot com Summary:package can not be installed on debian -Status: Open +Status: Wont fix Type: Bug -Package:PDO_PGSQL +Package:*General Issues Operating System: Debian 5.0 PHP Version:5.2.5 Block user comment: N Private report: N New Comment: PECL PDO packages are obsolete. Previous Comments: [2009-03-09 16:41:58] jwspam1 at gmail dot com Description: pecl install pdo_pgsql gives the following error: checking for pg_config: not found configure:error: cannot find libpg-fe.h please specify correct postgresql installation path -- Edit this bug report at https://bugs.php.net/bug.php?id=58580&edit=1
Bug #57396 [Opn->Fbk]: The pdo_psql not support array[x:y]?
Edit report at https://bugs.php.net/bug.php?id=57396&edit=1 ID: 57396 Updated by: m...@php.net Reported by:jacch dot tw at gmail dot com Summary:The pdo_psql not support array[x:y]? -Status: Open +Status: Feedback Type: Bug -Package:PDO_PGSQL +Package:*General Issues Operating System: Mandriva 2006 PHP Version:5.2.0 RC4 Block user comment: N Private report: N New Comment: Should be gone since fixing bug #64953 Please try PHP-5.4.20 or newer. Previous Comments: [2006-11-26 11:58:25] jacch dot tw at gmail dot com Description: I'm tring pgsql array on php5.2 pdo_pgsql object, but I found this problem on my php machine. when i query this sql string ,it cann't run on my machine. "select array_to_string(array[1:10],";") from sometable limit 30" , this cann't work. but !! "select array_to_string(array,";") from sometable limit 30" it work !! So ,how can I do for this problem; -- Edit this bug report at https://bugs.php.net/bug.php?id=57396&edit=1
Bug #56082 [Opn->Wfx]: install fails - can't find krb5.h
Edit report at https://bugs.php.net/bug.php?id=56082&edit=1 ID: 56082 Updated by: m...@php.net Reported by:matt at kynx dot org Summary:install fails - can't find krb5.h -Status: Open +Status: Wont fix Type: Bug -Package:PDO_PGSQL +Package:*General Issues Operating System: RedHat 9 PHP Version:5CVS-2004-05-30 (dev) Block user comment: N Private report: N New Comment: PECL PDO packages are obsolete. Previous Comments: [2004-05-30 11:28:59] matt at kynx dot org Description: On RedHat 9, the file krb5.h required for installation of this package is located in /usr/kerebos/include where make cannot find it. To get this package to install, run $ CFLAGS="-I/usr/kerberos/include"; export CFLAGS before you run the pear install. -- Edit this bug report at https://bugs.php.net/bug.php?id=56082&edit=1
Req #57734 [Opn->Wfx]: PECL version of PDO_PGSQL is very out of date
Edit report at https://bugs.php.net/bug.php?id=57734&edit=1 ID: 57734 Updated by: m...@php.net Reported by:bill dot w dot farrar at gmail dot com Summary:PECL version of PDO_PGSQL is very out of date -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:PDO_PGSQL +Package:*General Issues Operating System: Linux PHP Version:5.2.1 Block user comment: N Private report: N New Comment: PECL PDO packages are obsolete. Previous Comments: [2007-07-06 13:56:02] bill dot w dot farrar at gmail dot com Description: Having just been bitten by this bug: http://bugs.php.net/bug.php?id=36681 I've done a little digging and found that while the bug is indeed fixed in the bundled version of the driver, it isn't in the latest PECL version. In fact, the latest pecl version (1.0.2) was released over a year ago, which probably means there have been many bugs fixed since then. This goes against the PDO documentation on the php.net site, which recommends using the PECL version of PDO so you get updates quicker. Expected result: Either a new release of PDO_PGSQL (and possibly other drivers) that at least match the version bundled in with php, or the deprecation of the PECL versions of these extensions with the documentation updated to this effect. Actual result: -- Reality doesn't appear to match the advice on the php documentation page for PDO. :( -- Edit this bug report at https://bugs.php.net/bug.php?id=57734&edit=1
Req #57741 [Opn->Fbk]: Support for COPY FROM STDIN statements
Edit report at https://bugs.php.net/bug.php?id=57741&edit=1 ID: 57741 Updated by: m...@php.net Reported by:sebastianmarconi at gmail dot com Summary:Support for COPY FROM STDIN statements -Status: Open +Status: Feedback Type: Feature/Change Request -Package:PDO_PGSQL +Package:*General Issues Operating System: All PHP Version:5.2.1 Block user comment: N Private report: N New Comment: Looks like current PDO_PGSQL has a COPY interface. Previous Comments: [2007-07-12 11:02:32] sebastianmarconi at gmail dot com Description: Would it be possible to have something like pg_copy_from? We use it a lot in migrations and data imports. Currently, we need to create a different connection using the old extension. -- Edit this bug report at https://bugs.php.net/bug.php?id=57741&edit=1
Req #57206 [Opn->Fbk]: Add ability to change auto_commit
Edit report at https://bugs.php.net/bug.php?id=57206&edit=1
ID: 57206
Updated by: m...@php.net
Reported by:tiggscharley at charter dot net
Summary:Add ability to change auto_commit
-Status: Open
+Status: Feedback
Type: Feature/Change Request
-Package:PDO_PGSQL
+Package:*General Issues
Operating System: FreeBSD 6.1-Release
PHP Version:5.1.4
Block user comment: N
Private report: N
New Comment:
What's wrong with BEGIN & COMMIT?
Previous Comments:
[2006-08-30 12:27:13] tiggscharley at charter dot net
Description:
Would it be possible to have the ability to change the value of
PDO::ATTR_AUTOCOMMIT within the PDO_PGSQL driver at will? Specifically, if a
connection is opened where PDO::ATTR_AUTOCOMMIT is true but there are certain
processes that span classes within the currently executing page that use the
same connection, it would be helpful to be able to selectively turn off
autocommit and turn it back on once the transactions are complete. Attempting
to set autocommit to off using $dbh->setAttribute ( PDO::ATTR_AUTOCOMMIT, false
) after the connection has been made results in an exception.
Reproduce code:
---
setAttribute(PDO::ATTR_AUTOCOMMIT, false);
?>
Expected result:
PDO::ATTR_AUTOCOMMIT to be set to false.
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message 'The auto-commit
mode cannot be changed for this driver' in /usr/local/www/test_autocommit.php:4
Stack trace:
#0 /usr/local/www/test_autocommit.php(4): PDO->setAttribute(0, false)
#1 {main}
thrown in /usr/local/www/test_autocommit.php on line 4
--
Edit this bug report at https://bugs.php.net/bug.php?id=57206&edit=1
Req #43593 [Opn->Fbk]: Impossible to disable Zend Memory Manager in anything other than CLI SAPI
Edit report at https://bugs.php.net/bug.php?id=43593&edit=1 ID: 43593 Updated by: m...@php.net Reported by:phajdan dot jr at gmail dot com Summary:Impossible to disable Zend Memory Manager in anything other than CLI SAPI -Status: Open +Status: Feedback Type: Feature/Change Request Package:Compile Failure Operating System: Linux Gentoo 2007.0 PHP Version:5.2CVS-2007-12-14 Block user comment: N Private report: N New Comment: Works fine here. What SAPI are you using? /usr/share/nginx/html$ USE_ZEND_ALLOC=0 PHP_FCGI_CHILDREN=0 php-cgi -b 0: $ curl --progress localhost/info.php | grep "Memory Manager" Zend Memory Manager disabled It's really just coming from the environment: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_alloc.c#2723 Previous Comments: [2008-02-02 09:18:42] phajdan dot jr at gmail dot com After compiling with that option Zend MM is still enabled, according to phpinfo(). Anyway, it must be possible to somehow disable it, because debug build does it. But it would be not a good solution to use debug build in production. Please, please check it yourself, *seriously* - no guessing, not requiring me to check every opportunity. [2008-02-01 22:48:39] j...@php.net How about --disable-malloc-mm ?? [2008-01-29 07:06:10] phajdan dot jr at gmail dot com Well, reproduction script is *not*needed* as it's a PHP configuration setting issue. It is visible for example in and I gave exact *steps* to reproduce at the beginning. Here they are, for convenience: The goal is to disable the Zend Memory Manager. Try #1: 1. set USE_ZEND_ALLOC in the environment (/etc/profile) 1a. also tried other ways, like setting it in the Apache config (SetEnv etc) 2. Restart Apache to make sure change takes effect 3. View phpinfo page to see if Zend Memory Manager got disabled 3a. But this way works for the CLI version of PHP (setting env in /etc/profile). Try #2: (proven to be futile and ineffective, but anyway) I tried to recompile PHP with ./configure switches like --disable-zend-memory-manager or --enable-malloc-mm (some webpages told they will disable Zend MM), but as other developers said in this report, there are no such compile options. [2007-12-17 10:59:06] phajdan dot jr at gmail dot com So the bug I referred to was http://bugs.php.net/bug.php?id=43397. Curently it's marked as a duplicate of some other bug, which is now closed because of lack of feedback. I tried to request reopening my original bug, unfortunately without success. About setting env var - please note that I tried this method. No go. phpinfo shows that Zend Memory Manager is enabled. Note that I didn't set it from command line, but had in environment (something like export USE_ZEND_ALLOC=0; /usr/sbin/httpd ...). But it shouldn't make a difference. [2007-12-17 10:00:38] sni...@php.net How about you tell us what the crash is you get? (what bug id was the one you reported?) Also note that some crash bugs were fixed recently. And there are no -disable-zend-memory-manager or --enable-malloc-mm configure options. To disable the memory manager (for debugging) you start e.g. apache with same way you do with PHP CLI: # USE_ZEND_ALLOC=0 /usr/sbin/httpd 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 https://bugs.php.net/bug.php?id=43593 -- Edit this bug report at https://bugs.php.net/bug.php?id=43593&edit=1
Bug #50291 [ReO->Fbk]: incorrect usage of autoconf diversions
Edit report at https://bugs.php.net/bug.php?id=50291&edit=1
ID: 50291
Updated by: m...@php.net
Reported by:vapier at gentoo dot org
Summary:incorrect usage of autoconf diversions
-Status: Re-Opened
+Status: Feedback
Type: Bug
Package:Compile Failure
Operating System: Linux
PHP Version:5.3.1
Block user comment: N
Private report: N
New Comment:
IIRC this is obsolete?
Previous Comments:
[2011-10-12 16:00:04] reeves_28 at yahoo dot com
One to make it compile is to run grep -Rn "divert(" and comment out all lines
in the *.m4 and *.in files that show up. There should be only three files that
actuall need changed. Ignore /ext/fileinfo/tests/magic this doesn't affect the
compile. You will get a lot of warnings from autoconf but it will compile.
[2011-04-25 11:12:57] mail at crick dot ru
PS. I mean the patch to compile only with autoconf> 2.6.4, not for both post
and pre.
[2011-04-25 11:09:15] mail at crick dot ru
Can I ask post here a patch that will allow PHP to compile with autoconf
version> 2.6? I think it will be useful to many users.
[2011-04-25 01:21:24] ras...@php.net
I spent quite a while on it. I couldn't come up with a viable way to support
both
pre and post autoconf-2.64 so it is either/or at this point. Every distro has
pre-
2.64, not everyone has post 2.64. We will eventually be able to make a clean
break, but it definitely won't be in 5.3.
[2011-04-24 23:41:25] mail at crick dot ru
This annoying bug is still there. How about solutions?
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
https://bugs.php.net/bug.php?id=50291
--
Edit this bug report at https://bugs.php.net/bug.php?id=50291&edit=1
Bug #51247 [Asn->Csd]: SHA-2 family function test in crypt are wrong
Edit report at https://bugs.php.net/bug.php?id=51247&edit=1 ID: 51247 Updated by: m...@php.net Reported by:ondrej at debian dot org Summary:SHA-2 family function test in crypt are wrong -Status: Assigned +Status: Closed Type: Bug Package:Compile Failure Operating System: Linux PHP Version:5.3.2 Assigned To:pajoye Block user comment: N Private report: N New Comment: Has recently been fixed. Previous Comments: [2010-03-09 16:06:55] paj...@php.net Given the tests we have made lately on many platforms (with the author of the bundled SHA and blowfish implementation), we ponder to always use these version to provide a true portable crypt to PHP users. I will post the details of the tests in our wiki to explain why it is a must (no clear standard on error, differences in the way some character are processd, etc.). I also recommend to debian to use the PHP implementation instead of relying of the various system versions. About the m4 code, I will have to test it on our tests platforms. Cheers, [2010-03-09 15:04:55] ondrej at debian dot org Description: Tests for SHA-2 family functions in crypt() from -lcrypt are broken: strcpy(&answer[29],"$6$$QMXjqd7rHQZPQ1yHsXkQqC1FBzDiVfTHXL.LaeDAeVV.IzMaV9VU4MQ8 kPuZa2SOP1A0RPm772EaFYjpEJtdu."); in SHA-512 test will surely not fit into char answer[80]... and because of that salt (on the stack) is overwriten, same problem with SHA-256. But even if you increase the buffer, the code there is just plain wrong and could never function correctly. Looks like this code was not properly tested since there are probably too few platforms where you can satisfy all needed crypt functions (extended DES and Blowfish) and therefore internal crypt implementation is always used. Attached patch corrects that. If I have a more time I'll rework this whole code, to just use internal reimplementations for functions not provided by system library. Expected result: checking for SHA512 crypt... yes checking for SHA256 crypt... yes Actual result: -- checking for SHA512 crypt... no checking for SHA256 crypt... no -- Edit this bug report at https://bugs.php.net/bug.php?id=51247&edit=1
Bug #53442 [Opn->Nab]: [fix provided] configure --with-iconv=DIR fails due to two faulty tests
Edit report at https://bugs.php.net/bug.php?id=53442&edit=1 ID: 53442 Updated by: m...@php.net Reported by:fransmeulenbroeks at gmail dot com Summary:[fix provided] configure --with-iconv=DIR fails due to two faulty tests -Status: Open +Status: Not a bug Type: Bug Package:Compile Failure Operating System: linux PHP Version:5.2SVN-2010-12-01 (snap) Block user comment: N Private report: N New Comment: Anything to add here? Previous Comments: [2013-06-25 16:35:47] fel...@php.net There is a check right after what you have quoted which handles the supplied path. ... dnl dnl Check external libs for iconv funcs dnl if test "$found_iconv" = "no"; then for i in $PHP_ICONV /usr/local /usr; do ... [2010-12-01 23:10:25] fransmeulenbroeks at gmail dot com oh and the subject line is wrong this reports and fixes only one faulty test, the other one is reported and fixed in 53443 [2010-12-01 23:09:00] fransmeulenbroeks at gmail dot com oops, made typo in patch This line: + if test "$PHP_ICONV" != no"; then is missing a " and must read + if test "$PHP_ICONV" != "no"; then Uploaded a new patch. Sorry for any inconvenience! [2010-12-01 22:50:49] fransmeulenbroeks at gmail dot com Description: when trying to cross-compile configure picked up the host iconv, not the target one, resulting in wrong paths later on and configure failing. configure was called with configure --with-iconv=DIR (where DIR is the dir to find the iconv stuff). This fails at two places. First one is due to a faulty test in acinclude.m4 It tests PHP_ICONV against "yes". However PHP_ICONV in my case contains the path so we should test against not "no" (PHP_ICONV can be a dir because otherwise this code later on would not make any sense: for i in $PHP_ICONV /usr/local /usr; do ) The following patch is for 5.2.13, but I have verified it is also in the 5.2 snap from today. Index: php-5.2.13/acinclude.m4 === --- php-5.2.13.orig/acinclude.m4 +++ php-5.2.13/acinclude.m4 @@ -2430,7 +2430,8 @@ AC_DEFUN([PHP_SETUP_ICONV], [ dnl dnl Check libc first if no path is provided in --with-iconv dnl - if test "$PHP_ICONV" = "yes"; then + dnl must check against no, not against yes as PHP_ICONV can also include a path, which implies yes + if test "$PHP_ICONV" != no"; then AC_CHECK_FUNC(iconv, [ found_iconv=yes ],[ -- Edit this bug report at https://bugs.php.net/bug.php?id=53442&edit=1
Bug #53571 [Opn->Sus]: phpize: Can not build extensions with config[0-9].m4
Edit report at https://bugs.php.net/bug.php?id=53571&edit=1 ID: 53571 Updated by: m...@php.net Reported by:admin at webdesignforall dot net Summary:phpize: Can not build extensions with config[0-9].m4 -Status: Open +Status: Suspended Type: Bug Package:Compile Failure Operating System: linux PHP Version:5.3.4 Block user comment: N Private report: N New Comment: Patches welcome. In the meantime you can enable phpize builds with the a little trick in config.m4: sinclude(config9.m4) See pecl/http as example: http://svn.php.net/viewvc/pecl/http/branches/DEV_2/config.m4?revision=303137&view=markup Previous Comments: [2010-12-18 16:10:39] admin at webdesignforall dot net phpize is quicker than compiling php with the shared extension, so I'll stick to renaming the config0.m4 for now. [2010-12-18 13:07:13] johan...@php.net This actually is a bug in phpize, if at all. The name actually is part of a simple dependency mechanism for building extensions in the right order. You can build sqlite3 shared when doing ./configure--with-sqlite3=shared in the PHP source, no need for phpize. [2010-12-18 07:20:44] admin at webdesignforall dot net Description: ext/sqlite3 has a config0.m4 file instead of config.m4 so phpize complains. Nothing major since it can be renamed before running phpize, just a niggle. -- Edit this bug report at https://bugs.php.net/bug.php?id=53571&edit=1
Bug #53772 [Opn->Fbk]: Can´t compile
Edit report at https://bugs.php.net/bug.php?id=53772&edit=1 ID: 53772 Updated by: m...@php.net Reported by:nestor_bolivar at digitel dot com dot ve Summary:Can´t compile -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: Solaris 10 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Is this still an issue for you? I recently built fine a couple times on Solaris 11. By the way; the upload feature is for patches not logs. Previous Comments: [2011-01-17 23:50:32] nestor_bolivar at digitel dot com dot ve Description: ld: fatal: library -lnet: not found ld: fatal: File processing errors. No output written to sapi/cgi/php-cgi collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `sapi/cgi/php-cgi' Test script: --- ./configure '--prefix=/usr/local/php' '--with-config-file-path=/usr/local/php/lib' '--with-libxml-dir=/usr/local' '--with-zlib=/usr/local' '--with-xpm-dir=/usr/local' '--with-mysql=/usr/local/mysql' '--with-mysqli=/usr/local/mysql/bin/mysql_config' '--without-pgsql' '--with-jpeg-dir=/usr/local/lib' '--with-zlib-dir=/usr/local/lib' '--with-gd=/usr/local' '--enable-mbstring' '--enable-exif' '--enable-sockets' '--enable-soap' '--with-png-dir=/usr/local/lib' '--with-curl=/usr/local' '--with-ldap=/usr/local' '--with-openssl=/usr/local/ssl' '--with-gettext' '--with-pcre-dir=/usr/local' '--with-freetype-dir=/usr/local' '--with-mssql=/usr/local/freetds' '--with-oci8=/export/home/oraclien/instantclient_10_2' -- Edit this bug report at https://bugs.php.net/bug.php?id=53772&edit=1
Bug #54205 [Opn->Dup]: race condition in shtool's mkdir -p implementation. AND shtool 2.0.8
Edit report at https://bugs.php.net/bug.php?id=54205&edit=1 ID: 54205 Updated by: m...@php.net Reported by:fviard at lacie dot com Summary:race condition in shtool's mkdir -p implementation. AND shtool 2.0.8 -Status: Open +Status: Duplicate Type: Bug Package:Compile Failure Operating System: Linux PHP Version:trunk-SVN-2011-03-09 (SVN) Block user comment: N Private report: N New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. See bug #51076 Previous Comments: [2011-03-09 16:23:49] fviard at lacie dot com Description: Previous bug #51076 http://bugs.php.net/bug.php?id=51076 was fixed by: svn commit r295225 ( http://svn.php.net/viewvc?view=revision&revision=295225 ) but later, commit r295230 ( http://svn.php.net/viewvc? view=revision&revision=295230) updated shtool to version 2.0.8 without backporting the previous patch. (In upstream, nothing changed regarding mkdir between 2.0.6 and 2.0.8) And so, the race condition with -j>1 is still there. (In my case, it appeared during the "make install" step processing the installation of the extensions) Error was: "mkdir: cannot create directory ... : File exists" So, the patch in r295225 should be reapplied to shtool 2.0.8. In a second time, why not replacing all the mkdir code block of shtool by something like: if opt_p = no: mkdir ... chmod ... chown ... chgrp ... ... else: mkdir -p ... chmod -R ... chown -R ... chgrp -R ... ... That would be safer I think ... -- Edit this bug report at https://bugs.php.net/bug.php?id=54205&edit=1
Bug #61057 [Opn->Fbk]: PHP 5.3.10 fails to cross compile when FPM is enabled (ptrace)
Edit report at https://bugs.php.net/bug.php?id=61057&edit=1 ID: 61057 Updated by: m...@php.net Reported by:d dot albano at gmail dot com Summary:PHP 5.3.10 fails to cross compile when FPM is enabled (ptrace) -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: Linux PHP Version:5.3.10 Block user comment: N Private report: N New Comment: What is the outcome of the test? Previous Comments: [2012-02-12 21:34:13] d dot albano at gmail dot com I'm cross compiling because i'm building a set of images for boards like alix, routerboards and, when it will be out, raspberry pi too. I know that it may sound strange, but i don't want to put an entire distribution on the alix my 30mb systems works perfectly and has everything i need. Thank you, i'll do a test. [2012-02-12 21:27:44] ras...@php.net Why are you cross-compiling to the same architecture? You may be able to solve this simply by using a newer version of autoconf to generate the configure script. As a quick test, try building the latest PHP 5.4 with a recent version of autoconf installed. (use ./buildconf --force to force re-generation of the configure script) For PHP 5.3 the latest you can use is autoconf-2.59 For PHP 5.4 the oldest you can use is autoconf-2.59 [2012-02-12 21:06:43] hotseason007 at gmail dot com I also reach it ,but php.net don't regard it as a bug ! here is my report: https://bugs.php.net/bug.php?id=61063 I have fix and Here is the guid: https://github.com/Qzi/webstore/wiki the page attaches the patch enjoy it !! [2012-02-11 17:15:22] d dot albano at gmail dot com Description: I'm trying to cross compile php 5.3.10 (build x86, host x86, target x86) but when i enable FPM i get the following error checking whether ptrace works... configure: error: can not run test program while cross compiling I know that FPM is experimental, btw the bug is related to configure script and not to FPM itself. Wihtout fpm, enabling only cgi and cli works fine Here more output, starting from SAPI modules Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking whether to enable Apache charset compatibility option... no checking for Apache 2.0 filter-module support via DSO through APXS... no checking for Apache 2.0 handler-module support via DSO through APXS... no checking for Apache 1.x (hooks) module support via DSO through APXS... no checking for Apache 1.x (hooks) module support... no checking whether to enable Apache charset compatibility option... no checking for Caudium support... no checking for CLI build... yes checking for Continuity support... no checking for embedded SAPI library support... no checking for FPM build... yes checking for setenv... yes checking for clearenv... yes checking for setproctitle... no checking for library containing socket... none required checking for library containing inet_addr... none required checking for errno.h... yes checking for fcntl.h... yes checking for stdio.h... yes checking for stdlib.h... yes checking for unistd.h... yes checking for sys/uio.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/time.h... yes checking for arpa/inet.h... yes checking for netinet/in.h... yes checking for prctl... yes checking for clock_gettime... yes checking for ptrace... yes checking whether ptrace works... configure: error: can not run test program while cross compiling make[1]: *** [/home/daniele/sviluppo/clew.js/br-rootfs/build/php- 5.3.10/.stamp_configured] Errore 1 make: *** [all] Errore 2 Expected result: it should go ahead Actual result: -- checking whether ptrace works... configure: error: can not run test program while cross compiling -- Edit this bug report at https://bugs.php.net/bug.php?id=61057&edit=1
Bug #55108 [Opn->Nab]: Unable to compile with MySQL
Edit report at https://bugs.php.net/bug.php?id=55108&edit=1 ID: 55108 Updated by: m...@php.net Reported by:s21122012 at yahoo dot com Summary:Unable to compile with MySQL -Status: Open +Status: Not a bug Type: Bug Package:Compile Failure Operating System: Mac OS X 10.6.8 PHP Version:5.4.0alpha1 Block user comment: N Private report: N New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Previous Comments: [2011-11-07 20:09:04] rpickard at gmail dot com Hi all, I had this problem trying to compile php 5.3.8 on OS X 10.7.2 (Lion) with MySQL 5.5.17 against Apache 2.2.21. I found a solution that would allow the build to complete here: https://github.com/adamv/homebrew-alt/issues/53 The solution is to set a EXTRA_CFLAGS value of -lresolv. In my case with the bash command export EXTRA_CFLAGS=-lresolv and then re-do make. There was no need to do make clean or distclean. After compiling all tests passed. Hope this helps, -p. [2011-09-01 22:30:46] matt dot fellows at onegeek dot com dot au I had the same issue with php 5.3.8 on Lion, but unfortunately I'm unable to use the mysqlnd option due to the fact that the database I'm connecting to is MySQL v3. Assuming a default MySQL installation (5.5.15 using either image or source), I was able to solve the issue with the following command: sudo install_name_tool -id /usr/local/mysql/lib/libmysqlclient.18.dylib /usr/local/mysql/lib/libmysqlclient.dylib Hope this helps someone. Cheers, Matt [2011-08-29 23:10:02] aaronh at bind dot com Same issue here running Lion Server / 10.7.1 and php-5.3.8 with the mysql binary. mysql-5.5.15-osx10.6-x86_64.tar.gz Darwin 6c1.sjc.6connect.com 11.0.1 Darwin Kernel Version 11.0.1: Thu Jul 28 02:01:39 PDT 2011; root:xnu-1699.23.4~1/RELEASE_X86_64 x86_64 Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/src/configure - -disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 -- mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- - -program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib -- build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42- 2335.15~25/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple- darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx- include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00) [2011-07-01 18:12:31] s21122012 at yahoo dot com Thank you for your reply! I used the binary package when I posted the issue, but I had tried with a version compiled by myself before and the result was the same. Here is the file you requested (it was compiled using only the --prefix, --with-apxs2, --with- mysql and --with-mysqli flags): http://dl.dropbox.com/u/4460937/php_config.h I have been able to compile it with MySQL support using the native driver (mysqlnd), as suggested by you. I would also like to mention that I had similar errors with PHP 5.3.6 in the past. I am not sure if the conflict was between the same macros, though. [2011-07-01 16:22:28] johan...@php.net These might be caused by conflicts in the usage of either HAVE_DNS_SEARCH or HAVE_RES_NSEARCH between MySQL libs and PHP. Did you use MySQL binary packages or did you compile MySQL yourself? I have no Mac at hand, could you please send me the file main/php_config.h from the failing build? - Thanks. (As remark: You could build PHP using mysqlnd instead of libmysql by using --with-mysql=mysqlnd --with-mysqli=mysqlnd - but your issue should be fixed anyways.) 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 https://bugs.php.net/bug.php?id=55108 -- Edit this bug report at https://bugs.php.net/bug.php?id=55108&edit=1
Bug #60772 [Opn->Fbk]: DB4/DB5 configure library lookup broken --build=x86_64-linux-gnu is passed
Edit report at https://bugs.php.net/bug.php?id=60772&edit=1
ID: 60772
Updated by: m...@php.net
Reported by:david at davidfavor dot com
Summary:DB4/DB5 configure library lookup broken
--build=x86_64-linux-gnu is passed
-Status: Open
+Status: Feedback
Type: Bug
Package:Compile Failure
Operating System: Ubuntu 11.10
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
How about --with-libdir=lib/x86_64-linux-gnu?
Previous Comments:
[2012-01-16 19:25:57] david at davidfavor dot com
Description:
First DB4/DB5 library lookup is far to simple.
Lookups are done for /usr/lib/libdb.a then /usr/lib/libdb.so in that order.
First problem is there's no consideration of 'shared', which if specified
should
reverse the search looking for .so before .a as they usually both exist.
Second problem is when --build=x86_64-linux-gnu (or any other value) is passed
no consideration is given. This means /usr/lib/x86_64-linux-gnu libraries are
ignored.
Neither --with-libdir=/usr/lib/x86_64-linux-gnu or --libdir=x86_64-linux-gnu
have any effect.
Third problem is diagnostics as many systems may have multiple copies of DB
installed. Be great to echo the info out of /usr/include/db.h as in...
DB_VERSION_{MAJOR,RELEASE,MINOR,PATCH} to clarify what's occurring.
Probably logic similar to libcurl is a good place to start.
Ugly fix is ln -s /usr/lib/x86_64-linux-gnu/libdb-5.1.so /usr/lib/.
Expected result:
Use all /usr/lib/(--build) libraries if --build is specified.
Actual result:
--
--build is ignored.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60772&edit=1
Bug #61300 [Opn->Fbk]: segfault in assignment
Edit report at https://bugs.php.net/bug.php?id=61300&edit=1 ID: 61300 Updated by: m...@php.net Reported by:fbableus at yahoo dot fr Summary:segfault in assignment -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: ARM PHP Version:5.4 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ There've been some ARM fixes recently, can you try a current snapshot, please? Previous Comments: [2013-01-11 21:46:17] fbableus at yahoo dot fr Successful compilation with --enable-debug on php 5.4.11RC1 (fails on 5.4.10) but still failing without the flag. Maybe related to https://bugs.php.net/bug.php?id=51216 [2013-01-03 12:33:05] bergere50 at yahoo dot fr I compile natively on my arm nas and I have the same issue. Can't install, can't run tests and when I run your same it crashes with segfault even if the code is unreachable. No output is performed apart 'Segmentation fault'. [2012-12-31 14:31:47] fbableus at yahoo dot fr The following code produces segfault (php 5.4.10): [2012-12-31 09:32:54] fbableus at yahoo dot fr The cli binary runs but when using tab key in interactive mode, segfault occurs. Apache handler fails too. [2012-03-06 12:42:57] fbableus at yahoo dot fr Description: When compiling php 5.4.0 under ARMV5tel (gcc 3.4.2) the make install command fails while attempting to install pear. make test even fails with segfault before any output. Compiling without any optimization (-O0 option) is successfull. Expected result: Successfull installation. Actual result: -- Segmentation fault -- Edit this bug report at https://bugs.php.net/bug.php?id=61300&edit=1
Bug #51076 [Asn]: race condition in shtool's mkdir -p implementation
Edit report at https://bugs.php.net/bug.php?id=51076&edit=1 ID: 51076 Updated by: m...@php.net Reported by:geissert at debian dot org Summary:race condition in shtool's mkdir -p implementation Status: Assigned Type: Bug Package:Compile Failure Operating System: * PHP Version:5.3SVN-2010-02-18 (SVN) Assigned To:geissert Block user comment: N Private report: N New Comment: And you make me angry by wasting my time. It was just a template when marking a bug as duplicate. Stop calling people and do something yourself. You do not have to apologize for being an asshole, just don't be an asshole. Previous Comments: [2013-10-01 12:58:34] fviard at lacie dot com Hi, Today m...@php.net made me angry by posting a crappy comment on my 2,5years old bug report #54205 without even fixing the issue. This issue was so old that I completely forgot it. But now, I'm stupefied to notice that after 2 years, that issue that is resolvable with only a 5lines patch (easy to apply) is still not resolved. What are you doing? Mike, sorry to be offensive, but do you prefer harassing people on old bugs or fixing them? So, please close this bug soon! Thank you! [2013-10-01 12:30:15] m...@php.net Related To: Bug #54205 [2010-02-18 08:34:49] j...@php.net -Status: Closed +Status: Assigned Not fixed. [2010-02-18 00:31:15] geiss...@php.net -Status: Open +Status: Closed This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2010-02-18 00:30:13] s...@php.net Automatic comment from SVN on behalf of geissert Revision: http://svn.php.net/viewvc/?view=revision&revision=295225 Log: Fix race condition in shtool's mkdir -p implementation (bug #51076) 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 https://bugs.php.net/bug.php?id=51076 -- Edit this bug report at https://bugs.php.net/bug.php?id=51076&edit=1
Bug #61951 [Opn->Fbk]: "make install" script fails when prefix dir is a symbolic link
Edit report at https://bugs.php.net/bug.php?id=61951&edit=1 ID: 61951 Updated by: m...@php.net Reported by:stolen dot data dot net at gmail dot com Summary:"make install" script fails when prefix dir is a symbolic link -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: Any PHP Version:5.4.2 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Works fine here. $ make install Installing PHP CLI binary:/tmp/php-5.4/sym/bin/ Installing PHP CLI man page: /tmp/php-5.4/sym/php/man/man1/ Installing PHP CGI binary:/tmp/php-5.4/sym/bin/ Installing PHP CGI man page: /tmp/php-5.4/sym/php/man/man1/ Installing build environment: /tmp/php-5.4/sym/lib/php/build/ Installing header files: /tmp/php-5.4/sym/include/php/ Installing helper programs: /tmp/php-5.4/sym/bin/ program: phpize program: php-config Installing man pages: /tmp/php-5.4/sym/php/man/man1/ page: phpize.1 page: php-config.1 $ cat config.nice #! /bin/sh # # Created by configure '/home/mike/src/php-5.4/configure' \ '--cache-file=config.cache' \ '--disable-all' \ '--prefix=/tmp/php-5.4/sym' \ "$@" $ ls -ld sym lrwxrwxrwx 1 mike users 4 1. Okt 15:07 sym -> real $ ls -ld real drwxr-xr-x 6 mike users 120 1. Okt 15:55 real Previous Comments: [2012-05-07 19:25:36] stolen dot data dot net at gmail dot com Specifically, the PHP Makefile fails when the destination of the symbolic link doesn't end with a trailing slash. This will cause the new Makefile to fail...: drwxr-xr-x 9 root wheel 512 May 7 21:21 php542 lrwxr-xr-x 1 root wheel7 May 7 21:10 php -> php542 ...but the Makefile bug doesn't manifest itself in this case: drwxr-xr-x 9 root wheel 512 May 7 21:21 php542 lrwxr-xr-x 1 root wheel7 May 7 21:10 php -> php542/ (Note the trailing slash at the end of the symbolic link destination...) [2012-05-05 11:00:50] stolen dot data dot net at gmail dot com Description: I've been using a symbolic link scheme for the prefix destination dir of PHP/Apache/etc. software that I compile myself for over ten years now, to easily and quickly switch between releases in case of problems showing up when I move to a new version: # ls -l /usr/opt drwxr-xr-x 6 root wheel 512 Mar 20 2011 php536 drwxr-xr-x 6 root wheel 512 Dec 11 12:44 php538 drwxr-xr-x 16 root wheel 512 May 5 11:02 php542 lrwxr-xr-x 1 root wheel6 May 5 11:02 php -> php542 ... ./configure --prefix=/usr/opt/php --other-flags If something goes wrong, I just shut down the servers, change the symbolical link, restart... You get the idea... It is not a problem with any earlier version of PHP, but as of PHP 5.4.0 something changed in the "install" portion of the Makefile that breaks this handy practice: # make install Installing PHP CLI binary:/usr/opt/php/bin/ Installing PHP CLI man page: /usr/opt/php/php/man/man1/ mkdir: /usr/opt/php/php: File exists mkdir: /usr/opt/php/php/man: Too many levels of symbolic links mkdir: /usr/opt/php/php/man/man1: Too many levels of symbolic links *** Error code 1 Stop in /usr/opt/php-5.4.2 (line 243 of Makefile). And when I take a look at what the install script has been doing: # cd /usr/opt/php # ls -l total 4 drwxr-xr-x 2 root wheel 512 May 5 13:43 bin lrwxr-xr-x 1 root wheel3 May 5 11:02 php -> php For some reason, when the prefix dir is a symbolic link, the 5.4.x Makefile creates a symbolic link to itself inside the prefix dir. Note also that the timestamp of the symbolic is identical to the actual symbolic link I make for the prefix destination, as if the Makefile tries to copy the directory into itself. The problem is easily solved by entering the prefix dir, removing the broken link that the install script creates and just "mkdir php", then resuming "make install" again. This shouldn't be needed, obviously. The script shouldn't fail just because the prefix happens to be a symbolic link to an actual destination sitting in the same directory - there are no technical complications caused by this handy practice. -- Edit this bug report at https://bugs.php.net/bug.php?id=61951&edit=1
Bug #51076 [Asn]: race condition in shtool's mkdir -p implementation
Edit report at https://bugs.php.net/bug.php?id=51076&edit=1 ID: 51076 Updated by: m...@php.net Reported by:geissert at debian dot org Summary:race condition in shtool's mkdir -p implementation Status: Assigned Type: Bug Package:Compile Failure Operating System: * PHP Version:5.3SVN-2010-02-18 (SVN) Assigned To:geissert Block user comment: N Private report: N New Comment: Looks like I have to apologize for being an asshole myself, some may even think I'm the only asshole here. Previous Comments: [2013-10-01 13:55:06] m...@php.net And you make me angry by wasting my time. It was just a template when marking a bug as duplicate. Stop calling people and do something yourself. You do not have to apologize for being an asshole, just don't be an asshole. [2013-10-01 12:58:34] fviard at lacie dot com Hi, Today m...@php.net made me angry by posting a crappy comment on my 2,5years old bug report #54205 without even fixing the issue. This issue was so old that I completely forgot it. But now, I'm stupefied to notice that after 2 years, that issue that is resolvable with only a 5lines patch (easy to apply) is still not resolved. What are you doing? Mike, sorry to be offensive, but do you prefer harassing people on old bugs or fixing them? So, please close this bug soon! Thank you! [2013-10-01 12:30:15] m...@php.net Related To: Bug #54205 [2010-02-18 08:34:49] j...@php.net -Status: Closed +Status: Assigned Not fixed. [2010-02-18 00:31:15] geiss...@php.net -Status: Open +Status: Closed This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. 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 https://bugs.php.net/bug.php?id=51076 -- Edit this bug report at https://bugs.php.net/bug.php?id=51076&edit=1
Bug #62003 [Opn->Fbk]: LDAP compile failure
Edit report at https://bugs.php.net/bug.php?id=62003&edit=1 ID: 62003 Updated by: m...@php.net Reported by:aconnor at ait dot ie Summary:LDAP compile failure -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: Ubuntu server 12.04 PHP Version:5.4.3 Block user comment: N Private report: N New Comment: See bug #61450 -- a fix is in the works. I'm inclined to mark this as duplicate. @aconnor: Were you trying to build ldap and oci8 at the same time, too? Previous Comments: [2012-12-05 14:15:39] fernando dot wendt at gmail dot com When compiling PHP 5.4.9, trying to enable both oci8 (instantclient, 11.2) and ldap modules, it points the same issue, and fails. The little bit diff is that once you point --with-ldap, it seems to compile it, but - by a misunderstood behavior, it uses the ldap.h from instantclient sdk file! Of course, make fails. Reading at OTN forum, theres is a thread where some people does not recommend compiling them togheter: the suggest is to compile PHP with ldap, and install oci8 with PECL, after [https://forums.oracle.com/forums/thread.jspa? messageID=10319335]. Works to me: i was needing ldap at first. oci8, will be added after. Best regards [2012-06-28 13:41:19] macolinovo at gmail dot com I'm also with same problem [2012-05-11 10:42:37] aconnor at ait dot ie Description: I am trying configure php 5.4.3 from source on a ubuntu 12.04 server build using this switch --with-ldap=/usr i get this error: configure: error: Cannot find ldap libraries in /usr/lib. So i change to --with-ldap=/usr/lib Then i get this error: configure: error: Cannot find ldap.h So i find ldap.h in /usr/include I created a sym link for the /include directory in the /usr/lib directory, so the config might see ldap.h. I have tried ln -s /usr/include/ /usr/lib and ln -s /usr/include/ldap.h /usr/lib/ but i still get the same error. also: Permissions on the directory /usr/lib: drwxr-xr-x 53 root root 4096 May 11 09:06 lib I chmod 777 the ldap.h file. Then ran ln -s /usr/include/ldap.h /usr/lib/ i also tried ln -s /usr/include/ldap.h . Both create the link it appears as : lrwxrwxrwx 1 root root 19 May 11 09:00 ldap.h -> /usr/include/ldap.h But still the same error -- Edit this bug report at https://bugs.php.net/bug.php?id=62003&edit=1
Req #64492 [Opn->Csd]: ./configure fails under bison 2.7 environment
Edit report at https://bugs.php.net/bug.php?id=64492&edit=1 ID: 64492 Updated by: m...@php.net Reported by:user at zuse dot jp Summary:./configure fails under bison 2.7 environment -Status: Open +Status: Closed Type: Feature/Change Request Package:Compile Failure Operating System: OSX 10.7 PHP Version:master-Git-2013-03-22 (Git) -Assigned To: +Assigned To:mike Block user comment: N Private report: N Previous Comments: [2013-03-27 18:55:48] s...@php.net The PHP test suite runs fine with (hand built) bison 2.7 on Oracle Linux 5.9. The fix for https://bugs.php.net/bug.php?id=64503 means that 2.3 and earlier are no longer usable. I verified this, as did laruence (on IRC he retracted his email that claimed it was usable). Rasmus is OK with dropping support for 2.3 (see http://news.php.net/php.internals/66810). These older versions should be removed from Zend/acinclude.m4 Note in https://bugs.php.net/bug.php?id=64503 Remi says 2.4.1 is OK. I haven't seen any results for 2.4. [2013-03-23 13:38:52] paj...@php.net Then we need to fix the code for 2.6+. Right now it fails for ZTS with 2.6.1 already. [2013-03-23 13:15:21] m...@php.net We might add it to master, I'm using 2.7 all-time here, too. [2013-03-22 16:29:08] paj...@php.net I would suggest to use older versions for now, latest versions are not yet tested and can create issues. [2013-03-22 16:21:28] user at zuse dot jp Description: Please add build support for bison 2.7 environment. Test script: --- $ bison --version bison (GNU Bison) 2.7 $ autoreconf -i && ./configure configure: WARNING: bison versions supported for regeneration of the Zend/PHP parsers: 1.28 1.35 1.75 1.875 2.0 2.1 2.2 2.3 2.4 2.4.1 2.4.2 2.4.3 2.5 2.5.1 2.6 2.6.1 2.6.2 (found: 2.7). configure: error: bison is required to build PHP/Zend when building a GIT checkout! -- Edit this bug report at https://bugs.php.net/bug.php?id=64492&edit=1
Bug #65595 [Opn->Fbk]: ext/standard/.libs/basic_functions.o:(.data+0xbf08): undefined reference to `zi
Edit report at https://bugs.php.net/bug.php?id=65595&edit=1 ID: 65595 Updated by: m...@php.net Reported by:g dot fischer at ah-online dot com Summary:ext/standard/.libs/basic_functions.o:(.data+0xbf08): undefined reference to `zi -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: linux, debian 6 PHP Version:5.4.19, 5.5.3 Block user comment: N Private report: N New Comment: Sorry, but how should we consistently fix bugs with a trialware compiler? I'd be happy though, to apply a portable patch! Thank you. Previous Comments: [2013-08-30 15:36:33] g dot fischer at ah-online dot com both affected versions added [2013-08-30 15:34:33] g dot fischer at ah-online dot com Description: system: === debian 6, pgi 2012 options used: = ./configure --enable-fastcgi --disable-ipv6 --with-openssl --with-mysql=/usr/local/mysql --with-mysql-sock --enable-sockets --with-curl --prefix=/usr/local/php553 --enable-shmop this occurs with 5.4.19 as well as with 5.5.3 upon final linking. 5.3.27 is not affected. nothing new it seems. the following report i found shows the same error with the intel compiler http://forum.nginx.org/read.php?25,58334 Expected result: link without error Actual result: -- ext/standard/.libs/basic_functions.o:(.data+0xbf08): undefined reference to `zif_sscanf' make: *** [sapi/cli/php] Error 2 make: *** Waiting for unfinished jobs make: *** [sapi/cgi/php-cgi] Error 2 -- Edit this bug report at https://bugs.php.net/bug.php?id=65595&edit=1
Bug #65571 [Opn->Fbk]: Compiling fails with - missing binary operator before token "extern"
Edit report at https://bugs.php.net/bug.php?id=65571&edit=1 ID: 65571 Updated by: m...@php.net Reported by:tony dot ar dot wright at bt dot com Summary:Compiling fails with - missing binary operator before token "extern" -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: SuSE 9 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: What are your flex/bison versions? Previous Comments: [2013-09-09 12:33:28] pascal at nobus dot be I had the same problem on php-5.4.19 This on a slackware-10.1 Tried the snapshot (php5.4-201309091030), and it seems to be fixed there? However I have no idea with what change the bug is fixed. [2013-08-28 09:37:25] tony dot ar dot wright at bt dot com Description: I installed 5.5.2 ok but when I tried to install 5.5.3 I get the error message: In file included from Zend/zend_language_scanner.l:40: Zend/zend_language_parser.h:40:1: missing binary operator before token "extern" make: *** [Zend/zend_language_scanner.lo] Error 1 Configure options used: './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--enable-ftp' '--witho ut-ldap' '--enable-sockets' '--with-gd' '--with-freetype-dir' '--without-mcrypt' '--with-zlib-dir' '--with-png-dir' '--with-oci8=/export/oracle/product/10.2.0/d b_1' '--with-openssl' -- Edit this bug report at https://bugs.php.net/bug.php?id=65571&edit=1
Bug #54740 [Opn->Nab]: Ternary operator will not work with return by reference
Edit report at https://bugs.php.net/bug.php?id=54740&edit=1
ID: 54740
Updated by: m...@php.net
Reported by:dukeofgaming at gmail dot com
Summary:Ternary operator will not work with return by
reference
-Status: Open
+Status: Not a bug
Type: Bug
-Package:Compile Failure
+Package:Scripting Engine problem
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Check the second note here:
http://php.net/manual/en/language.references.return.php
Previous Comments:
[2012-08-27 14:17:44] marrch dot caat at gmail dot com
This is a general problem with reference inside ternary operator. For ex., the
following script fails with the same error:
$link = isset($i) ? (& $arr[$i]) : null;
- while the following works fine:
$link = & $arr[$i];
[2011-05-15 22:59:17] dukeofgaming at gmail dot com
Description:
PHP fails to parse a returned by reference value when using the ternary
operator.
The test script provided illustrates a case of when it is absolutely necessary
to return by reference; if the "&" is removed then the output would be a fatal
error: "Fatal error: Cannot use [] for reading in <...>"
Test script:
---
$value = ($condition)?(
$some_value
):(&$object->Collection[]);
Expected result:
No errors, should be the equivalent of having:
if($condition){
$value = $some_value;
}else{
$value = &$object->Collection[];
}
Actual result:
--
Parse error: syntax error, unexpected '&' in <...>
--
Edit this bug report at https://bugs.php.net/bug.php?id=54740&edit=1
Bug #62396 [Opn->Csd]: 'make test' crashes starting with 5.3.14 (missing gzencode())
Edit report at https://bugs.php.net/bug.php?id=62396&edit=1 ID: 62396 Updated by: m...@php.net Reported by:long at ku dot edu Summary:'make test' crashes starting with 5.3.14 (missing gzencode()) -Status: Open +Status: Closed Type: Bug Package:Compile Failure Operating System: Red Hat Enterprise Linux AS rele PHP Version:5.3.14 Block user comment: N Private report: N New Comment: Automatic comment on behalf of mike Revision: http://git.php.net/?p=php-src.git;a=commit;h=cd1cab3f4726751a0476ac8701ce09cc37cb36df Log: fix bug #62396 'make test' crashes starting with 5.3.14 (missing gzencode()) Previous Comments: [2013-03-19 16:39:55] long at ku dot edu I'm stilling seeing this error in 5.3.23 contrary to previous post. [2013-01-07 09:58:51] meths at btinternet dot com I found this bug report after encountering it on 5.4.x and I duplicated the issue seen with 5.3.14 at the time. I can confirm with my latest attempts that this seems fixed in 5.3.x but is still occurring with 5.4.x as of 5.4.10. [2012-06-22 15:24:53] long at ku dot edu Description: When I run 'make test' it now crashes: PASS SOAP Server 17: user fault (through return) [ext/soap/tests/server017.phpt] PASS SOAP Server 18: user fault (through throw) [ext/soap/tests/server018.phpt] PHP Fatal error: Call to undefined function gzencode() in /apps/home/long/src/php5.3-201206221330/run-tests.php on line 1712 Fatal error: Call to undefined function gzencode() in /apps/home/long/src/php5.3-201206221330/run-tests.php on line 1712 [long@wbtstap php5.3-201206221330]$ This did not happen in 5.3.13 and earlier. Here is the config.nice that was used: #! /bin/sh # # Created by configure CFLAGS='-O3' \ CXXFLAGS='-O3' \ LIBS='-lssl -lncurses' \ './configure' \ '--enable-discard-path' \ '--with-openssl=shared' \ '--with-zlib=shared' \ '--enable-bcmath' \ '--with-bz2=shared' \ '--enable-calendar' \ '--with-curl=shared' \ '--enable-dba=shared' \ '--with-gdbm=shared' \ '--with-db4=shared' \ '--enable-dbase' \ '--enable-exif' \ '--enable-ftp' \ '--with-gd=shared' \ '--enable-gd-native-ttf' \ '--enable-gd-jis-conv' \ '--with-gettext=shared' \ '--with-gmp=shared' \ '--with-imap=shared' \ '--with-kerberos' \ '--with-imap-ssl' \ '--with-ldap' \ '--enable-mbstring' \ '--with-mysql=/usr' \ '--with-ncurses=shared' \ '--with-oci8' \ '--with-pspell=shared' \ '--with-readline=shared' \ '--enable-shmop' \ '--with-snmp=shared' \ '--enable-sockets' \ '--with-sqlite=shared' \ '--with-pdo-sqlite=shared' \ '--enable-sysvmsg' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-wddx' \ '--with-freetype-dir' \ '--with-jpeg-dir' \ '--with-xpm-dir' \ '--enable-cgi' \ '--with-mysqli' \ '--enable-pdo=shared' \ '--with-pdo-mysql=shared' \ '--with-pdo-oci=shared' \ '--with-tidy' \ '--enable-soap=shared' \ '--enable-zip' \ "$@" Expected result: 'make test' should not bomb out, errors should be trapped, etc. Actual result: -- ... PASS SOAP Server 17: user fault (through return) [ext/soap/tests/server017.phpt] PASS SOAP Server 18: user fault (through throw) [ext/soap/tests/server018.phpt] PHP Fatal error: Call to undefined function gzencode() in /apps/home/long/src/php5.3-201206221330/run-tests.php on line 1712 Fatal error: Call to undefined function gzencode() in /apps/home/long/src/php5.3-201206221330/run-tests.php on line 1712 [long@wbtstap php5.3-201206221330]$ -- Edit this bug report at https://bugs.php.net/bug.php?id=62396&edit=1
Bug #62003 [Opn->Csd]: LDAP compile failure
Edit report at https://bugs.php.net/bug.php?id=62003&edit=1 ID: 62003 Updated by: m...@php.net Reported by:aconnor at ait dot ie Summary:LDAP compile failure -Status: Open +Status: Closed Type: Bug Package:Compile Failure Operating System: Ubuntu server 12.04 PHP Version:5.4.3 -Assigned To: +Assigned To:mike Block user comment: N Private report: N New Comment: Ok, we'll suppose it's fixed then. Previous Comments: [2013-10-01 14:33:26] aconnor at ait dot ie Hi Mike, At the time I wasn't trying to build with oci8 at the time. I eventually got around this error after alot of trial and error I found then solution in a different version of ldap. I was trying to compile with openldap- stable-20120311 (2.4.30), I downloaded and compiled openldap-2.4.31 and this allowed me to compile php 5.4.3. I now have multiple successful ldap connections running on the front end of our server. Sorry I didn't post these comments earlier, I didn't realise others were having a similar issue. This was my solution but it only be a work-around as there could be a bug. Regards, Anthony [2013-10-01 14:15:57] m...@php.net See bug #61450 -- a fix is in the works. I'm inclined to mark this as duplicate. @aconnor: Were you trying to build ldap and oci8 at the same time, too? [2012-12-05 14:15:39] fernando dot wendt at gmail dot com When compiling PHP 5.4.9, trying to enable both oci8 (instantclient, 11.2) and ldap modules, it points the same issue, and fails. The little bit diff is that once you point --with-ldap, it seems to compile it, but - by a misunderstood behavior, it uses the ldap.h from instantclient sdk file! Of course, make fails. Reading at OTN forum, theres is a thread where some people does not recommend compiling them togheter: the suggest is to compile PHP with ldap, and install oci8 with PECL, after [https://forums.oracle.com/forums/thread.jspa? messageID=10319335]. Works to me: i was needing ldap at first. oci8, will be added after. Best regards [2012-06-28 13:41:19] macolinovo at gmail dot com I'm also with same problem [2012-05-11 10:42:37] aconnor at ait dot ie Description: I am trying configure php 5.4.3 from source on a ubuntu 12.04 server build using this switch --with-ldap=/usr i get this error: configure: error: Cannot find ldap libraries in /usr/lib. So i change to --with-ldap=/usr/lib Then i get this error: configure: error: Cannot find ldap.h So i find ldap.h in /usr/include I created a sym link for the /include directory in the /usr/lib directory, so the config might see ldap.h. I have tried ln -s /usr/include/ /usr/lib and ln -s /usr/include/ldap.h /usr/lib/ but i still get the same error. also: Permissions on the directory /usr/lib: drwxr-xr-x 53 root root 4096 May 11 09:06 lib I chmod 777 the ldap.h file. Then ran ln -s /usr/include/ldap.h /usr/lib/ i also tried ln -s /usr/include/ldap.h . Both create the link it appears as : lrwxrwxrwx 1 root root 19 May 11 09:00 ldap.h -> /usr/include/ldap.h But still the same error -- Edit this bug report at https://bugs.php.net/bug.php?id=62003&edit=1
Bug #65571 [Fbk->Sus]: Compiling fails with - missing binary operator before token "extern"
Edit report at https://bugs.php.net/bug.php?id=65571&edit=1 ID: 65571 Updated by: m...@php.net Reported by:tony dot ar dot wright at bt dot com Summary:Compiling fails with - missing binary operator before token "extern" -Status: Feedback +Status: Suspended Type: Bug Package:Compile Failure Operating System: SuSE 9 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Looks like you have to use bison2.4 - 2.7 to build from a source checkout. Previous Comments: [2013-10-01 15:05:47] pascal at nobus dot be For the slackware-OS: (also php-5.4.20 has this problem) # flex -V flex 2.5.33 # bison -V bison (GNU Bison) 2.3 [2013-10-01 14:36:01] m...@php.net What are your flex/bison versions? [2013-09-09 12:33:28] pascal at nobus dot be I had the same problem on php-5.4.19 This on a slackware-10.1 Tried the snapshot (php5.4-201309091030), and it seems to be fixed there? However I have no idea with what change the bug is fixed. [2013-08-28 09:37:25] tony dot ar dot wright at bt dot com Description: I installed 5.5.2 ok but when I tried to install 5.5.3 I get the error message: In file included from Zend/zend_language_scanner.l:40: Zend/zend_language_parser.h:40:1: missing binary operator before token "extern" make: *** [Zend/zend_language_scanner.lo] Error 1 Configure options used: './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--enable-ftp' '--witho ut-ldap' '--enable-sockets' '--with-gd' '--with-freetype-dir' '--without-mcrypt' '--with-zlib-dir' '--with-png-dir' '--with-oci8=/export/oracle/product/10.2.0/d b_1' '--with-openssl' -- Edit this bug report at https://bugs.php.net/bug.php?id=65571&edit=1
Bug #62284 [Opn->Fbk]: getimagesize does not work with all supported images
Edit report at https://bugs.php.net/bug.php?id=62284&edit=1
ID: 62284
Updated by: m...@php.net
Reported by:dnied at tiscali dot it
Summary:getimagesize does not work with all supported images
-Status: Open
+Status: Feedback
Type: Bug
Package:GetImageSize related
Operating System: Linux, i386
PHP Version:5.3.13
Block user comment: N
Private report: N
New Comment:
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.
I get "Error generating thumbnail".
Previous Comments:
[2012-06-10 15:47:47] dnied at tiscali dot it
Yes, I can get the non-working image with my browser and with wget.
Your comment made me think of a config issue, so I tried an original, untouched
php.ini file with all extensions enabled (not that my own php.ini was really
tweaked). Still, no go. I do get a couple of warnings for 2 missing libs, but
they look unrelated to me (one is a spell-checking lib, the other is SQLite3 --
neither is documented as a dependency to getimagesize):
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php/extensions/enchant.so' - /usr/lib/php/extensions/enchant.so:
cannot open shared object file: No such file or directory in Unknown on line 0
Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php/extensions/enchant.so' - /usr/lib/php/extensions/enchant.so:
cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php/extensions/sqlite3.so' - /usr/lib/php/extensions/sqlite3.so:
cannot open shared object file: No such file or directory in Unknown on line 0
Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php/extensions/sqlite3.so' - /usr/lib/php/extensions/sqlite3.so:
cannot open shared object file: No such file or directory in Unknown on line 0
[2012-06-10 15:17:09] larue...@php.net
I can not reproduce this, is the network to wikimedia okey?
[2012-06-10 14:01:16] dnied at tiscali dot it
Description:
The getimagesize function does not work with some (allegedly supported) images.
I could not observe this on images stored locally, so it only seems to affect
images retrieved via the http wrapper.
FWIW, URL length doesn't seem to affect this: I tried a shortened URL for the
image that didn't work, and it still didn't work.
Test script:
---
~> php -r '$imgInfo =
getimagesize("http://upload.wikimedia.org/wikipedia/commons/thumb/d/d9/Disney_Concert_Hall_by_Carol_Highsmith_edit2.jpg/767px-Disney_Concert_Hall_by_Carol_Highsmith_edit2.jpg";);
print_r($imgInfo);'
~>
~>
~> php -r '$imgInfo =
getimagesize("https://bugs.php.net/images/logo.gif";);print_r($imgInfo);'
Array
(
[0] => 130
[1] => 67
[2] => 1
[3] => width="130" height="67"
[bits] => 8
[channels] => 3
[mime] => image/gif
)
~>
Expected result:
An array of image properties, for both images
Actual result:
--
A boolean false on the 1st image, the expected array of image properties on the
2nd one.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62284&edit=1
Bug #63257 [Opn->Nab]: checkdate(): Wrong if year is two digits and year is 2000
Edit report at https://bugs.php.net/bug.php?id=63257&edit=1
ID: 63257
Updated by: m...@php.net
Reported by:php at skay dot se
Summary:checkdate(): Wrong if year is two digits and year is
2000
-Status: Open
+Status: Not a bug
Type: Bug
Package:*Calendar problems
Operating System: Unix
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2012-10-11 11:25:58] ewgraf at gmail dot com
Seems not a bug.
>From manual:
> 'year' The year is between 1 and 32767 inclusive.
int from "00" will be 0
[2012-10-10 22:22:19] php at skay dot se
Description:
---
>From manual page: http://www.php.net/function.checkdate
---
If year is 2000 the function will return TRUE (provided the rest is valid) -
Thats good!
But if year is 00 the function will always return FALSE
Test script:
---
echo checkdate("01", "01", "2000");
echo checkdate("01", "01", "00");
Expected result:
TRUE
TRUE
Actual result:
--
TRUE
FALSE
[2012-10-10 22:17:13] php at skay dot se
Description:
---
>From manual page: http://www.php.net/function.checkdate
---
PHP version 5.3.10
If year is 2000 the function will return TRUE (provided the rest is valid) -
Thats good!
But if year is 00 the function will always return FALSE
Test script:
---
echo checkdate("01", "01", "2000");
echo checkdate("01", "01", "00");
Expected result:
TRUE
TRUE
Actual result:
--
TRUE
FALSE
--
Edit this bug report at https://bugs.php.net/bug.php?id=63257&edit=1
