Bug #52788 [Opn-Bgs]: preg_match not matching last backslash '\'
Edit report at http://bugs.php.net/bug.php?id=52788edit=1
ID: 52788
Updated by: ras...@php.net
Reported by:reevsey at gmail dot com
Summary:preg_match not matching last backslash '\'
-Status: Open
+Status: Bogus
Type: Bug
Package:*Regular Expressions
Operating System: ALL
PHP Version:5.3.3
Block user comment: N
New Comment:
And if you replace that backslash with any other character that is not
in your
range, you will see the same thing. It has nothing to do with the
backslash.
Your regex is simply completely wrong.
Your regex says:
From the start of the string ^
Find me 0 or more characters that are not [^0-9a-zA-Z]*
Until the end of the string $
Your problem is that you have anchored it to the start of the string.
In each
of your not matched cases, you have a valid char as the first char.
What you probably meant to write was:
'#[^0-9a-zA-Z]+#'
By not anchoring your regex to the start or end of the string, you are
telling
it to look for invalid characters anywhere in the string. And you want
+
instead of * because you want to match at least 1 invalid char, not 0.
By the way, there are much quicker ways of doing this if your list of
valid or
invalid chars is finite. See strpbrk and strcspn.
Previous Comments:
[2010-09-07 07:37:44] reevsey at gmail dot com
Description:
preg_match() does not match the last backslash at the end of a subject
string.
I'm using the pattern #^[^0-9a-zA-Z]*$# to filter out any characters
from user input other than alphanumerics.
The Problem I'm seeing is if there is a backslash \ as the last
character with valid characters before it, then preg_match() does not
match it.
Example input:
\= matched.
\\ = matched.
a\a = matched.
@$ = matched.
a\ = not matched.
0\ = not matched.
A\ = not matched.
abc\ = not matched.
etc...
Test script:
---
// Obviously taking into account here that backslash \ is an escape
char.
// SO double the backslash.
$userInput = a\\;
if (preg_match(#^[^0-9a-zA-Z]*$#, $userInput))
{
echo Invalid input;
}
else
{
echo Good to go!;
}
// If you negate the regular expression to #^[0-9a-zA-Z]*$# and change
the
// test statement to be:
// if (!preg_match(#^[0-9a-zA-Z]*$#, $userInput)) {}
// it works as expected.
Expected result:
Expected result: Invalid input
Actual result:
--
Actual result: Good to go!
--
Edit this bug report at http://bugs.php.net/bug.php?id=52788edit=1
Bug #42659 [Com]: microtime() loses time in long-running scripts
Edit report at http://bugs.php.net/bug.php?id=42659edit=1
ID: 42659
Comment by: jdolecek at NetBSD dot org
Reported by:jdolecek at NetBSD dot org
Summary:microtime() loses time in long-running scripts
Status: No Feedback
Type: Bug
Package:Date/time related
Operating System: win32 only
PHP Version:5.2.4
Block user comment: N
New Comment:
The problem is still there even with PHP 5.3.3:
PHP 5.3.3 (cli) (built: Jul 21 2010 20:36:55)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
The test runs on physical machine (not a virtual) running Windows XP
SP3.
Output after about 21 hours with 5.3.3:
msec: [2010-09-07 09:12:15.7766]
sec : [2010-09-07 09:12:18]
msec: [2010-09-07 09:17:15.7700]
sec : [2010-09-07 09:17:18]
msec: [2010-09-07 09:22:15.7634]
sec : [2010-09-07 09:22:18]
msec: [2010-09-07 09:27:15.7568]
sec : [2010-09-07 09:27:18]
For comparison, here is output from parallelly running PHP 5.2.6:
msec: [2010-09-07 09:19:51.6134]
sec : [2010-09-07 09:19:54]
msec: [2010-09-07 09:24:51.6068]
sec : [2010-09-07 09:24:54]
msec: [2010-09-07 09:29:51.6003]
sec : [2010-09-07 09:29:54]
Both show ~3 sec time difference between microtime() and time()
Unfortunately I can't re-open the PR (it says I can't change the PR to
that state), so just adding a comment.
Previous Comments:
[2008-09-03 01:00:01] 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.
[2008-08-26 23:06:36] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.3-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.3-win32-installer-latest.msi
[2007-09-13 15:30:05] jdolecek at NetBSD dot org
Description:
When PHP script runs for long time, the value returned by microtime()
gradually drifts away from time(). The exact value depends on system,
but we've seen 5 hour difference to current time for script running
about a week, with drift about 1 minute per 5 minutes run (system
running under VMware). The script is daemon-like process, i.e. it's
blocked in select() most of time, and only occassionally wakes up to
process request.
Looking at win32/time.c, I spot one problematic spot in that the code
might not notice counter wrap-off if timer happens to be a higher value
after wrap-around then the last time the function was called. However,
that shouldn't be normally problem, since the counter wraps-around very
infrequently.
Reproduce code:
---
?php
ini_set('date.timezone', 'CET');
putenv(TZ=CET);
while(true) {
$sec = microtime(true);
echo msec: . sprintf([%s.%04d],
date(Y-m-d H:i:s, floor($sec)),
(float) ($sec - floor($sec)) *
1).\n;
echo sec : .date('[Y-m-d H:i:s]').\n;
sleep(300);
}
C program which demostrates how the two times diverge (cutpaste from
win32/time.c, so please forgive whitespace/style):
#include windows.h
#include winbase.h
#include time.h
#include winsock2.h
int getfilesystemtime(struct timeval *time_Info)
{
FILETIME ft;
__int64 ff;
LARGE_INTEGER li;
GetSystemTimeAsFileTime(ft); /* 100 ns blocks since 01-Jan-1641
*/
/* resolution seems to be 0.01 sec
*/
li.u.LowPart = ft.dwLowDateTime;
li.u.HighPart = ft.dwHighDateTime;
ff = li.QuadPart;
time_Info-tv_sec =
(int)(ff/(__int64)1000-(__int64)11644473600ULL);
time_Info-tv_usec = (int)(ff % 1000)/10;
return 0;
}
#define PW32G(x)(x)
int
main()
{
LARGE_INTEGER li;
__int64 freq, timer;
double dt;
struct timeval tv, *time_Info = tv, starttime, tv2;
QueryPerformanceFrequency(li);
freq = li.QuadPart;
getfilesystemtime(starttime);
QueryPerformanceCounter(li);
timer = li.QuadPart;
dt = (double)timer/PW32G(freq);
PW32G(starttime).tv_usec -=
(int)((dt-(int)dt)*100);
if (PW32G(starttime).tv_usec 0) {
PW32G(starttime).tv_usec += 100;
--PW32G(starttime).tv_sec;
}
PW32G(starttime).tv_sec -= (int)dt;
while(1)
[PHP-BUG] Bug #52789 [NEW]: microtime() loses time in long-running scripts (please reopen)
From: Operating system: Windows XP PHP version: 5.3.3 Package: Date/time related Bug Type: Bug Bug description:microtime() loses time in long-running scripts (please reopen) Description: This is just a reminder for Bug #42659 since I cannot reopen that one. The problem with time difference between time() and microtime() on Windows XP is still there. Please reopen Bug #42659 -- Edit bug report at http://bugs.php.net/bug.php?id=52789edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52789r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52789r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52789r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52789r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52789r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52789r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52789r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52789r=needscript Try newer version: http://bugs.php.net/fix.php?id=52789r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52789r=support Expected behavior: http://bugs.php.net/fix.php?id=52789r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52789r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52789r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52789r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52789r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52789r=dst IIS Stability: http://bugs.php.net/fix.php?id=52789r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52789r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52789r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52789r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52789r=mysqlcfg
Bug #52788 [Bgs]: preg_match not matching last backslash '\'
Edit report at http://bugs.php.net/bug.php?id=52788edit=1
ID: 52788
User updated by:reevsey at gmail dot com
Reported by:reevsey at gmail dot com
Summary:preg_match not matching last backslash '\'
Status: Bogus
Type: Bug
Package:*Regular Expressions
Operating System: ALL
PHP Version:5.3.3
Block user comment: N
New Comment:
Thanks for your speedy reply. Yes your absolutely right and sorry for my
mistake.
The code fragment I posted is from a larger code base and for whatever
reason backslash was the only character that was not being matched.
Other invalid characters '#$%^' etc. even with valid chars beforehand
were being matched, which made it seem like a bug.
Anyway replacing the expression makes it work.
Once again thanks for your time and the suggested use of the other
functions, the expression posted will form a larger expression evently
and indeed will need the anchoring back; my mistake.
Previous Comments:
[2010-09-07 08:03:00] ras...@php.net
And if you replace that backslash with any other character that is not
in your
range, you will see the same thing. It has nothing to do with the
backslash.
Your regex is simply completely wrong.
Your regex says:
From the start of the string ^
Find me 0 or more characters that are not [^0-9a-zA-Z]*
Until the end of the string $
Your problem is that you have anchored it to the start of the string.
In each
of your not matched cases, you have a valid char as the first char.
What you probably meant to write was:
'#[^0-9a-zA-Z]+#'
By not anchoring your regex to the start or end of the string, you are
telling
it to look for invalid characters anywhere in the string. And you want
+
instead of * because you want to match at least 1 invalid char, not 0.
By the way, there are much quicker ways of doing this if your list of
valid or
invalid chars is finite. See strpbrk and strcspn.
[2010-09-07 07:37:44] reevsey at gmail dot com
Description:
preg_match() does not match the last backslash at the end of a subject
string.
I'm using the pattern #^[^0-9a-zA-Z]*$# to filter out any characters
from user input other than alphanumerics.
The Problem I'm seeing is if there is a backslash \ as the last
character with valid characters before it, then preg_match() does not
match it.
Example input:
\= matched.
\\ = matched.
a\a = matched.
@$ = matched.
a\ = not matched.
0\ = not matched.
A\ = not matched.
abc\ = not matched.
etc...
Test script:
---
// Obviously taking into account here that backslash \ is an escape
char.
// SO double the backslash.
$userInput = a\\;
if (preg_match(#^[^0-9a-zA-Z]*$#, $userInput))
{
echo Invalid input;
}
else
{
echo Good to go!;
}
// If you negate the regular expression to #^[0-9a-zA-Z]*$# and change
the
// test statement to be:
// if (!preg_match(#^[0-9a-zA-Z]*$#, $userInput)) {}
// it works as expected.
Expected result:
Expected result: Invalid input
Actual result:
--
Actual result: Good to go!
--
Edit this bug report at http://bugs.php.net/bug.php?id=52788edit=1
Bug #50953 [PATCH]: fsockopen will not work on 'localhost'
Edit report at http://bugs.php.net/bug.php?id=50953edit=1
ID: 50953
Patch added by: cataphr...@php.net
Reported by:tony at marston-home dot demon dot co dot uk
Summary:fsockopen will not work on 'localhost'
Status: Bogus
Type: Bug
Package:Sockets related
Operating System: Windows XP
PHP Version:5.2.12
Block user comment: N
New Comment:
The following patch has been added/updated:
Patch Name: connect_fix_win32
Revision: 1283848007
URL:
http://bugs.php.net/patch-display.php?bug=50953patch=connect_fix_win32revision=1283848007
Previous Comments:
[2010-02-12 14:22:47] tony at marston-home dot demon dot co dot uk
If IPv6 support is enabled in the operating system it does NOT mean that
only IPv6 addresses are allowed, it means that both IPv5 and IPv6
addresses are supported.
All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.
The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.
The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.
fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.
So why does fsockopen() in php 5.2.12 have a problem?
[2010-02-10 11:27:25] tony at marston-home dot demon dot co dot uk
This has got nothing to do with IPV6 addresses as my hosts file does not
contain anf IPV6 addresses. All it has is as follows:
127.0.0.1 localhost
Every other piece of software on my PC uses 'loalhost' without a
problem, so should fsockopen in PHP. Curl can manage it, so why not
fsockopen.
I have the same setup on another PC which runs Windows XP with IPV6
support and PHP 5.3.0, and it does not have a problem with 'localhost',
so this is a genuine bug in 5.2
Do not keep telling me that you have already addressed this issue in
other posts because you have not. You nhave suggested removing any IPV6
entries from the hosts file, which I have done, but this does not fix
the problem.
If gethostbyname() can work with 'localhost' then why can't fsockopen()?
[2010-02-10 11:06:08] paj...@php.net
It works just fine here using localhost and ipv4.
You are clearly experiencing the IPv6 problem described in a good dozen
bugs here (with solutions).
I'm sorry if it is not acceptable but we can't do anything about that,
see the other reports for a complete and detailed explanation.
[2010-02-10 10:57:11] tony at marston-home dot demon dot co dot uk
THIS IS NOT BOGUS, IT IS A GENUINE BUG!!!
If print_r(gethostbynamel('localhost')); produces the following:
Array
(
[0] = 127.0.0.1
)
then why can't fsockopen connect to 'localhost'? It is a valid name
which is recognised by every other piece of software on my computer, so
there is no good reason why fsockopen should have a problem with it.
I have another PC which runs 5.3.0 where fsockopen does not have a
problem with 'localhost', therefore there is a bug in 5.2
[2010-02-10 10:18:16] paj...@php.net
Already explained why it can't and won't be fixed in 5.2, neither in
5.3. Use the IP then instead of the hostname. Bogus (duplicated, not
really a bug per se but a feature,etc.)
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/bug.php?id=50953
--
Edit this bug report at http://bugs.php.net/bug.php?id=50953edit=1
Bug #50953 [Bgs-Asn]: fsockopen will not work on 'localhost'
Edit report at http://bugs.php.net/bug.php?id=50953edit=1
ID: 50953
Updated by: cataphr...@php.net
Reported by:tony at marston-home dot demon dot co dot uk
Summary:fsockopen will not work on 'localhost'
-Status: Bogus
+Status: Assigned
Type: Bug
Package:Sockets related
Operating System: Windows XP
PHP Version:5.2.12
-Assigned To:
+Assigned To:pajoye
Block user comment: N
Previous Comments:
[2010-09-07 10:26:47] cataphr...@php.net
The following patch has been added/updated:
Patch Name: connect_fix_win32
Revision: 1283848007
URL:
http://bugs.php.net/patch-display.php?bug=50953patch=connect_fix_win32revision=1283848007
[2010-02-12 14:22:47] tony at marston-home dot demon dot co dot uk
If IPv6 support is enabled in the operating system it does NOT mean that
only IPv6 addresses are allowed, it means that both IPv5 and IPv6
addresses are supported.
All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.
The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.
The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.
fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.
So why does fsockopen() in php 5.2.12 have a problem?
[2010-02-10 11:27:25] tony at marston-home dot demon dot co dot uk
This has got nothing to do with IPV6 addresses as my hosts file does not
contain anf IPV6 addresses. All it has is as follows:
127.0.0.1 localhost
Every other piece of software on my PC uses 'loalhost' without a
problem, so should fsockopen in PHP. Curl can manage it, so why not
fsockopen.
I have the same setup on another PC which runs Windows XP with IPV6
support and PHP 5.3.0, and it does not have a problem with 'localhost',
so this is a genuine bug in 5.2
Do not keep telling me that you have already addressed this issue in
other posts because you have not. You nhave suggested removing any IPV6
entries from the hosts file, which I have done, but this does not fix
the problem.
If gethostbyname() can work with 'localhost' then why can't fsockopen()?
[2010-02-10 11:06:08] paj...@php.net
It works just fine here using localhost and ipv4.
You are clearly experiencing the IPv6 problem described in a good dozen
bugs here (with solutions).
I'm sorry if it is not acceptable but we can't do anything about that,
see the other reports for a complete and detailed explanation.
[2010-02-10 10:57:11] tony at marston-home dot demon dot co dot uk
THIS IS NOT BOGUS, IT IS A GENUINE BUG!!!
If print_r(gethostbynamel('localhost')); produces the following:
Array
(
[0] = 127.0.0.1
)
then why can't fsockopen connect to 'localhost'? It is a valid name
which is recognised by every other piece of software on my computer, so
there is no good reason why fsockopen should have a problem with it.
I have another PC which runs 5.3.0 where fsockopen does not have a
problem with 'localhost', therefore there is a bug in 5.2
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/bug.php?id=50953
--
Edit this bug report at http://bugs.php.net/bug.php?id=50953edit=1
Bug #50953 [Asn]: fsockopen will not work on 'localhost'
Edit report at http://bugs.php.net/bug.php?id=50953edit=1
ID: 50953
Updated by: cataphr...@php.net
Reported by:tony at marston-home dot demon dot co dot uk
Summary:fsockopen will not work on 'localhost'
Status: Assigned
Type: Bug
Package:Sockets related
Operating System: Windows XP
PHP Version:5.2.12
Assigned To:pajoye
Block user comment: N
New Comment:
This is indeed a bug.
The problem is that PHP doesn't detect a connection was actively refused
and instead times out on it.
The scenario where the address has both ipv4 and ipv6 addresses, the
service is only listening on ipv4 and ipv6 has precedence results in:
a) trying ipv6
b) time out
c) fail
instead of
a) trying ipv6
b) connection refused
c) trying ipv4
d) success
I've attached a patch that fixes the issue.
Previous Comments:
[2010-09-07 10:26:47] cataphr...@php.net
The following patch has been added/updated:
Patch Name: connect_fix_win32
Revision: 1283848007
URL:
http://bugs.php.net/patch-display.php?bug=50953patch=connect_fix_win32revision=1283848007
[2010-02-12 14:22:47] tony at marston-home dot demon dot co dot uk
If IPv6 support is enabled in the operating system it does NOT mean that
only IPv6 addresses are allowed, it means that both IPv5 and IPv6
addresses are supported.
All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.
The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.
The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.
fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.
So why does fsockopen() in php 5.2.12 have a problem?
[2010-02-10 11:27:25] tony at marston-home dot demon dot co dot uk
This has got nothing to do with IPV6 addresses as my hosts file does not
contain anf IPV6 addresses. All it has is as follows:
127.0.0.1 localhost
Every other piece of software on my PC uses 'loalhost' without a
problem, so should fsockopen in PHP. Curl can manage it, so why not
fsockopen.
I have the same setup on another PC which runs Windows XP with IPV6
support and PHP 5.3.0, and it does not have a problem with 'localhost',
so this is a genuine bug in 5.2
Do not keep telling me that you have already addressed this issue in
other posts because you have not. You nhave suggested removing any IPV6
entries from the hosts file, which I have done, but this does not fix
the problem.
If gethostbyname() can work with 'localhost' then why can't fsockopen()?
[2010-02-10 11:06:08] paj...@php.net
It works just fine here using localhost and ipv4.
You are clearly experiencing the IPv6 problem described in a good dozen
bugs here (with solutions).
I'm sorry if it is not acceptable but we can't do anything about that,
see the other reports for a complete and detailed explanation.
[2010-02-10 10:57:11] tony at marston-home dot demon dot co dot uk
THIS IS NOT BOGUS, IT IS A GENUINE BUG!!!
If print_r(gethostbynamel('localhost')); produces the following:
Array
(
[0] = 127.0.0.1
)
then why can't fsockopen connect to 'localhost'? It is a valid name
which is recognised by every other piece of software on my computer, so
there is no good reason why fsockopen should have a problem with it.
I have another PC which runs 5.3.0 where fsockopen does not have a
problem with 'localhost', therefore there is a bug in 5.2
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/bug.php?id=50953
--
Edit this bug report at http://bugs.php.net/bug.php?id=50953edit=1
Bug #51079 [Asn]: fsockopen will not work on 'localhost'
Edit report at http://bugs.php.net/bug.php?id=51079edit=1
ID: 51079
Updated by: cataphr...@php.net
Reported by:tony at marston-home dot demon dot co dot uk
Summary:fsockopen will not work on 'localhost'
Status: Assigned
Type: Bug
Package:Sockets related
Operating System: win32 only - Windows XP
PHP Version:5.2.12
Assigned To:pajoye
Block user comment: N
New Comment:
Oops I hadn't noticed this bug existed and modified #50953 instead.
Sorry.
Previous Comments:
[2010-08-25 17:57:19] galatmc at gmail dot com
One small note, if this is of any help. First, I am new to PHP, and ran
into this same issue with PHPMyAdmin and Drupal. I am on Windows 7 x64,
and found some info on another site. However, In my case, I was having
an issue with Drupal trying to check http://family-hp/ (my computer
name). At the time, my hosts file (c:\windows\system32\etc\hosts)
contained:
127.0.0.1 localhost
::1 localhost
When I ran the script, I received:
called connect('family-hp')
faultcode=10060, faultstring=A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond.
called connect('localhost')
faultcode=10060, faultstring=A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond.
called connect('127.0.0.1')
Connected to 127.0.0.1 OK
called connect('www.tonymarston.net')
Connected to www.tonymarston.net OK
(note: I added a piece of code to indicate how 'connect' was called.)
I made the following changes to hosts:
1. Added a line for family-hp (not sure why I need this, since IE has no
problem resolving my computer name!).
2. Based on information I found on another site, I commented out the
IPv6 loopback.
New hosts file:
127.0.0.1 family-hp
127.0.0.1 localhost
#::1localhost
Rerun of script:
called connect('family-hp')
Connected to family-hp OK
called connect('localhost')
Connected to localhost OK
called connect('127.0.0.1')
Connected to 127.0.0.1 OK
called connect('www.tonymarston.net')
Connected to www.tonymarston.net OK
So, if you give hosts a single choice of IPv4 loopback, and no IPv6
loopback, it works!
Mike
[2010-05-11 13:41:25] anders at ingemann dot de
I can confirm this on Vista x86 with the precompiled 5.3.2 VC6 ts
[2010-04-28 00:03:32] jbphp at jlb dot nu
We recently upgraded to PHP 5.3.2 and can replicate this problem under
Windows 7 x64.
Luckily the workaround of using '127.0.0.1' in the fsockopen address
instead of 'localhost' is relatively easy but it broke a large volume of
our existing code. Very annoying.
Please fix this asap.
[2010-03-13 20:26:19] dontwantanyspam at mailinator dot com
Forgot to mention my operating system. Windows 7 x64.
[2010-03-13 20:22:24] dontwantanyspam at mailinator dot com
I can also confirm that this problem isn't there in PHP 5.3.0. Its there
since
5.3.1.
Unlike PHP 5.3.0, a 64 bit version of PHP 5.3.1 wasn't available at
http://windows.php.net/qa/, so I tried compiling it myself. After
compiling I
noticed that a script that uses
file_get_contents(http://localhost/...;)
wouldn't work until I change the localhost to 127.0.0.1. I didn't
care about
it much at that time since it seemed like a small problem. But then I
noticed
that none of the scripts that used mysql were working. I even tried to
log in to
phpMyAdmin and even that didn't work (same problem described by
thijsputman). So
I thought that it was probably a bug with the 64 bit binary and
continued using
PHP 5.3.0.
But after PHP 5.3.2 was released, I tried compiling it also and noticed
that the
problem was still there. Thinking that it may be related to mysqlnd
since the
version used by PHP 5.3.0 is 5.0.5-dev and the one used by PHP 5.3.2 is
5.0.7-
dev, I tried compiling the mysql, mysqli and pdo mysql extensions with
libmysql.
I has success with the mysql extension only. The mysqli and pdo mysql
extension
failed to compile with libmysql (there were a lot of build errors).
Anyway, I
tried the mysql extension compiled with libmysql and noticed that it was
working
fine! But I needed the mysqli extension to work also and since it failed
to
compile with libmysql, I messed around some more and finally realized
that it
was the same problem as with the
Bug #51079 [Asn-Dup]: fsockopen will not work on 'localhost'
Edit report at http://bugs.php.net/bug.php?id=51079edit=1
ID: 51079
Updated by: paj...@php.net
Reported by:tony at marston-home dot demon dot co dot uk
Summary:fsockopen will not work on 'localhost'
-Status: Assigned
+Status: Duplicate
Type: Bug
Package:Sockets related
Operating System: win32 only - Windows XP
PHP Version:5.2.12
Assigned To:pajoye
Block user comment: N
New Comment:
Fix and discussions will go now into the bug #50963.
Previous Comments:
[2010-09-07 10:59:53] cataphr...@php.net
Oops I hadn't noticed this bug existed and modified #50953 instead.
Sorry.
[2010-08-25 17:57:19] galatmc at gmail dot com
One small note, if this is of any help. First, I am new to PHP, and ran
into this same issue with PHPMyAdmin and Drupal. I am on Windows 7 x64,
and found some info on another site. However, In my case, I was having
an issue with Drupal trying to check http://family-hp/ (my computer
name). At the time, my hosts file (c:\windows\system32\etc\hosts)
contained:
127.0.0.1 localhost
::1 localhost
When I ran the script, I received:
called connect('family-hp')
faultcode=10060, faultstring=A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond.
called connect('localhost')
faultcode=10060, faultstring=A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond.
called connect('127.0.0.1')
Connected to 127.0.0.1 OK
called connect('www.tonymarston.net')
Connected to www.tonymarston.net OK
(note: I added a piece of code to indicate how 'connect' was called.)
I made the following changes to hosts:
1. Added a line for family-hp (not sure why I need this, since IE has no
problem resolving my computer name!).
2. Based on information I found on another site, I commented out the
IPv6 loopback.
New hosts file:
127.0.0.1 family-hp
127.0.0.1 localhost
#::1localhost
Rerun of script:
called connect('family-hp')
Connected to family-hp OK
called connect('localhost')
Connected to localhost OK
called connect('127.0.0.1')
Connected to 127.0.0.1 OK
called connect('www.tonymarston.net')
Connected to www.tonymarston.net OK
So, if you give hosts a single choice of IPv4 loopback, and no IPv6
loopback, it works!
Mike
[2010-05-11 13:41:25] anders at ingemann dot de
I can confirm this on Vista x86 with the precompiled 5.3.2 VC6 ts
[2010-04-28 00:03:32] jbphp at jlb dot nu
We recently upgraded to PHP 5.3.2 and can replicate this problem under
Windows 7 x64.
Luckily the workaround of using '127.0.0.1' in the fsockopen address
instead of 'localhost' is relatively easy but it broke a large volume of
our existing code. Very annoying.
Please fix this asap.
[2010-03-13 20:26:19] dontwantanyspam at mailinator dot com
Forgot to mention my operating system. Windows 7 x64.
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/bug.php?id=51079
--
Edit this bug report at http://bugs.php.net/bug.php?id=51079edit=1
Bug #47437 [Bgs]: fsockopen doesn't work with DNS names, only IPs
Edit report at http://bugs.php.net/bug.php?id=47437edit=1 ID: 47437 Updated by: paj...@php.net Reported by:ogi at triangle dot bg Summary:fsockopen doesn't work with DNS names, only IPs Status: Bogus Type: Bug Package:Sockets related Operating System: Windows XP Pro SP3 PHP Version:5.2.9RC2 Assigned To:pajoye Block user comment: N New Comment: Fix and discussions will go now into the bug #50963. Previous Comments: [2009-02-18 17:16:18] paj...@php.net no php bug, it tries to contact localhost which was certainly updated to IPv6 ::1, or the server was using IPv6 and not ipv4. In both cases it is not a bug. (bogus) [2009-02-18 17:12:17] ogi at triangle dot bg Bingo! After uninstalling IPv6 everything works as expected. I remember that I installed IPv6 for XP and after that I didn't used Drupal. Today I updated Drupal and fell into this problem. I don't know if this is PHP problem or some underlining library (XP bug?). [2009-02-18 17:11:28] paj...@php.net what's about IPv6? [2009-02-18 17:05:52] ogi at triangle dot bg C:\WINDOWS\system32\drivers\etc\hosts contains 127.0.0.1 localhost and other entries are irrelevant to this case. This happened after some Drupal updates but I can't see how this can influence PHP itself - the above PHP example is isolated from Drupal framework. [2009-02-18 17:03:53] paj...@php.net Can you check that you do not have IPv6 enabled (it is not in xp Pro afaict)? I think it is enabled and your host file should have a line like: ::1 locahost ..other hosts... comment it out and be sure that the ipv4 127.0.0.1 aliases are in place. 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/bug.php?id=47437 -- Edit this bug report at http://bugs.php.net/bug.php?id=47437edit=1
Bug #47437 [Bgs-Dup]: fsockopen doesn't work with DNS names, only IPs
Edit report at http://bugs.php.net/bug.php?id=47437edit=1 ID: 47437 Updated by: paj...@php.net Reported by:ogi at triangle dot bg Summary:fsockopen doesn't work with DNS names, only IPs -Status: Bogus +Status: Duplicate Type: Bug Package:Sockets related Operating System: Windows XP Pro SP3 PHP Version:5.2.9RC2 Assigned To:pajoye Block user comment: N Previous Comments: [2010-09-07 11:19:20] paj...@php.net Fix and discussions will go now into the bug #50963. [2009-02-18 17:16:18] paj...@php.net no php bug, it tries to contact localhost which was certainly updated to IPv6 ::1, or the server was using IPv6 and not ipv4. In both cases it is not a bug. (bogus) [2009-02-18 17:12:17] ogi at triangle dot bg Bingo! After uninstalling IPv6 everything works as expected. I remember that I installed IPv6 for XP and after that I didn't used Drupal. Today I updated Drupal and fell into this problem. I don't know if this is PHP problem or some underlining library (XP bug?). [2009-02-18 17:11:28] paj...@php.net what's about IPv6? [2009-02-18 17:05:52] ogi at triangle dot bg C:\WINDOWS\system32\drivers\etc\hosts contains 127.0.0.1 localhost and other entries are irrelevant to this case. This happened after some Drupal updates but I can't see how this can influence PHP itself - the above PHP example is isolated from Drupal framework. 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/bug.php?id=47437 -- Edit this bug report at http://bugs.php.net/bug.php?id=47437edit=1
Bug #50965 [Bgs]: fsockopen will not work on 'localhost'
Edit report at http://bugs.php.net/bug.php?id=50965edit=1
ID: 50965
Updated by: paj...@php.net
Reported by:tony at marston-home dot demon dot co dot uk
Summary:fsockopen will not work on 'localhost'
Status: Bogus
Type: Bug
Package:Sockets related
Operating System: Windows XP
PHP Version:5.2.12
Block user comment: N
New Comment:
Fix and discussions will go now into the bug #50953.
Previous Comments:
[2010-02-08 17:55:43] tony at marston-home dot demon dot co dot uk
print_r(gethostbynamel('localhost')); produces the following:
Array
(
[0] = 127.0.0.1
)
[2010-02-08 17:39:14] ras...@php.net
There is no special-case code in PHP for localhost.
Try: print_r(gethostbynamel('localhost'));
[2010-02-08 17:32:36] tony at marston-home dot demon dot co dot uk
I have checked my hosts file, and it only contains the following entry
for 'localhost':
127.0.0.1 localhost
I have rebooted my PC to clear any cache, but the error is still there.
The name 'localhost' works in all the browsers that I use - IE, Firefox,
Opera and Safari - so it should work with fsockopen. It works with names
I use for other PCs in my home network.
I have another PC running Windows XP with IPV6 enabled and PHP 5.3.0,
and fsockopen doesn't have a problem using 'localhost' there.
[2010-02-08 17:07:40] ras...@php.net
If 127.0.0.1 works and your name lookup system correctly returns
127.0.0.1 for localhost, then localhost has to work. If it isn't
working it is because the lookup isn't returning the correct ipv4 ip.
You may have removed it from your hosts file, but perhaps the old
answer is cached somewhere. Try restarting things after changing your
hosts file.
[2010-02-08 11:57:49] tony at marston-home dot demon dot co dot uk
I did respond in the original bug, but you closed it before finding out
if your suggestion about removing the IPV6 entries from my hosts file
actually worked. I put in a reply saying that it hadn't worked, but you
never re-opened the bug. I assumed that as you had closed it that you
were refusing to answer any more queries about 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
http://bugs.php.net/bug.php?id=50965
--
Edit this bug report at http://bugs.php.net/bug.php?id=50965edit=1
Bug #47437 [Dup]: fsockopen doesn't work with DNS names, only IPs
Edit report at http://bugs.php.net/bug.php?id=47437edit=1 ID: 47437 Updated by: paj...@php.net Reported by:ogi at triangle dot bg Summary:fsockopen doesn't work with DNS names, only IPs Status: Duplicate Type: Bug Package:Sockets related Operating System: Windows XP Pro SP3 PHP Version:5.2.9RC2 Assigned To:pajoye Block user comment: N New Comment: Fix and discussions will go now into the bug #50953. Previous Comments: [2010-09-07 11:19:20] paj...@php.net Fix and discussions will go now into the bug #50963. [2009-02-18 17:16:18] paj...@php.net no php bug, it tries to contact localhost which was certainly updated to IPv6 ::1, or the server was using IPv6 and not ipv4. In both cases it is not a bug. (bogus) [2009-02-18 17:12:17] ogi at triangle dot bg Bingo! After uninstalling IPv6 everything works as expected. I remember that I installed IPv6 for XP and after that I didn't used Drupal. Today I updated Drupal and fell into this problem. I don't know if this is PHP problem or some underlining library (XP bug?). [2009-02-18 17:11:28] paj...@php.net what's about IPv6? [2009-02-18 17:05:52] ogi at triangle dot bg C:\WINDOWS\system32\drivers\etc\hosts contains 127.0.0.1 localhost and other entries are irrelevant to this case. This happened after some Drupal updates but I can't see how this can influence PHP itself - the above PHP example is isolated from Drupal framework. 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/bug.php?id=47437 -- Edit this bug report at http://bugs.php.net/bug.php?id=47437edit=1
Bug #51079 [Dup]: fsockopen will not work on 'localhost'
Edit report at http://bugs.php.net/bug.php?id=51079edit=1
ID: 51079
Updated by: paj...@php.net
Reported by:tony at marston-home dot demon dot co dot uk
Summary:fsockopen will not work on 'localhost'
Status: Duplicate
Type: Bug
Package:Sockets related
Operating System: win32 only - Windows XP
PHP Version:5.2.12
Assigned To:pajoye
Block user comment: N
New Comment:
Fix and discussions will go now into the bug #50953.
Previous Comments:
[2010-09-07 11:19:04] paj...@php.net
Fix and discussions will go now into the bug #50963.
[2010-09-07 10:59:53] cataphr...@php.net
Oops I hadn't noticed this bug existed and modified #50953 instead.
Sorry.
[2010-08-25 17:57:19] galatmc at gmail dot com
One small note, if this is of any help. First, I am new to PHP, and ran
into this same issue with PHPMyAdmin and Drupal. I am on Windows 7 x64,
and found some info on another site. However, In my case, I was having
an issue with Drupal trying to check http://family-hp/ (my computer
name). At the time, my hosts file (c:\windows\system32\etc\hosts)
contained:
127.0.0.1 localhost
::1 localhost
When I ran the script, I received:
called connect('family-hp')
faultcode=10060, faultstring=A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond.
called connect('localhost')
faultcode=10060, faultstring=A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond.
called connect('127.0.0.1')
Connected to 127.0.0.1 OK
called connect('www.tonymarston.net')
Connected to www.tonymarston.net OK
(note: I added a piece of code to indicate how 'connect' was called.)
I made the following changes to hosts:
1. Added a line for family-hp (not sure why I need this, since IE has no
problem resolving my computer name!).
2. Based on information I found on another site, I commented out the
IPv6 loopback.
New hosts file:
127.0.0.1 family-hp
127.0.0.1 localhost
#::1localhost
Rerun of script:
called connect('family-hp')
Connected to family-hp OK
called connect('localhost')
Connected to localhost OK
called connect('127.0.0.1')
Connected to 127.0.0.1 OK
called connect('www.tonymarston.net')
Connected to www.tonymarston.net OK
So, if you give hosts a single choice of IPv4 loopback, and no IPv6
loopback, it works!
Mike
[2010-05-11 13:41:25] anders at ingemann dot de
I can confirm this on Vista x86 with the precompiled 5.3.2 VC6 ts
[2010-04-28 00:03:32] jbphp at jlb dot nu
We recently upgraded to PHP 5.3.2 and can replicate this problem under
Windows 7 x64.
Luckily the workaround of using '127.0.0.1' in the fsockopen address
instead of 'localhost' is relatively easy but it broke a large volume of
our existing code. Very annoying.
Please fix this asap.
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/bug.php?id=51079
--
Edit this bug report at http://bugs.php.net/bug.php?id=51079edit=1
[PHP-BUG] Bug #52791 [NEW]: SoapServer doesn't convert objects into SOAP Response
From:
Operating system: Gentoo
PHP version: 5.3.3
Package: SOAP related
Bug Type: Bug
Bug description:SoapServer doesn't convert objects into SOAP Response
Description:
Hi,
I'm using SoapServer and the classmap feature to convert WSDL Types into
PHP
classes. This works fine for input (SOAP-Envelope=PHP), but not for output
(PHP=SOAP-Envelope).
I have created a simple WSDL (see http://www.timohummel.com/test.wsdl )
which
accepts the same WSDL type for input and output.
For testing purposes, I simply return the input from the test call to the
output, which fails with SOAP-ERROR: Encoding: object hasn't 'username'
property. If I add a serialize around $user, no error is thrown, but an
empty
object is returned.
See below for the code.
In my example PHP code, if I replace
return array(User = $user);
with
return array(User = array(username = 1, password = 2);
it works. This means that the PHP SOAP extension does not convert an object
to
the WSDL datatype.
If this is intentional, please document this in the online manual.
Test script:
---
?php
/* Use the example WSDL from http://www.timohummel.com/test.wsdl to test
*/
class User {
public $username;
public $password;
}
class UserService {
public function createUser (User $user) {
return array(User = $user); // - this doesn't work,
throws an
encoding error
//return array(User = array(username = 1,
password = 2); - this works, but isn't intented
//return array(User = serialize($user)); - this
doesn't work, returns an empty User/ tag
}
}
$server = new SoapServer(test.wsdl, array(cache_wsdl =
WSDL_CACHE_NONE, classmap = array(User = User)));
$server-setClass(UserService);
$server-handle();
?
--
Edit bug report at http://bugs.php.net/bug.php?id=52791edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52791r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52791r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52791r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52791r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52791r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52791r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52791r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52791r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52791r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52791r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52791r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52791r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52791r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52791r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52791r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52791r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52791r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52791r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52791r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52791r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52791r=mysqlcfg
[PHP-BUG] Bug #52792 [NEW]: core dump
From: Operating system: FreeBSD 7.2 PHP version: 5.3.3 Package: Unknown/Other Function Bug Type: Bug Bug description:core dump Description: db4# php -m [PHP Modules] Core date ereg json libxml memcached pcre Reflection session SPL standard xml [Zend Modules] Segmentation fault (core dumped) The problem only occur when memcached extension is loaded. Actual result: -- db4# gdb /usr/local/bin/php php.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Core was generated by `php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.4...done. Loaded symbols for /lib/libcrypt.so.4 Reading symbols from /usr/local/lib/libpcre.so.0...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/local/lib/libxml2.so.5...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /lib/libz.so.4...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x7b5647b0 in ?? () (gdb) bt #0 0x7b5647b0 in ?? () #1 0x7a74b7d5 in xmlFreeMutex () from /usr/local/lib/libxml2.so.5 #2 0x7a74b215 in xmlCleanupGlobals () from /usr/local/lib/libxml2.so.5 #3 0x7a6e3d3a in xmlCleanupParser () from /usr/local/lib/libxml2.so.5 #4 0x0045f338 in php_libxml_shutdown () at /usr/ports/lang/php5/work/php-5.3.3/ext/libxml/libxml.c:583 #5 0x0045f823 in zm_shutdown_libxml (type=1, module_number=3) at /usr/ports/lang/php5/work/php-5.3.3/ext/libxml/libxml.c:655 #6 0x005c6b26 in module_destructor (module=0x7af61270) at /usr/ports/lang/php5/work/php-5.3.3/Zend/zend_API.c:2098 #7 0x005ce1f4 in zend_hash_apply_deleter (ht=0x8b4460, p=0x7afbd4c0) at /usr/ports/lang/php5/work/php-5.3.3/Zend/zend_hash.c:611 #8 0x005ce35a in zend_hash_graceful_reverse_destroy (ht=0x8b4460) at /usr/ports/lang/php5/work/php-5.3.3/Zend/zend_hash.c:646 #9 0x005bc888 in zend_shutdown () at /usr/ports/lang/php5/work/php-5.3.3/Zend/zend.c:759 #10 0x00548aad in php_module_shutdown () at /usr/ports/lang/php5/work/php-5.3.3/main/main.c:2138 #11 0x006abff6 in main (argc=2, argv=0x7fffec68) at /usr/ports/lang/php5/work/php-5.3.3/sapi/cli/php_cli.c:1387 (gdb) frame 4 #4 0x0045f338 in php_libxml_shutdown () at /usr/ports/lang/php5/work/php-5.3.3/ext/libxml/libxml.c:583 583 xmlCleanupParser(); (gdb) -- Edit bug report at http://bugs.php.net/bug.php?id=52792edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52792r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52792r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52792r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52792r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52792r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52792r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52792r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52792r=needscript Try newer version: http://bugs.php.net/fix.php?id=52792r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52792r=support Expected behavior: http://bugs.php.net/fix.php?id=52792r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52792r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52792r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52792r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52792r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52792r=dst IIS Stability: http://bugs.php.net/fix.php?id=52792r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52792r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52792r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52792r=nozend MySQL Configuration
Bug #50953 [Asn-Csd]: fsockopen will not work on 'localhost'
Edit report at http://bugs.php.net/bug.php?id=50953edit=1 ID: 50953 Updated by: paj...@php.net Reported by:tony at marston-home dot demon dot co dot uk Summary:fsockopen will not work on 'localhost' -Status: Assigned +Status: Closed Type: Bug Package:Sockets related Operating System: Windows XP PHP Version:5.2.12 Assigned To:pajoye Block user comment: N New Comment: 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. Previous Comments: [2010-09-07 11:47:39] paj...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=303129 Log: - fix bug #50953, socket will not connect to IPv4 address when the host has both ipv4 and ipv6 addresses [2010-09-07 10:54:49] cataphr...@php.net This is indeed a bug. The problem is that PHP doesn't detect a connection was actively refused and instead times out on it. The scenario where the address has both ipv4 and ipv6 addresses, the service is only listening on ipv4 and ipv6 has precedence results in: a) trying ipv6 b) time out c) fail instead of a) trying ipv6 b) connection refused c) trying ipv4 d) success I've attached a patch that fixes the issue. [2010-09-07 10:26:47] cataphr...@php.net The following patch has been added/updated: Patch Name: connect_fix_win32 Revision: 1283848007 URL: http://bugs.php.net/patch-display.php?bug=50953patch=connect_fix_win32revision=1283848007 [2010-02-12 14:22:47] tony at marston-home dot demon dot co dot uk If IPv6 support is enabled in the operating system it does NOT mean that only IPv6 addresses are allowed, it means that both IPv5 and IPv6 addresses are supported. All of my web browsers (IE, Firefox, Opera, Safari) have no problem in translating 'localhost' to '127.0.0.1'. The PHP gethostbyname() function has no problem in translating 'localhost' to '127.0.0.1'. The PHP cURL extension has no problem in translating 'localhost' to '127.0.0.1'. fsockopen() when running in PHP 5.3.0 has no problem in translating 'localhost' to '127.0.0.1'. So why does fsockopen() in php 5.2.12 have a problem? [2010-02-10 11:27:25] tony at marston-home dot demon dot co dot uk This has got nothing to do with IPV6 addresses as my hosts file does not contain anf IPV6 addresses. All it has is as follows: 127.0.0.1 localhost Every other piece of software on my PC uses 'loalhost' without a problem, so should fsockopen in PHP. Curl can manage it, so why not fsockopen. I have the same setup on another PC which runs Windows XP with IPV6 support and PHP 5.3.0, and it does not have a problem with 'localhost', so this is a genuine bug in 5.2 Do not keep telling me that you have already addressed this issue in other posts because you have not. You nhave suggested removing any IPV6 entries from the hosts file, which I have done, but this does not fix the problem. If gethostbyname() can work with 'localhost' then why can't fsockopen()? 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/bug.php?id=50953 -- Edit this bug report at http://bugs.php.net/bug.php?id=50953edit=1
Bug #52323 [Asn-Fbk]: php_network_connect_socket doesn't return all errors correctly
Edit report at http://bugs.php.net/bug.php?id=52323edit=1 ID: 52323 Updated by: paj...@php.net Reported by:onno at flox dot org Summary:php_network_connect_socket doesn't return all errors correctly -Status: Assigned +Status: Feedback Type: Bug Package:Sockets related PHP Version:trunk-SVN-2010-07-12 (SVN) Assigned To:pajoye Block user comment: N New Comment: hi, This is related to #50953, can you take a look at the patch and see if that matches what you have done here? Or if we need to apply your patch instead, or part of it. Previous Comments: [2010-07-12 23:07:25] onno at flox dot org Description: php_network_connect_socket doesn't return all connection errors (like ECONNREFUSED) correctly in all cases. When error_string is NULL, ret isn't set to -1, even when error is set. This can cause problems on all platforms. The ftp extension for example will only detect a socket error once it tries to read the socket, instead of directly after the call to php_network_connect_socket. On Windows, an additional problem exists because of the poll() emulation in php_poll2: php_network_connect_socket polls for PHP_POLLREADABLE|POLLOUT, which by php_poll2 is mapped to the readfds and writefds parameters of select(). In winsock however, connect() errors are returned in exceptfds, not in writefds like they are in POSIX. This means the select() call will only return once its timeout has passed and that php_network_connect_socket will incorrectly return PHP_TIMEOUT_ERROR_VALUE. This behaviour causes undesired delays in many functions that (try to) create network connections. An example of this is the long delay that is observed when connecting to a MySQL-server using mysqlnd and a hostname that has both an IPv6 and an IPv4 address: connecting using the IPv6 address will quickly fail, but because of this bug it will take mysql.connect_timeout seconds before the IPv4 address is tried. -- Edit this bug report at http://bugs.php.net/bug.php?id=52323edit=1
Bug #52792 [Opn-Bgs]: core dump
Edit report at http://bugs.php.net/bug.php?id=52792edit=1 ID: 52792 Updated by: paj...@php.net Reported by:ken73 dot chen at gmail dot com Summary:core dump -Status: Open +Status: Bogus Type: Bug Package:Unknown/Other Function Operating System: FreeBSD 7.2 PHP Version:5.3.3 Block user comment: N New Comment: Report the issue to the memcached developers at PECL Previous Comments: [2010-09-07 11:25:31] ken73 dot chen at gmail dot com Description: db4# php -m [PHP Modules] Core date ereg json libxml memcached pcre Reflection session SPL standard xml [Zend Modules] Segmentation fault (core dumped) The problem only occur when memcached extension is loaded. Actual result: -- db4# gdb /usr/local/bin/php php.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Core was generated by `php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.4...done. Loaded symbols for /lib/libcrypt.so.4 Reading symbols from /usr/local/lib/libpcre.so.0...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/local/lib/libxml2.so.5...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /lib/libz.so.4...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x7b5647b0 in ?? () (gdb) bt #0 0x7b5647b0 in ?? () #1 0x7a74b7d5 in xmlFreeMutex () from /usr/local/lib/libxml2.so.5 #2 0x7a74b215 in xmlCleanupGlobals () from /usr/local/lib/libxml2.so.5 #3 0x7a6e3d3a in xmlCleanupParser () from /usr/local/lib/libxml2.so.5 #4 0x0045f338 in php_libxml_shutdown () at /usr/ports/lang/php5/work/php-5.3.3/ext/libxml/libxml.c:583 #5 0x0045f823 in zm_shutdown_libxml (type=1, module_number=3) at /usr/ports/lang/php5/work/php-5.3.3/ext/libxml/libxml.c:655 #6 0x005c6b26 in module_destructor (module=0x7af61270) at /usr/ports/lang/php5/work/php-5.3.3/Zend/zend_API.c:2098 #7 0x005ce1f4 in zend_hash_apply_deleter (ht=0x8b4460, p=0x7afbd4c0) at /usr/ports/lang/php5/work/php-5.3.3/Zend/zend_hash.c:611 #8 0x005ce35a in zend_hash_graceful_reverse_destroy (ht=0x8b4460) at /usr/ports/lang/php5/work/php-5.3.3/Zend/zend_hash.c:646 #9 0x005bc888 in zend_shutdown () at /usr/ports/lang/php5/work/php-5.3.3/Zend/zend.c:759 #10 0x00548aad in php_module_shutdown () at /usr/ports/lang/php5/work/php-5.3.3/main/main.c:2138 #11 0x006abff6 in main (argc=2, argv=0x7fffec68) at /usr/ports/lang/php5/work/php-5.3.3/sapi/cli/php_cli.c:1387 (gdb) frame 4 #4 0x0045f338 in php_libxml_shutdown () at /usr/ports/lang/php5/work/php-5.3.3/ext/libxml/libxml.c:583 583 xmlCleanupParser(); (gdb) -- Edit this bug report at http://bugs.php.net/bug.php?id=52792edit=1
Bug #52792 [Com]: core dump
Edit report at http://bugs.php.net/bug.php?id=52792edit=1 ID: 52792 Comment by: ken73 dot chen at gmail dot com Reported by:ken73 dot chen at gmail dot com Summary:core dump Status: Bogus Type: Bug Package:Unknown/Other Function Operating System: FreeBSD 7.2 PHP Version:5.3.3 Block user comment: N New Comment: I have done, but developers thinks the problem is on libxml2. developers http://pecl.php.net/bugs/bug.php?id=18509 Previous Comments: [2010-09-07 11:33:21] paj...@php.net Report the issue to the memcached developers at PECL [2010-09-07 11:25:31] ken73 dot chen at gmail dot com Description: db4# php -m [PHP Modules] Core date ereg json libxml memcached pcre Reflection session SPL standard xml [Zend Modules] Segmentation fault (core dumped) The problem only occur when memcached extension is loaded. Actual result: -- db4# gdb /usr/local/bin/php php.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Core was generated by `php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.4...done. Loaded symbols for /lib/libcrypt.so.4 Reading symbols from /usr/local/lib/libpcre.so.0...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/local/lib/libxml2.so.5...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /lib/libz.so.4...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x7b5647b0 in ?? () (gdb) bt #0 0x7b5647b0 in ?? () #1 0x7a74b7d5 in xmlFreeMutex () from /usr/local/lib/libxml2.so.5 #2 0x7a74b215 in xmlCleanupGlobals () from /usr/local/lib/libxml2.so.5 #3 0x7a6e3d3a in xmlCleanupParser () from /usr/local/lib/libxml2.so.5 #4 0x0045f338 in php_libxml_shutdown () at /usr/ports/lang/php5/work/php-5.3.3/ext/libxml/libxml.c:583 #5 0x0045f823 in zm_shutdown_libxml (type=1, module_number=3) at /usr/ports/lang/php5/work/php-5.3.3/ext/libxml/libxml.c:655 #6 0x005c6b26 in module_destructor (module=0x7af61270) at /usr/ports/lang/php5/work/php-5.3.3/Zend/zend_API.c:2098 #7 0x005ce1f4 in zend_hash_apply_deleter (ht=0x8b4460, p=0x7afbd4c0) at /usr/ports/lang/php5/work/php-5.3.3/Zend/zend_hash.c:611 #8 0x005ce35a in zend_hash_graceful_reverse_destroy (ht=0x8b4460) at /usr/ports/lang/php5/work/php-5.3.3/Zend/zend_hash.c:646 #9 0x005bc888 in zend_shutdown () at /usr/ports/lang/php5/work/php-5.3.3/Zend/zend.c:759 #10 0x00548aad in php_module_shutdown () at /usr/ports/lang/php5/work/php-5.3.3/main/main.c:2138 #11 0x006abff6 in main (argc=2, argv=0x7fffec68) at /usr/ports/lang/php5/work/php-5.3.3/sapi/cli/php_cli.c:1387 (gdb) frame 4 #4 0x0045f338 in php_libxml_shutdown () at /usr/ports/lang/php5/work/php-5.3.3/ext/libxml/libxml.c:583 583 xmlCleanupParser(); (gdb) -- Edit this bug report at http://bugs.php.net/bug.php?id=52792edit=1
Bug #52323 [Fbk]: php_network_connect_socket doesn't return all errors correctly
Edit report at http://bugs.php.net/bug.php?id=52323edit=1 ID: 52323 Updated by: cataphr...@php.net Reported by:spam at geleia dot net Summary:php_network_connect_socket doesn't return all errors correctly Status: Feedback Type: Bug Package:Sockets related PHP Version:trunk-SVN-2010-07-12 (SVN) Assigned To:pajoye Block user comment: N New Comment: I think it makes moresense leave php_poll2 untouched. See http://linux.die.net/man/2/poll, which is being emulated and http://msdn.microsoft.com/en-us/library/ms740141(VS.85).aspx which is being used for the implementation. The patch in this bug report fills the exceptfds if POLLERR is given, instead of POLLPRI. However, POLLERR is supposed to be output only as per poll(2)'s specification. This way, * PHP_POLLREADABLE can be given to check if there's data to be read -- although, like the comment in php_poll2 says, it can also mean POLLHUP and POLLERR. Since we can't know this without probing, we default to retuning POLLIN. * POLLOUT can be given to check if data can be sent/will not block. In windows, it can also mean a nonblocking connection was successful. We can't distinguish between the two, so we return POLLOUT. * POLLPRI can be given to check if processing a connect call (nonblocking), connection attempt failed or OOB data is available for reading (only if SO_OOBINLINE is disabled). Again, we can't distinguish between the two, so we return POLLPRI. It has to be caller that disambiguates the return value. In Windows, in case of a nonblocking connect call, we should pass POLLOUT|POLLPRI. When read the return, we know that POLLOUT means the connection was successful and POLLPRI means the connection failed (see patch for bug #50953). Previous Comments: [2010-09-07 11:59:45] paj...@php.net hi, This is related to #50953, can you take a look at the patch and see if that matches what you have done here? Or if we need to apply your patch instead, or part of it. [2010-07-12 23:07:25] spam at geleia dot net Description: php_network_connect_socket doesn't return all connection errors (like ECONNREFUSED) correctly in all cases. When error_string is NULL, ret isn't set to -1, even when error is set. This can cause problems on all platforms. The ftp extension for example will only detect a socket error once it tries to read the socket, instead of directly after the call to php_network_connect_socket. On Windows, an additional problem exists because of the poll() emulation in php_poll2: php_network_connect_socket polls for PHP_POLLREADABLE|POLLOUT, which by php_poll2 is mapped to the readfds and writefds parameters of select(). In winsock however, connect() errors are returned in exceptfds, not in writefds like they are in POSIX. This means the select() call will only return once its timeout has passed and that php_network_connect_socket will incorrectly return PHP_TIMEOUT_ERROR_VALUE. This behaviour causes undesired delays in many functions that (try to) create network connections. An example of this is the long delay that is observed when connecting to a MySQL-server using mysqlnd and a hostname that has both an IPv6 and an IPv4 address: connecting using the IPv6 address will quickly fail, but because of this bug it will take mysql.connect_timeout seconds before the IPv4 address is tried. -- Edit this bug report at http://bugs.php.net/bug.php?id=52323edit=1
Bug #18953 [Com]: T_INLINE_HTML parser error
Edit report at http://bugs.php.net/bug.php?id=18953edit=1 ID: 18953 Comment by: htekinfo at yahoo dot com Reported by:fclever at verinform dot com Summary:T_INLINE_HTML parser error Status: Closed Type: Bug Package:Scripting Engine problem Operating System: Win32 PHP Version:4.2.2 Block user comment: N New Comment: I had the same problem with php 5, windows, apache2. Some small scripts still worked, but most didn't, and in different directories of the web server. As I could not find anything that had changed, I opened the Apache log files to find an error or external attack. Nothing, but the files were huge, and that was the key: The server log files were simply too big (2-3 years of logs) ! I suppose Apache did send some error bytes that were inserted - spliced - into the php script ? Just rename the big files and with new apache log files, no more T_INLINE_HTML problems. Previous Comments: [2002-09-14 00:23:22] fclever at verinform dot com We have been using PHP 4.2.3 snapshoots, PHP 4.2.3RC1 and PHP 4.2.3 for a while now and the problem does not occur anymore at all. We are running this on production servers, thus it must have gotten fixed one way or another. [2002-08-19 15:38:38] ddreier at mbuti dot org I have run into the same problem, running the same extensions, under Windows NT 4. It is a fairly significant issue for me. [2002-08-19 14:44:31] fclever at verinform dot com The latest 4.3.0-dev snapshot crashes very frequently. The latest STABLE snapshot (4.2.3-dev) performs significantly more stable. [2002-08-17 04:39:26] ed...@php.net Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-08-17 01:22:43] fclever at verinform dot com mistyped email. 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/bug.php?id=18953 -- Edit this bug report at http://bugs.php.net/bug.php?id=18953edit=1
Bug #40880 [Com]: public-protected inheritance causes fatal
Edit report at http://bugs.php.net/bug.php?id=40880edit=1
ID: 40880
Comment by: nickyla83 at yahoo dot fr
Reported by:prometheus__0 at hotmail dot com
Summary:public-protected inheritance causes fatal
Status: Bogus
Type: Bug
Package:Class/Object related
Operating System: SUSE SLES 10
PHP Version:5CVS-2007-03-21 (snap)
Block user comment: N
New Comment:
I'm in the same situation as our friend prometheus here, I am trying
to use a singleton pattern and logically, this should involve being able
to encapsulate the subcalasses information particularly setting up a
private constructor for the singleton subclass, IT DEFINITELY DOES MAKE
SENSE, so please try to take this under consideration for the next php
engine release.
Previous Comments:
[2007-03-21 10:05:25] prometheus__0 at hotmail dot com
is this the 'php'-dev definition?
i'm asking cause wraping a singleton pattern around a subclass makes
sense
and the same example is valid for java and c++
to ask it differently: why is it working this way in php? (i'm
interested in the background of this)
my point is that 2 languages allow it and there is an example which is
valid, not?
[2007-03-21 09:43:47] der...@php.net
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
This is how it works... you can always open up an API through a new
extended interface, but not hide more.
[2007-03-21 09:38:19] prometheus__0 at hotmail dot com
Description:
(1) It is not possible to make inherited functions more private, which
seems like a bug to me but
(2) it is possible to make inherited functions more public, which
shouldn't be possible, afaik.
The example code causes the fatal (1)
if you change
protected function __construct()
to
public function __construct()
from class b
and
public function __construct(){
to
protected function __construct(){
from class a
it works (2)
since i'm not an expert in oop i tried the same example in java and it
works the complete opposite way (the b functions can be more private but
not more public)
and in C++ it's the same
i know bug report http://bugs.php.net/bug.php?id=34237 but it considers
point (2)
point (1) is still a bug in my opinion
Reproduce code:
---
?php
class a{
public function __construct(){
print(public construct\n);
}
}
class b extends a{
protected function __construct(){
print(protected construct\n);
}
public static function getInstance(){
return new b();
}
}
$b = b::getInstance();
?
Expected result:
protected construct
Actual result:
--
Fatal error: Access level to b::__construct() must be public (as in
class a) in PHPDocument2 on line 16
--
Edit this bug report at http://bugs.php.net/bug.php?id=40880edit=1
Bug #52323 [Fbk]: php_network_connect_socket doesn't return all errors correctly
Edit report at http://bugs.php.net/bug.php?id=52323edit=1 ID: 52323 Updated by: cataphr...@php.net Reported by:onno at flox dot org Summary:php_network_connect_socket doesn't return all errors correctly Status: Feedback Type: Bug Package:Sockets related PHP Version:trunk-SVN-2010-07-12 (SVN) Assigned To:pajoye Block user comment: N New Comment: +1 for the first half of the patch. It doesn't make sense that the return value varies according to whether the caller is interested in the error string or not... Previous Comments: [2010-09-07 12:46:14] cataphr...@php.net I think it makes moresense leave php_poll2 untouched. See http://linux.die.net/man/2/poll, which is being emulated and http://msdn.microsoft.com/en-us/library/ms740141(VS.85).aspx which is being used for the implementation. The patch in this bug report fills the exceptfds if POLLERR is given, instead of POLLPRI. However, POLLERR is supposed to be output only as per poll(2)'s specification. This way, * PHP_POLLREADABLE can be given to check if there's data to be read -- although, like the comment in php_poll2 says, it can also mean POLLHUP and POLLERR. Since we can't know this without probing, we default to retuning POLLIN. * POLLOUT can be given to check if data can be sent/will not block. In windows, it can also mean a nonblocking connection was successful. We can't distinguish between the two, so we return POLLOUT. * POLLPRI can be given to check if processing a connect call (nonblocking), connection attempt failed or OOB data is available for reading (only if SO_OOBINLINE is disabled). Again, we can't distinguish between the two, so we return POLLPRI. It has to be caller that disambiguates the return value. In Windows, in case of a nonblocking connect call, we should pass POLLOUT|POLLPRI. When read the return, we know that POLLOUT means the connection was successful and POLLPRI means the connection failed (see patch for bug #50953). [2010-09-07 11:59:45] paj...@php.net hi, This is related to #50953, can you take a look at the patch and see if that matches what you have done here? Or if we need to apply your patch instead, or part of it. [2010-07-12 23:07:25] onno at flox dot org Description: php_network_connect_socket doesn't return all connection errors (like ECONNREFUSED) correctly in all cases. When error_string is NULL, ret isn't set to -1, even when error is set. This can cause problems on all platforms. The ftp extension for example will only detect a socket error once it tries to read the socket, instead of directly after the call to php_network_connect_socket. On Windows, an additional problem exists because of the poll() emulation in php_poll2: php_network_connect_socket polls for PHP_POLLREADABLE|POLLOUT, which by php_poll2 is mapped to the readfds and writefds parameters of select(). In winsock however, connect() errors are returned in exceptfds, not in writefds like they are in POSIX. This means the select() call will only return once its timeout has passed and that php_network_connect_socket will incorrectly return PHP_TIMEOUT_ERROR_VALUE. This behaviour causes undesired delays in many functions that (try to) create network connections. An example of this is the long delay that is observed when connecting to a MySQL-server using mysqlnd and a hostname that has both an IPv6 and an IPv4 address: connecting using the IPv6 address will quickly fail, but because of this bug it will take mysql.connect_timeout seconds before the IPv4 address is tried. -- Edit this bug report at http://bugs.php.net/bug.php?id=52323edit=1
[PHP-BUG] Bug #52794 [NEW]: $a = $b = $c = $d logic with ArrayObject
From:
Operating system:
PHP version: 5.3.3
Package: Arrays related
Bug Type: Bug
Bug description:$a = $b = $c = $d logic with ArrayObject
Description:
If i use expression like
$a = $b = $c = $d;
where $b or $c determined as class extends ArrayObject, then
ArrayObject::offsetGet method do not call.
It may be only if above expression interpreted as
$a = $d;
$b = $d;
$c = $d;
Test script:
---
class foo extends ArrayObject{
function offsetGet($index){return 'Ok';}
}
$o = new foo();
$a = $o[1];
$b = ($o[1] = 'Fail');
echo $a,$b;
//Output: OkFail
//but if
$o[1] = 'Fail';
$b = $o[1];
echo $a,$b;
//Output: OkOk
--
Edit bug report at http://bugs.php.net/bug.php?id=52794edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52794r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52794r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52794r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52794r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52794r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52794r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52794r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52794r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52794r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52794r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52794r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52794r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52794r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52794r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52794r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52794r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52794r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52794r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52794r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52794r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52794r=mysqlcfg
Req #32100 [Com]: Request 'finally' support for exceptions
Edit report at http://bugs.php.net/bug.php?id=32100edit=1
ID: 32100
Comment by: michael202 at gmx dot de
Reported by:ceefour at gauldong dot net
Summary:Request 'finally' support for exceptions
Status: Closed
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: *
PHP Version:5.*
Block user comment: N
New Comment:
I also think that try-finally is useful.
try catch is no elegant replacement.
Just needed it today again.
finally is more elegant than an other solution.
For example:
try {
lots o' code
if a return
..
if b exit
..
} finally
do somethin
}
Another solution to the finally problem is to use goto.
Not so elegant but not a bad thing according to Knuth.
Previous Comments:
[2010-08-16 12:42:11] torsten dot landmann at bauermedia dot com
I also agree: 'finally' is needed. I really don't get why it has been
left out.
There is no elegant equivalent, especially so since rethrowing the
exception alters file and line number saved in the exception, so later
it's hard to find out where it originally came from.
Please offer finally. Don't worry, nobody will be forced to use it.
I definitely will.
thuejk showed very well how 'finally' helps with keeping your code
clean. Or vice versa: How the absence of it often causes the need to
copy and paste code (which is always a bad development pattern).
[2010-06-27 00:59:16] thuejk at gmail dot com
We've had long discussions and came to the only conclusion that we
don't need
that, for more search the mailing list archieves.
Where is that discussion? I haven't been able to find it. Only people
saying
that finally is utterly useless, without showing any signs that they
have
actually considered finally's uses.
As the other comments have said, sometimes some code inside a try will
allocate
a non-php ressource which need to be deallocated whether or not an
exception is
thrown. To avoid writing that code twice, you need it in finally.
Version without finally:
try {
allocate non-php resource
} catch ($ex) {
deallocate non-php resource
throw $ex;
}
deallocate non-php resource
Version with finally:
try {
allocate non-php resource
} finally {
deallocate non-php resource
}
The finally code is obviously better. And it is a completely
reasonable way to
code.
Sure you can emulate finally with more code, but so can a Turin Machine.
finally
is syntactic sugar which makes it easier to write maintainable programs.
[2010-06-16 20:54:10] orlandu96 at gmail dot com
are there any updates on this issue?
[2010-03-31 12:40:17] a dot e at inne dot pl
Could finally also mean that 'returns' will be executed after the
finally block
try{
some ifs
...
return x
...
more ifs
...
throw
...
return y
}catch{
handle exceptions
}finally{
No matter if there was exception or not
execute this bit before you leave the method.
For example if object has some state it might be necessary to
make sure its consistent at the end
}
In the case i have now at work i had to add method call before every
return and throw to make sure that my data will be set properly before
method ends.
Would that be a feature someone might like?
thanks
art
[2005-02-25 20:27:50] ceefour at gauldong dot net
I don't think the code is absolutely equivalent. And omitting the
rethrow statement gives up the whole notion of 'finally'.
Actually my code was trying to *emulate* finally. But it's not the right
thing to do. Finally should not even touch the Exception at all...
Finally doesn't even know there is an exception.
I have to agree that 'finally' is not _required_ by PHP, but not by
'we'. 'We' in this sense refers to 'all PHP developers' and that
includes me, and I _need_ (although not _require_) this functionality.
Almost the same as namespaces don't have to be in PHP but some people
feel the need for it. However namespaces are much harder to implement
yet I think finally is relatively straightforward since we can already
emulate it using try/catch, but with the quirks.
I don't think finally is a control flow block. By emulating finally
using try/catch, yes maybe, but we have no other choice. Finally is not
a control flow because why..? Finally has no idea whether it is inside
an Exception or not, and cannot handle it i.e. it's not able to
_control_ processing based on the state of Exception. In this sense
finally is unconditional, just like ordinary
Bug #39448 [Com]: Maximum execution time exceeded even if is unlimited
Edit report at http://bugs.php.net/bug.php?id=39448edit=1 ID: 39448 Comment by: jwagner at computing dot dcu dot ie Reported by:jschwabik at koop dot cz Summary:Maximum execution time exceeded even if is unlimited Status: No Feedback Type: Bug Package:Performance problem Operating System: CentOS release 4.3 PHP Version:5.2.0 Block user comment: N New Comment: Regarding the unpredictable moment when execution stops, please note that max_execution_time only applies to time spent by crunching php code, i.e. the 30 seconds stop counting down when you run a shell command, query your mysql database etc. Therefore, the 30 seconds may be over after 10 minutes or 5 hours. It all depends on what your php code is doing. Theoretically, if php automatically parallelised code on multiple cores, the 30 seconds could also be over even quicker than 30 seconds real time. Regarding the set_time_limit(0), you need to be in soft mode in order to be able to raise your limits. JJ Previous Comments: [2007-03-12 19:26:15] quentinjs at gmail dot dom I'm using IIS, MySQL, and PHP 5.1.1. This problem starting happening randomly within the code, and there doesn't seem to be a reason for it other then it seems to be related to MySQL calls... but I haven't taken the time yet to test that theory. Its also is random which makes it VERY hard to create a reproducable version. I'll be upgrading PHP and MySQL tonight and will then spend some time building a test case to reproduce this problem as its becoming more frequent as of late. [2006-11-17 01:00:01] 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. [2006-11-10 19:29:35] christoph at ziegenberg dot de Perhaps this has to do with the problem in Bug #39361, where ini settings which are valid for a directory only are still active when leaving the directory (although ini_get() returns the correct value). I tested some settings and they worked, so I though this problem is a mbstring problem - but it possibly occurs also with other ini settings... [2006-11-09 17:10:02] tony2...@php.net Not reproducible. [2006-11-09 12:39:24] jschwabik at koop dot cz Description: I've got script running from linux shell and sometimes it crashes with Maximum execution time of 30 seconds exceeded in some line error in the script. The command on which it crashes is unpredictable. The script is runnig sometimes 10 minutes, sometimes 30 minutes and crashes on different lines. (It never runs 30 seconds). I am running it from command line (CLI) (max_execution_time should be 0) an I set it with set_time_limit(0) to 0. I've tried two servers 4 php versions (4.4.2, 4.4.4,5.1.6,5.2.0) In my php.ini is max_execution_time set to 0. Sometimes it ends on ifx_fetch_row(). Sometimes it ends on mktime(). My configure './configure' '--with-config-file-path=/etc/php.ini' '--with-apache=../apache_1.3.37/' '--with-informix=/opt/informix' '--with-mysql=/usr/local/mysql/' '--enable-ftp' '--with-gd' '--enable-gd-native-ttf' '--enable-gd-imgstrttf' '--with-zlib' '--with-jpeg-dir=/usr/' '--with-freetype-dir=/usr' '--with-dom=./ext' '--with-ldap' '--with-mssql=/usr/local/' '--enable-dbase' '--with-iconv=/usr/local' PHP Core Info . . . max_execution_time = 0 = 30 max_input_time = -1 = 60 open_basedir = no value = no value output_buffering = 0 = no value output_handler = no value = no value post_max_size = 8M = 8M precision = 12 = 12 safe_mode = Off = Off . . . Reproduce code: --- ? set_time_limit(0); //connection to MYsql database //connection to Informix database //running Informix query (10 queries) //doing some transformations and inserting into MYsql database (multiple insert every 100 rows) echo End; ? Expected result: End is echoed or some meaningful error message. Actual result: -- Fatal error:Maximum execution time of 30 seconds exceeded in ... -- Edit this bug report at http://bugs.php.net/bug.php?id=39448edit=1
[PHP-BUG] Req #52795 [NEW]: OCI.dll not found
From: Operating system: MS Windows 7 PHP version: 5.3.3 Package: Unknown/Other Function Bug Type: Feature/Change Request Bug description:OCI.dll not found Description: Hi! I have problem with PHP, that the file php-cgi.exe when the server demands it, it would report Missing OCI.dll problem, I had used Apache 2.2.16 and MS IIS 7.5, and the two of them can't access php-cgi.exe properly,IIS 7.5 shows this problem: Error Summary HTTP Error 500.0 - Internal Server Error C:\Program Files\PHP\php-cgi.exe - The FastCGI process exited unexpectedly Detailed Error Information Module FastCgiModule Notification ExecuteRequestHandler HandlerPHP_via_FastCGI Error Code 0x00ff Requested URL http://localhost:150/vb/install/install.php Physical Path C:\inetpub\wwwroot\vb\install\install.php Logon Method Anonymous Logon User Anonymous note: I am running HTTP on port 150. And when I open php-cgi.exe by double click, it shows the Missing OCI.dll message. Then, I looked for OCI.dll, and got one, you can download it from: http://iwih.co.cc/PHP-bug/oci.dll I've placed it in the PHP directory where I've installed it, the message turned to Wrong OCI.dll, please reinstall the product message. A similar bug discussed in this link: http://bugs.php.net/bug.php?id=52307 Mentioned in it Don't enable Oracle extensions, then how can I disable the Oracle extensions?? Thank you in advance. -- Edit bug report at http://bugs.php.net/bug.php?id=52795edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52795r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52795r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52795r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52795r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52795r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52795r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52795r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52795r=needscript Try newer version: http://bugs.php.net/fix.php?id=52795r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52795r=support Expected behavior: http://bugs.php.net/fix.php?id=52795r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52795r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52795r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52795r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52795r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52795r=dst IIS Stability: http://bugs.php.net/fix.php?id=52795r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52795r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52795r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52795r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52795r=mysqlcfg
Bug #52794 [Opn-Bgs]: $a = $b = $c = $d logic with ArrayObject
Edit report at http://bugs.php.net/bug.php?id=52794edit=1
ID: 52794
Updated by: cataphr...@php.net
Reported by:seroshkin at gmail dot com
Summary:$a = $b = $c = $d logic with ArrayObject
-Status: Open
+Status: Bogus
Type: Bug
Package:Arrays related
PHP Version:5.3.3
Block user comment: N
New Comment:
This is not a bug.
You did not override offsetSet. The assignment returns the assigned
value, hence $b will be 'Fail' in the first example.
However, in the second, despite $o[1] = 'Fail';, $o[1] will return 'Ok'
due to your definition of offsetGet and $b will be 'Ok'.
Previous Comments:
[2010-09-07 16:53:29] seroshkin at gmail dot com
Description:
If i use expression like
$a = $b = $c = $d;
where $b or $c determined as class extends ArrayObject, then
ArrayObject::offsetGet method do not call.
It may be only if above expression interpreted as
$a = $d;
$b = $d;
$c = $d;
Test script:
---
class foo extends ArrayObject{
function offsetGet($index){return 'Ok';}
}
$o = new foo();
$a = $o[1];
$b = ($o[1] = 'Fail');
echo $a,$b;
//Output: OkFail
//but if
$o[1] = 'Fail';
$b = $o[1];
echo $a,$b;
//Output: OkOk
--
Edit this bug report at http://bugs.php.net/bug.php?id=52794edit=1
Bug #52710 [Fbk-Csd]: Session Disappears
Edit report at http://bugs.php.net/bug.php?id=52710edit=1 ID: 52710 User updated by:diemuzi at gmail dot com Reported by:diemuzi at gmail dot com Summary:Session Disappears -Status: Feedback +Status: Closed Type: Bug Package:FPM related Operating System: Archlinux PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: Closing, not related with FPM. This was bad timing the issue presented itself once FPM was compiled and used. Previous Comments: [2010-08-26 22:38:44] f...@php.net HUm well I'm using a quite similar configuration and it works without any problems. Can you strace the child process when the problem occurs and report the returned result please ? strace -p PID -s 1024 -o /tmp/strace.fpm.log [2010-08-26 22:31:28] diemuzi at gmail dot com # # php-fpm.conf # ; FPM Configuration ; ; ; All relative paths in this configuration file are relative to PHP's install ; prefix. ; Include one or more files. If glob(3) exists, it is used to include a bunch of ; files from a glob(3) pattern. This directive can be used everywhere in the ; file. include=/usr/local/etc/fpm.d/*.conf ;; ; Global Options ; ;; [global] ; Pid file ; Default Value: none pid = /var/run/php-fpm.pid ; Error log file ; Default Value: /usr/local/var/log/php-fpm.log error_log = /var/log/php-fpm.log ; Log level ; Possible Values: alert, error, warning, notice, debug ; Default Value: notice log_level = notice ; If this number of child processes exit with SIGSEGV or SIGBUS within the time ; interval set by emergency_restart_interval then FPM will restart. A value ; of '0' means 'Off'. ; Default Value: 0 ;emergency_restart_threshold = 1 ; Interval of time used by emergency_restart_interval to determine when ; a graceful restart will be initiated. This can be useful to work around ; accidental corruptions in an accelerator's shared memory. ; Available Units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 ;emergency_restart_interval = 1 ; Time limit for child processes to wait for a reaction on signals from master. ; Available units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 ;process_control_timeout = 1 ; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging. ; Default Value: yes daemonize = no # # admin.conf (included by php-fpm.conf) # [admin] listen = /tmp/fcgi_ipc/php-fpm.sock listen.backlog = -1 listen.owner = apache listen.group = apache listen.mode = 0777 user = admin group = admin pm = dynamic pm.max_children = 1 pm.start_servers = 1 pm.min_spare_servers = 1 pm.max_spare_servers = 1 pm.max_requests = 500 catch_workers_output = no # # Notes # I attempted to change the values of the servers thinking perhaps it had something to do with that but no luck. As for php.ini they are default values which comes packaged with PHP 5.3.3 just for sanity tests. As an additional test a moment ago I switched back to FastCGI/CGI mode without FPM support and as expected I did not encounter this situation. If this is a configuration issue, I appologize for the bug report. [2010-08-26 22:23:59] f...@php.net Can you please provide you complete php-fpm.conf ? [2010-08-26 22:11:52] diemuzi at gmail dot com Description: It appears when running PHP 5.3.3 with FPM support sessions disappear on almost every-other request. The session name stays the same, but any application using a session returns a blank page until the page has been refreshed again. Currently I have the session.save_path to /tmp, I tested other locations but the same issue. (This did not occur with FastCGI/CGI). As another test I changed the location of the save_path and loaded a phpinfo() script. It showed the corrected changed location, however upon refresh it was changed back to /tmp. Another refresh and the location was again changed to the path I specified. When the path changes, it does not write a new session file in either location. The error in the error log is always: FastCGI: server stdeer: PHP Fatal error session_start(); open(/tmp/session_name_here, O_RDWR) failed: Permission denied(13) Array Testing with random permissions ranging from 0644, 0666, 0755, 0777 return the same results. I also attempted to change the permissions to the actual session file and the same results. -- Edit this bug report
Bug #50830 [Com]: FILTER_VALIDATE_IP incorrectly validates a compressed IPv4-mapped IPv6 address
Edit report at http://bugs.php.net/bug.php?id=50830edit=1
ID: 50830
Comment by: sob at academ dot com
Reported by:mikerushton at hotmail dot co dot uk
Summary:FILTER_VALIDATE_IP incorrectly validates a
compressed IPv4-mapped IPv6 address
Status: Open
Type: Bug
Package:Filter related
Operating System: *
PHP Version:5.*, 6
Block user comment: N
New Comment:
Please note that RFC 4291 has been updated by RFC 5952.
Previous Comments:
[2010-08-17 18:47:30] michael at squiloople dot com
It has come to my attention that the regular expression I provided above
uses
RFC 5321 as the authority on IPv6 address format. This differs from RFC
4291
however, which is the ACTUAL authority on IPv6 address format. The key
difference between the two is that 4291 allows a double colon to
represent just
ONE 16-bit group of zeros whereas 5321 requires that it represent at
least TWO
groups. As such, I have provided a modified regular expression which
conforms
with 4291 in this respect (and have also removed the unnecessary
capturing
groups present in my earlier regex)
(?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){7})|(?:(?!(?:.*[a-f0-
9](?::|$)){8,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,6})?::(?:[a-f0-
9]{1,4}(?::[a-f0-9]{1,4}){0,6})?)))|(?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){5}:)|(?:(?!(?:.*[a-f0-9]:){6,})(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){0,4})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,4}:)?)))?(?:25[0-5]|2[0-
4][0-9]|1[0-9]{2}|[1-9]?[0-9])(?:\.(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-
9])){3}))
[2010-02-01 15:34:13] mikerushton at hotmail dot co dot uk
An addition: here's my solution (as a regular expression):
(?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){7})|(?:(?!(?:.*[a-f0-9](?
::|$)){7,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,5})?::(?:[a-f0-9]{1,4}(?
::[a-f0-9]{1,4}){0,5})?)))|(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){5}:)|(?:(?!(?:.*[a-f0-9]:){5,})(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){0,3})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,3}:)?))?(?:(?
:25[0-5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9]))(?:\.(?:(?:25[0-
5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9]))){3}))
[2010-01-24 15:45:29] mikerushton at hotmail dot co dot uk
Description:
FILTER_VALIDATE_IP validates the incorrect 0:::255.255.255.255 and does
not validate the correct 0::255.255.255.255
According to RFC 5321, the correct syntax is:
[IPv6-hex *3(: IPv6-hex)] :: [IPv6-hex *3(: IPv6-hex) :] IPv4-
address-literal
This does not allow for three consecutive colons.
Reproduce code:
---
// First
filter_var(':::255.255.255.255', FILTER_VALIDATE_IP);
// Second
filter_var('::255.255.255.255', FILTER_VALIDATE_IP);
Expected result:
// First
bool(false)
// Second
string(21) '::255.255.255.255'
Actual result:
--
// First
string(22) ':::255.255.255.255'
// Second
bool(false)
--
Edit this bug report at http://bugs.php.net/bug.php?id=50830edit=1
Bug #52637 [Opn]: bug in prepare statement
Edit report at http://bugs.php.net/bug.php?id=52637edit=1
ID: 52637
User updated by:angelo dot courtel at laposte dot net
Reported by:angelo dot courtel at laposte dot net
Summary:bug in prepare statement
Status: Open
Type: Bug
Package:PDO related
Operating System: Debian Lenny
PHP Version:5.2.6-1+lenny6
Block user comment: N
New Comment:
Well, but I want find a way to use a prepared statement, without need to
predeclare all paramètres on a sql comment ! It s not a very optimized
solution.
Previous Comments:
[2010-09-06 15:13:59] u...@php.net
Well, if you comment out your SQL statement, it should work fine
regardless what it may look like... -- starts a single line SQL
comment.
[2010-08-19 10:06:12] angelo dot courtel at laposte dot net
A little example for explain my bug :
This source works correctly on an Windows WAMP PHP5.2.6
But not on Debian :(
?php
//running on PHP Version 5.2.6-1+lenny6
try {
$dbh = new
PDO('pgsql:host=localhost;port=5432;dbname=db;user=user;password=pass');
} catch (PDOException $e) {
echo 'Connexion failed : ' . $e-getMessage();exit;
}
//list or parameters
$id = 40;
$id2 = 40;
$param = array (':id' = $id, ':id2' = $id2);
//query failed
$sReq = '
select * from t1
left join t2 on t2.id = :id
left join t3 on t3.id = :id
where t1.id = :id2';
$rTest1 = $dbh-prepare($sReq);
if ($rTest1-execute($param))
echo 'OK';
else
var_dump($rTest1-errorInfo());
// -- array(3) { [0]= string(5) 42P18 [1]= int(7) [2]=
string(69) ERREUR: n'a pas pu déterminer le type de données du
paramètres $2 }
$rTest2 = $dbh-prepare($sReq);
$rTest2-bindParam(':id', $id);
$rTest2-bindParam(':id2', $id2);
if ($rTest2-execute())
echo 'OK';
else
var_dump($rTest2-errorInfo());
// -- array(3) { [0]= string(5) 42P18 [1]= int(7) [2]=
string(69) ERREUR: n'a pas pu déterminer le type de données du
paramètres $2 }
//query success
$sReq = '
-- :id :id2
select * from t1
left join t2 on t2.id = :id
left join t3 on t3.id = :id
where t1.id = :id2';
$rTest3 = $dbh-prepare($sReq);
if ($rTest3-execute($param))
echo 'OK';
else
var_dump($rTest3-errorInfo());
// -- OK
$rTest4 = $dbh-prepare($sReq);
$rTest4-bindParam(':id', $id);
$rTest4-bindParam(':id2', $id2);
if ($rTest4-execute())
echo 'OK';
else
var_dump($rTest4-errorInfo());
// -- OK
?
[2010-08-19 06:55:59] angelo dot courtel at laposte dot net
Hi, I use PostGreSql Pdo driver
Thks
[2010-08-19 01:17:32] fel...@php.net
What PDO driver are you using?
[2010-08-18 18:18:03] angelo dot courtel at laposte dot net
Description:
Hi
when I execute a prepared query which use twice, or more, a same
parameters, it
returns an error : in french : ERREUR: n'a pas pu déterminer le type
de données
du paramètres $3
ie. : this query don't works
$sReq = 'select *
from categorie
left join budget on bud_cat = cat_cod and bud_moi = :month and bud_ann
=
:year
left join operation on ope_cat = cat_cod and ope_moi = :month and
ope_ann = :year
where cat_cod = :categorie';
$rCategorie = $oAppli-getDb()-prepare($sReq);
$rCategorie-bindParam(':month', date('m'));
$rCategorie-bindParam(':categorie', $sCategorie);
$rCategorie-bindParam(':year', date('Y'));
if ($rCategorie-execute())
but if I add -- :year :categorie :month at the beginning of the
query, it
works !!!
I thinks PDO don't like seeing a repeated parameter before seens all the
parameters (the :month appears twice before :categorie, almost with the
comment
at the beginning, PDO see all parameters at start)
Sorry for my english I'm french guy.
Thks
Test script:
---
//don't work
$sReq = 'select *
from categorie
left join budget on bud_cat = cat_cod and bud_moi = :month and bud_ann
= :year
left join operation on ope_cat = cat_cod and ope_moi = :month and
ope_ann = :year
where cat_cod = :categorie';
$rCategorie = $oAppli-getDb()-prepare($sReq);
$rCategorie-bindParam(':month', date('m'));
$rCategorie-bindParam(':categorie', $sCategorie);
$rCategorie-bindParam(':year', date('Y'));
if ($rCategorie-execute())
//works fine
$sReq = '-- :year :categorie :month
select *
from categorie
left join budget on bud_cat = cat_cod and bud_moi = :month and bud_ann
= :year
left join operation on
Bug #52498 [Asn-Csd]: when FPM is enable, php-cli is linked against libevent (it shouldn't)
Edit report at http://bugs.php.net/bug.php?id=52498edit=1 ID: 52498 Updated by: f...@php.net Reported by:f...@php.net Summary:when FPM is enable, php-cli is linked against libevent (it shouldn't) -Status: Assigned +Status: Closed Type: Bug Package:FPM related Operating System: linux PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: 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. Previous Comments: [2010-09-07 23:12:30] f...@php.net Automatic comment from SVN on behalf of fat Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=303147 Log: - Fixed bug #52498 (libevent was not only linked to php-fpm) [2010-07-30 13:33:53] f...@php.net Description: r...@wild # ldd sapi/fpm/php-fpm ... libevent-1.4.so.2 = /usr/local/libevent-1.4.13/lib/libevent-1.4.so.2 (0xb7d98000) ... r...@wild # ldd sapi/cli/php ... libevent-1.4.so.2 = /usr/local/libevent-1.4.13/lib/libevent-1.4.so.2 (0xb803) ... libevent is linked by sapi/cli/php when it shouldn't Test script: --- compile PHP with --enable-fpm Expected result: r...@wild # ldd sapi/fpm/php-fpm ... libevent-1.4.so.2 = /usr/local/libevent-1.4.13/lib/libevent-1.4.so.2 (0xb7d98000) ... r...@wild # ldd sapi/cli/php ... ... Actual result: -- r...@wild # ldd sapi/fpm/php-fpm ... libevent-1.4.so.2 = /usr/local/libevent-1.4.13/lib/libevent-1.4.so.2 (0xb7d98000) ... r...@wild # ldd sapi/cli/php ... libevent-1.4.so.2 = /usr/local/libevent-1.4.13/lib/libevent-1.4.so.2 (0xb803) ... -- Edit this bug report at http://bugs.php.net/bug.php?id=52498edit=1
Bug #52789 [Com]: microtime() loses time in long-running scripts (please reopen)
Edit report at http://bugs.php.net/bug.php?id=52789edit=1 ID: 52789 Comment by: cataphr...@php.net Reported by:jdolecek at NetBSD dot org Summary:microtime() loses time in long-running scripts (please reopen) Status: Open Type: Bug Package:Date/time related Operating System: Windows XP PHP Version:5.3.3 Block user comment: N New Comment: I ran the script for two hours and a half and couldn't reproduce it. Is this XP only? Previous Comments: [2010-09-07 09:40:11] jdolecek at NetBSD dot org Description: This is just a reminder for Bug #42659 since I cannot reopen that one. The problem with time difference between time() and microtime() on Windows XP is still there. Please reopen Bug #42659 -- Edit this bug report at http://bugs.php.net/bug.php?id=52789edit=1
Bug #50830 [Com]: FILTER_VALIDATE_IP incorrectly validates a compressed IPv4-mapped IPv6 address
Edit report at http://bugs.php.net/bug.php?id=50830edit=1
ID: 50830
Comment by: michael at squiloople dot com
Reported by:mikerushton at hotmail dot co dot uk
Summary:FILTER_VALIDATE_IP incorrectly validates a
compressed IPv4-mapped IPv6 address
Status: Open
Type: Bug
Package:Filter related
Operating System: *
PHP Version:5.*, 6
Block user comment: N
New Comment:
RFC 5952 is only a Proposed Standard. RFC 4291 is still the authority.
And even
if/when RFC 5952 is accepted, it is only a recommendation for (good
practice)
representation and clearly states that all implementations must accept
and be
able to handle any legitimate RFC 4291 format.
Previous Comments:
[2010-09-07 21:42:21] sob at academ dot com
Please note that RFC 4291 has been updated by RFC 5952.
[2010-08-17 18:47:30] michael at squiloople dot com
It has come to my attention that the regular expression I provided above
uses
RFC 5321 as the authority on IPv6 address format. This differs from RFC
4291
however, which is the ACTUAL authority on IPv6 address format. The key
difference between the two is that 4291 allows a double colon to
represent just
ONE 16-bit group of zeros whereas 5321 requires that it represent at
least TWO
groups. As such, I have provided a modified regular expression which
conforms
with 4291 in this respect (and have also removed the unnecessary
capturing
groups present in my earlier regex)
(?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){7})|(?:(?!(?:.*[a-f0-
9](?::|$)){8,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,6})?::(?:[a-f0-
9]{1,4}(?::[a-f0-9]{1,4}){0,6})?)))|(?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){5}:)|(?:(?!(?:.*[a-f0-9]:){6,})(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){0,4})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,4}:)?)))?(?:25[0-5]|2[0-
4][0-9]|1[0-9]{2}|[1-9]?[0-9])(?:\.(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-
9])){3}))
[2010-02-01 15:34:13] mikerushton at hotmail dot co dot uk
An addition: here's my solution (as a regular expression):
(?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){7})|(?:(?!(?:.*[a-f0-9](?
::|$)){7,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,5})?::(?:[a-f0-9]{1,4}(?
::[a-f0-9]{1,4}){0,5})?)))|(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){5}:)|(?:(?!(?:.*[a-f0-9]:){5,})(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){0,3})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,3}:)?))?(?:(?
:25[0-5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9]))(?:\.(?:(?:25[0-
5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9]))){3}))
[2010-01-24 15:45:29] mikerushton at hotmail dot co dot uk
Description:
FILTER_VALIDATE_IP validates the incorrect 0:::255.255.255.255 and does
not validate the correct 0::255.255.255.255
According to RFC 5321, the correct syntax is:
[IPv6-hex *3(: IPv6-hex)] :: [IPv6-hex *3(: IPv6-hex) :] IPv4-
address-literal
This does not allow for three consecutive colons.
Reproduce code:
---
// First
filter_var(':::255.255.255.255', FILTER_VALIDATE_IP);
// Second
filter_var('::255.255.255.255', FILTER_VALIDATE_IP);
Expected result:
// First
bool(false)
// Second
string(21) '::255.255.255.255'
Actual result:
--
// First
string(22) ':::255.255.255.255'
// Second
bool(false)
--
Edit this bug report at http://bugs.php.net/bug.php?id=50830edit=1
Bug #52789 [Opn-Fbk]: microtime() loses time in long-running scripts (please reopen)
Edit report at http://bugs.php.net/bug.php?id=52789edit=1 ID: 52789 Updated by: paj...@php.net Reported by:jdolecek at NetBSD dot org Summary:microtime() loses time in long-running scripts (please reopen) -Status: Open +Status: Feedback Type: Bug Package:Date/time related Operating System: Windows XP PHP Version:5.3.3 Block user comment: N New Comment: Please try using VC9 builds. Previous Comments: [2010-09-08 00:31:57] cataphr...@php.net I ran the script for two hours and a half and couldn't reproduce it. Is this XP only? [2010-09-07 09:40:11] jdolecek at NetBSD dot org Description: This is just a reminder for Bug #42659 since I cannot reopen that one. The problem with time difference between time() and microtime() on Windows XP is still there. Please reopen Bug #42659 -- Edit this bug report at http://bugs.php.net/bug.php?id=52789edit=1
