Bug #53585 [Com]: PNG support broken, Abort trap: 6 (core dumped)
Edit report at http://bugs.php.net/bug.php?id=53585&edit=1
ID: 53585
Comment by: eugene at krivoruchko dot info
Reported by:serge dot sitnikov at gmail dot com
Summary:PNG support broken, Abort trap: 6 (core dumped)
Status: Open
Type: Bug
Package:GD related
Operating System: FreeBSD 8.1-RELEASE
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
In FreeBSD 8.0
After update all port:
#portmanager -u
This problem resolved...
Previous Comments:
[2010-12-21 08:18:20] serge dot sitnikov at gmail dot com
Description:
PNG support broken, completely. If PHP runs under Apache that will lead
to
workers exhaustion.
PHP 5.3.4 on FreeBSD 8.1-RELEASE amd64
array (
'GD Version' => 'bundled (2.0.34 compatible)',
'FreeType Support' => true,
'FreeType Linkage' => 'with freetype',
'T1Lib Support' => true,
'GIF Read Support' => true,
'GIF Create Support' => true,
'JPEG Support' => true,
'PNG Support' => true,
'WBMP Support' => true,
'XPM Support' => true,
'XBM Support' => true,
'JIS-mapped Japanese Font Support' => false,
)
png-1.4.4 Library for manipulating PNG images
Test script:
---
$image = imagecreatefrompng('/path/to/my/png/file');
Expected result:
Image opened.
Actual result:
--
Abort trap: 6 (core dumped)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53585&edit=1
[PHP-BUG] Bug #53585 [NEW]: PNG support broken, Abort trap: 6 (core dumped)
From:
Operating system: FreeBSD 8.1-RELEASE
PHP version: 5.3.4
Package: GD related
Bug Type: Bug
Bug description:PNG support broken, Abort trap: 6 (core dumped)
Description:
PNG support broken, completely. If PHP runs under Apache that will lead to
workers exhaustion.
PHP 5.3.4 on FreeBSD 8.1-RELEASE amd64
array (
'GD Version' => 'bundled (2.0.34 compatible)',
'FreeType Support' => true,
'FreeType Linkage' => 'with freetype',
'T1Lib Support' => true,
'GIF Read Support' => true,
'GIF Create Support' => true,
'JPEG Support' => true,
'PNG Support' => true,
'WBMP Support' => true,
'XPM Support' => true,
'XBM Support' => true,
'JIS-mapped Japanese Font Support' => false,
)
png-1.4.4 Library for manipulating PNG images
Test script:
---
$image = imagecreatefrompng('/path/to/my/png/file');
Expected result:
Image opened.
Actual result:
--
Abort trap: 6 (core dumped)
--
Edit bug report at http://bugs.php.net/bug.php?id=53585&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53585&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53585&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53585&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53585&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53585&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53585&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53585&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53585&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53585&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53585&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53585&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53585&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53585&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53585&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53585&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53585&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53585&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53585&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53585&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53585&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53585&r=mysqlcfg
Req #49175 [Com]: mod_files.sh patch
Edit report at http://bugs.php.net/bug.php?id=49175&edit=1 ID: 49175 Comment by: mastermind dot ua at gmail dot com Reported by:oorza2k5 at gmail dot com Summary:mod_files.sh patch Status: Open Type: Feature/Change Request Package:Session related Operating System: *nix PHP Version:5.3.0 Block user comment: N Private report: N New Comment: The last parameter to mod_files.sh is not a MAJOR_PHP_VERSION but a number of bits used for hashing: session.hash_bits_per_character integer session.hash_bits_per_character allows you to define how many bits are stored in each character when converting the binary hash data to something readable. The possible values are '4' (0-9, a-f), '5' (0-9, a-v), and '6' (0-9, a-z, A-Z, "-", ","). http://www.php.net/manual/en/session.configuration.php#ini.session.hash-bits-per-character Previous Comments: [2009-08-06 02:51:23] oorza2k5 at gmail dot com Description: here's a script, mod_files.sh, in ext/session for creating directory tree with depth X for sessions. As it stands, it's pretty poorly documented and very basic. I got exceptionally bored and rewrote most of it, the patch is attached. It runs fine for me in linux (with sh version 4.0). I don't have any other *NIX systems to test it out on, so I can't verify that it works in anything but linux, sorry. What I changed: 1. Usage now properly reflects arguments, and is better explained. 2. Will create directory given if it doesn't exist 3. Will hop into interactive select if directory already has contents 4. Switched from "test" to "[[ ]]" as it's easier to read and _should_ be just as supported. Reproduce code: --- Patch is available at http://pastebin.ca/1520039 Expected result: (Old behavior) $ sh mod_files.sh usage: mod_files.sh basedir depth $ sh mod_files.sh /foo 3 mod_files.sh: line 13: test: : integer expression expected mkdir: cannot create directory `/foo/0': No such file or directory Actual result: -- (New behavior) $ sh mod_files.sh Usage: mod_files.sh BASE_DIRECTORY DEPTH MAJOR_PHP_VERSION BASE_DIRECTORY will be created if it doesn't exist DEPTH must be an integer number >0 MAJOR_PHP_VERSION should be one of 4, 5, or 6 $sh mod_files.sh /foo 3 5 Directory /foo is not empty! What would you like to do? 1) Delete directory contents 3) Quit 2) Choose another directory #? 1 Deleting /foo contents... Creating session path in /foo with a depth of 3 for PHP Version 5.X -- Edit this bug report at http://bugs.php.net/bug.php?id=49175&edit=1
Bug #53584 [Com]: Asterisk character equals 0
Edit report at http://bugs.php.net/bug.php?id=53584&edit=1
ID: 53584
Comment by: andy dot mezey at gmail dot com
Reported by:andy dot mezey at gmail dot com
Summary:Asterisk character equals 0
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
Yes, I see it now.
(http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion).
I'm very sorry to have wasted each of your time.
Previous Comments:
[2010-12-20 22:36:09] ras...@php.net
"*" == 0
and
"*" == "0"
are very different cases.
In the first you are comparing a string to an integer, so the string
will be
cast to an integer and the integer value of "*" is 0 so that will be
equal.
In the second you are comparing strings, so "*" and "0" will not be
equal.
[2010-12-20 22:30:26] andy dot mezey at gmail dot com
Are you saying when running the examples provided nothing was printed to
the screen; that the statements returned false? I just tried my
examples on another server running PHP Version 5.2.13 and received the
same results as before. When I execute the code var_dump( "*" == 0 );,
bool(true) is returned.
[2010-12-20 22:20:42] cataphr...@php.net
Everything in your test script is expected behavior. "*" == "0" being
true is not, but that claim isn't tested in the test script and I can't
reproduce, which leads me to conclude it was a mistake on the your
part.
php -r 'var_dump("*" == "0");'
bool(false)
[2010-12-20 21:45:11] andy dot mezey at gmail dot com
Description:
Using PHP Version 5.3.2-1ubuntu4.5. When a variable holds the value "*"
and when being compared against the values 0 or "0" using the equal
operator, true is always returned. I did look here:
http://php.net/manual/en/language.types.type-juggling.php and I do not
see a reason for this behavior. The Identical operator does however
return false which is what you would expect.
Test script:
---
$var1 = "*";
if( $var1 == 0 )
{
echo "ok";
}
switch( $var1 )
{
case 0 :
echo "ok";
break;
}
$var2 = "\*";
if( $var2 == 0 )
{
echo "ok";
}
switch( $var2 )
{
case 0 :
echo "ok";
break;
}
Expected result:
Should return false.
Actual result:
--
Returns true;
--
Edit this bug report at http://bugs.php.net/bug.php?id=53584&edit=1
Bug #53584 [Bgs]: Asterisk character equals 0
Edit report at http://bugs.php.net/bug.php?id=53584&edit=1
ID: 53584
Updated by: ras...@php.net
Reported by:andy dot mezey at gmail dot com
Summary:Asterisk character equals 0
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
"*" == 0
and
"*" == "0"
are very different cases.
In the first you are comparing a string to an integer, so the string
will be
cast to an integer and the integer value of "*" is 0 so that will be
equal.
In the second you are comparing strings, so "*" and "0" will not be
equal.
Previous Comments:
[2010-12-20 22:30:26] andy dot mezey at gmail dot com
Are you saying when running the examples provided nothing was printed to
the screen; that the statements returned false? I just tried my
examples on another server running PHP Version 5.2.13 and received the
same results as before. When I execute the code var_dump( "*" == 0 );,
bool(true) is returned.
[2010-12-20 22:20:42] cataphr...@php.net
Everything in your test script is expected behavior. "*" == "0" being
true is not, but that claim isn't tested in the test script and I can't
reproduce, which leads me to conclude it was a mistake on the your
part.
php -r 'var_dump("*" == "0");'
bool(false)
[2010-12-20 21:45:11] andy dot mezey at gmail dot com
Description:
Using PHP Version 5.3.2-1ubuntu4.5. When a variable holds the value "*"
and when being compared against the values 0 or "0" using the equal
operator, true is always returned. I did look here:
http://php.net/manual/en/language.types.type-juggling.php and I do not
see a reason for this behavior. The Identical operator does however
return false which is what you would expect.
Test script:
---
$var1 = "*";
if( $var1 == 0 )
{
echo "ok";
}
switch( $var1 )
{
case 0 :
echo "ok";
break;
}
$var2 = "\*";
if( $var2 == 0 )
{
echo "ok";
}
switch( $var2 )
{
case 0 :
echo "ok";
break;
}
Expected result:
Should return false.
Actual result:
--
Returns true;
--
Edit this bug report at http://bugs.php.net/bug.php?id=53584&edit=1
Bug #53584 [Com]: Asterisk character equals 0
Edit report at http://bugs.php.net/bug.php?id=53584&edit=1
ID: 53584
Comment by: andy dot mezey at gmail dot com
Reported by:andy dot mezey at gmail dot com
Summary:Asterisk character equals 0
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
Are you saying when running the examples provided nothing was printed to
the screen; that the statements returned false? I just tried my
examples on another server running PHP Version 5.2.13 and received the
same results as before. When I execute the code var_dump( "*" == 0 );,
bool(true) is returned.
Previous Comments:
[2010-12-20 22:20:42] cataphr...@php.net
Everything in your test script is expected behavior. "*" == "0" being
true is not, but that claim isn't tested in the test script and I can't
reproduce, which leads me to conclude it was a mistake on the your
part.
php -r 'var_dump("*" == "0");'
bool(false)
[2010-12-20 21:45:11] andy dot mezey at gmail dot com
Description:
Using PHP Version 5.3.2-1ubuntu4.5. When a variable holds the value "*"
and when being compared against the values 0 or "0" using the equal
operator, true is always returned. I did look here:
http://php.net/manual/en/language.types.type-juggling.php and I do not
see a reason for this behavior. The Identical operator does however
return false which is what you would expect.
Test script:
---
$var1 = "*";
if( $var1 == 0 )
{
echo "ok";
}
switch( $var1 )
{
case 0 :
echo "ok";
break;
}
$var2 = "\*";
if( $var2 == 0 )
{
echo "ok";
}
switch( $var2 )
{
case 0 :
echo "ok";
break;
}
Expected result:
Should return false.
Actual result:
--
Returns true;
--
Edit this bug report at http://bugs.php.net/bug.php?id=53584&edit=1
Bug #53584 [Opn->Bgs]: Asterisk character equals 0
Edit report at http://bugs.php.net/bug.php?id=53584&edit=1
ID: 53584
Updated by: cataphr...@php.net
Reported by:andy dot mezey at gmail dot com
Summary:Asterisk character equals 0
-Status: Open
+Status: Bogus
Type: Bug
-Package:Output Control
+Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
Everything in your test script is expected behavior. "*" == "0" being
true is not, but that claim isn't tested in the test script and I can't
reproduce, which leads me to conclude it was a mistake on the your
part.
php -r 'var_dump("*" == "0");'
bool(false)
Previous Comments:
[2010-12-20 21:45:11] andy dot mezey at gmail dot com
Description:
Using PHP Version 5.3.2-1ubuntu4.5. When a variable holds the value "*"
and when being compared against the values 0 or "0" using the equal
operator, true is always returned. I did look here:
http://php.net/manual/en/language.types.type-juggling.php and I do not
see a reason for this behavior. The Identical operator does however
return false which is what you would expect.
Test script:
---
$var1 = "*";
if( $var1 == 0 )
{
echo "ok";
}
switch( $var1 )
{
case 0 :
echo "ok";
break;
}
$var2 = "\*";
if( $var2 == 0 )
{
echo "ok";
}
switch( $var2 )
{
case 0 :
echo "ok";
break;
}
Expected result:
Should return false.
Actual result:
--
Returns true;
--
Edit this bug report at http://bugs.php.net/bug.php?id=53584&edit=1
[PHP-BUG] Bug #53584 [NEW]: Asterisk character equals 0
From:
Operating system: Linux
PHP version: 5.3.4
Package: Output Control
Bug Type: Bug
Bug description:Asterisk character equals 0
Description:
Using PHP Version 5.3.2-1ubuntu4.5. When a variable holds the value "*"
and when being compared against the values 0 or "0" using the equal
operator, true is always returned. I did look here:
http://php.net/manual/en/language.types.type-juggling.php and I do not see
a reason for this behavior. The Identical operator does however return
false which is what you would expect.
Test script:
---
$var1 = "*";
if( $var1 == 0 )
{
echo "ok";
}
switch( $var1 )
{
case 0 :
echo "ok";
break;
}
$var2 = "\*";
if( $var2 == 0 )
{
echo "ok";
}
switch( $var2 )
{
case 0 :
echo "ok";
break;
}
Expected result:
Should return false.
Actual result:
--
Returns true;
--
Edit bug report at http://bugs.php.net/bug.php?id=53584&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53584&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53584&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53584&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53584&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53584&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53584&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53584&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53584&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53584&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53584&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53584&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53584&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53584&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53584&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53584&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53584&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53584&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53584&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53584&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53584&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53584&r=mysqlcfg
Bug #50431 [Com]: Using filter_var to filter an email address returns incorrect result
Edit report at http://bugs.php.net/bug.php?id=50431&edit=1
ID: 50431
Comment by: vaughan dot montgomery at gmail dot com
Reported by:troy at scriptedmotion dot com
Summary:Using filter_var to filter an email address returns
incorrect result
Status: Bogus
Type: Bug
Package:Filter related
Operating System: Ubuntu
PHP Version:5.2.11
Block user comment: N
Private report: N
New Comment:
that's true. but in the real world! we aren't dealing with local issues.
yes
t...@localhost is valid for local, but it's no good on a remote server.
i want
my users to have to enter their address as t...@test.com or .co.uk or
whatever,
like everyone else out there who wants to use this filter for validating
user
email addresses. why is this so difficult to get through? what is so
wrong with
changing it or adding a filter flag to the filter for top level domains
etc?
then we have the best of both worlds.
if you won't do something about it, then this filter is pretty much
useless to
many people, i would have preferred to use it, but will have to stick to
using
the cumbersome regex method instead.
Previous Comments:
[2010-12-20 19:56:52] ras...@php.net
Even if he enters t...@test.com that still doesn't tell you if the email
will get
through to him. You are in the same position. The filter simply
validates the
string as a valid-looking email address. Whether or not this is the
actual user's
email address is way beyond the scope of this function. You can take it
further
and do an MX lookup on it, but that just means the host exists, it
doesn't mean
that user has an account on that box. The only way to know is to
actually deliver
an email to the address and see if the user gets it.
[2010-12-20 02:02:29] vaughan dot montgomery at gmail dot com
ok you say that's a valid email.. but in a working user environment,
using this
filter to VALIDATE an email address is unworkable.
when users register on my site, i want to validate their email address.
if the user enters t...@test, it returns as valid. but how on earth does
my
server know that the users email address .com/.net/.co.uk/.biz etc. so
when it
tries to send the user an email to validate his email address in order
to
register on my site, he never receives the email because the server
doesn't know
where to send it.
this means i can't use this filter for its intended purpose of
validating an
email address.
back to using regex and the old PHP 4 methods.
either make the filter return as invalid, or add an extra parameter to
tell it
to validate with a top level domain.
ie. filter_var('t...@test', FILTER_VALIDATE_EMAIL, FILTER_FLAG_TOP_LEVEL)
if FILTER_FLAG_TOP_LEVEL is set, then 't...@test' returns invalid, if
not, then
return valid.
problem solved, and i'm sure many users would apreciate it.
[2010-08-20 16:53:27] michael at squiloople dot com
The standards are actually RFC 5321 and 5322, and according to RFC 5321
(which
goes into more specific detail over domain names in email addresses),
"in the case
of a top-level domain used by itself in an email address, a single
string is used
without any dots."
[2010-05-08 02:32:01] office at lucian0308 dot com
i see a deference
the standard is http://tools.ietf.org/html/rfc2822
this function respect the standard?
because PEAR
http://pear.php.net/manual/en/package.validate.validate.email.php
say that use RFC2822 and it works corectly
without dot and level domain shoud be a false email.
[2009-12-09 19:02:01] ras...@php.net
That's a valid email address. Email addresses don't need a tld. Try
emailing r...@localhost, for example. Any locally defined host can
potentially receive 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=50431
--
Edit this bug report at http://bugs.php.net/bug.php?id=50431&edit=1
Bug #50431 [Bgs]: Using filter_var to filter an email address returns incorrect result
Edit report at http://bugs.php.net/bug.php?id=50431&edit=1
ID: 50431
Updated by: ras...@php.net
Reported by:troy at scriptedmotion dot com
Summary:Using filter_var to filter an email address returns
incorrect result
Status: Bogus
Type: Bug
Package:Filter related
Operating System: Ubuntu
PHP Version:5.2.11
Block user comment: N
Private report: N
New Comment:
Even if he enters t...@test.com that still doesn't tell you if the email
will get
through to him. You are in the same position. The filter simply
validates the
string as a valid-looking email address. Whether or not this is the
actual user's
email address is way beyond the scope of this function. You can take it
further
and do an MX lookup on it, but that just means the host exists, it
doesn't mean
that user has an account on that box. The only way to know is to
actually deliver
an email to the address and see if the user gets it.
Previous Comments:
[2010-12-20 02:02:29] vaughan dot montgomery at gmail dot com
ok you say that's a valid email.. but in a working user environment,
using this
filter to VALIDATE an email address is unworkable.
when users register on my site, i want to validate their email address.
if the user enters t...@test, it returns as valid. but how on earth does
my
server know that the users email address .com/.net/.co.uk/.biz etc. so
when it
tries to send the user an email to validate his email address in order
to
register on my site, he never receives the email because the server
doesn't know
where to send it.
this means i can't use this filter for its intended purpose of
validating an
email address.
back to using regex and the old PHP 4 methods.
either make the filter return as invalid, or add an extra parameter to
tell it
to validate with a top level domain.
ie. filter_var('t...@test', FILTER_VALIDATE_EMAIL, FILTER_FLAG_TOP_LEVEL)
if FILTER_FLAG_TOP_LEVEL is set, then 't...@test' returns invalid, if
not, then
return valid.
problem solved, and i'm sure many users would apreciate it.
[2010-08-20 16:53:27] michael at squiloople dot com
The standards are actually RFC 5321 and 5322, and according to RFC 5321
(which
goes into more specific detail over domain names in email addresses),
"in the case
of a top-level domain used by itself in an email address, a single
string is used
without any dots."
[2010-05-08 02:32:01] office at lucian0308 dot com
i see a deference
the standard is http://tools.ietf.org/html/rfc2822
this function respect the standard?
because PEAR
http://pear.php.net/manual/en/package.validate.validate.email.php
say that use RFC2822 and it works corectly
without dot and level domain shoud be a false email.
[2009-12-09 19:02:01] ras...@php.net
That's a valid email address. Email addresses don't need a tld. Try
emailing r...@localhost, for example. Any locally defined host can
potentially receive email.
[2009-12-09 18:59:19] troy at scriptedmotion dot com
Description:
Using filter_var to filter a string containing an email address with no
top level domain returns the string instead of false.
For example:
filter_var('t...@1', FILTER_VALIDATE_EMAIL);
returns 't...@1' instead of false.
Reproduce code:
---
filter_var('t...@1', FILTER_VALIDATE_EMAIL); // returns 't...@1' instead of
false.
Expected result:
false
Actual result:
--
"t...@1" // a string
--
Edit this bug report at http://bugs.php.net/bug.php?id=50431&edit=1
Bug #53572 [Com]: Bug appeared in php 5.2.15, FastCGI
Edit report at http://bugs.php.net/bug.php?id=53572&edit=1 ID: 53572 Comment by: markusb at gmx dot at Reported by:admin at xaker1 dot ru Summary:Bug appeared in php 5.2.15, FastCGI Status: Open Type: Bug Package:Unknown/Other Function Operating System: FreeBSD 8.1 PHP Version:5.2.16 Block user comment: N Private report: N New Comment: Same probleme We use php (cgi) and open_basedir > all php scrips > No input file specified. Previous Comments: [2010-12-19 09:05:26] admin at xaker1 dot ru The problem exists on php 5.2.15 and php 5.2.16. I'm using php 5.2.14, as work is needed for all sites. php.ini on the affected account: register_globals = Off display_errors = Off log_errors = On max_execution_time = 30 memory_limit = 128M upload_max_filesize = 16M post_max_size = 16M session.save_path = "/ home/saki2/data/tmp" upload_tmp_dir = "/ home/saki2/data/tmp" open_basedir = "/ home/saki2: / tmp: / var / tmp" ; [suhosin] ; suhosin.log.syslog = E_ALL & ~ S_SQL ; suhosin.log.sapi = E_ALL & ~ S_SQL ; suhosin.executor.include.max_traversal = 4 ; suhosin.executor.func.blacklist = popen, dl, passthru, system, exec, proc_open, shell_exec, proc_close, symlink ; WARNING ; Or eAccelerator or Zend!!! ; Not twice!!! ; [eAccelerator] ; zend_extension = "/ usr/local/lib/php/20060613/eaccelerator.so" ; eaccelerator.cache_dir = "/ home/saki2/data/tmp" ; eaccelerator.debug = "0" ; eaccelerator.shm_size = "16" ; [Zend] ; zend_optimizer.optimization_level = 15 ; zend_extension_manager.optimizer = "/ usr/local/lib/php/20060613/Optimizer" ; zend_extension_manager.optimizer_ts = "/ usr/local/lib/php/20060613/Optimizer_TS" ; zend_extension = "/ usr/local/lib/php/20060613/ZendExtensionManager.so" ; zend_extension_ts = "/ usr/local/lib/php/20060613/ZendExtensionManager_TS.so" php.ini in the working account: register_globals= Off display_errors= On log_errors= On max_execution_time= 900 memory_limit= 512M upload_max_filesize= 16M post_max_size = 16M session.save_path = "/home/bravohost/data/tmp" upload_tmp_dir="/home/bravohost/data/tmp" open_basedir = "/home/bravohost:/tmp:/var/tmp" ;[suhosin] ;suhosin.log.syslog = E_ALL & ~S_SQL ;suhosin.log.sapi = E_ALL & ~S_SQL ;suhosin.executor.include.max_traversal = 4 ;suhosin.executor.func.blacklist = popen,dl,passthru,system,exec,proc_open,shell_exec,proc_close,symlink ; WARNING ; or eAccelerator or Zend!!! ; not twice!!! [eAccelerator] zend_extension="/usr/local/lib/php/20060613/eaccelerator.so" eaccelerator.cache_dir="/home/bravohost/data/tmp" eaccelerator.debug="0" eaccelerator.shm_size="16" ;[Zend] ;zend_optimizer.optimization_level=15 ;zend_extension_manager.optimizer="/usr/local/lib/php/20060613/Optimizer" ;zend_extension_manager.optimizer_ts="/usr/local/lib/php/20060613/Optimizer_TS" ;zend_extension="/usr/local/lib/php/20060613/ZendExtensionManager.so" ;zend_extension_ts="/usr/local/lib/php/20060613/ZendExtensionManager_TS.so ;extension = filter.so php modules are used: [PHP Modules] bcmath bz2 calendar ctype curl date dom filter gd gettext hash iconv imap ionCube Loader json libxml mbstring mcrypt mhash mysql mysqli openssl pcre PDO pdo_mysql pdo_sqlite posix Reflection session SimpleXML sockets SPL SQLite standard suhosin tokenizer xml xmlreader xmlwriter Zend Optimizer zip zlib [Zend Modules] Zend Extension Manager Zend Optimizer the ionCube PHP Loader [2010-12-18 22:14:48] cataphr...@php.net We'd need more information than what you gave. First, are you using 5.2.15 or 5.2.16. If you're using 5.2.15, upgrade. Then, what exactly is causing this (not a vague it may be root folder or name/group or open_basedir) and, preferably, steps to reproduce, would go a long way. Thanks. [2010-12-18 18:03:27] admin at xaker1 dot ru If you downgrade to 5.2.14, the error disappears. At the moment the causes of errors are found, ask for help. [2010-12-18 18:02:10] admin at xaker1 dot ru Description: Any php script Test script: --- Actual result: -- The script fails, the message "No input file specified.". Sometimes the script works. The problem occurred in 2 of the account's 300. Accounts differ in the root folder, name\group file and set open_basedir. If you downgrade to 5.2.1914, the error disappears. At the moment the causes of errors are found, ask for help. -- Edit this bug report at http://bugs.php.net/bug.php?id=53572&edit
Bug #53352 [Com]: open_basedir does not pass through files with matching path
Edit report at http://bugs.php.net/bug.php?id=53352&edit=1 ID: 53352 Comment by: lekensteyn at gmail dot com Reported by:dmitrij at stepanov dot lv Summary:open_basedir does not pass through files with matching path Status: Closed Type: Bug Package:Safe Mode/open_basedir Operating System: Windows 7 PHP Version:5.3SVN-2010-11-19 (SVN) Assigned To:pajoye Block user comment: N Private report: N New Comment: Please see bug #53577 (marked as dupe), the patch provided was incomplete. Direct link to the patch: http://bugs.php.net/patch-display.php?bug_id=53577&patch=open_basedir-trailing-slash-fix-PHP_5_3&revision=latest Previous Comments: [2010-12-09 18:04:39] paj...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=306136 Log: - missing merge fix for #53352 [2010-11-24 10:17:39] paj...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2010-11-24 10:09:17] dmitrij at stepanov dot lv Sorry, my bad. Missed the "equal or" opcode :) r305698 works fine, issue is gone. Thanks. [2010-11-24 09:59:32] paj...@php.net Superior or equal to r305698, the r305698 is there :) [2010-11-24 07:24:08] dmitrij at stepanov dot lv Still see no snap at http://rmtools.php.net/snaps/ that is superior to r305698. Once it's there, I will reply with the results. 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=53352 -- Edit this bug report at http://bugs.php.net/bug.php?id=53352&edit=1
Bug #53483 [Com]: using mysqli_stmt::send_long_data() makes execute() fail
Edit report at http://bugs.php.net/bug.php?id=53483&edit=1 ID: 53483 Comment by: jbreton at kronostechnologies dot com Reported by:squarious at gmail dot com Summary:using mysqli_stmt::send_long_data() makes execute() fail Status: Open Type: Bug Package:MySQLi related Operating System: linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: I upgraded mysql to 5.1.54 using debian experimental packages and the problem is gone. Hopefully it won't break my ubuntu setup, which was a brand new 10.10 using official packages. Previous Comments: [2010-12-20 17:14:09] jbreton at kronostechnologes dot com You haven't tried mysql5.1.49 which was specified in squarious' description. I just tried with php 5.3.4 stable and mysql5.1.49 without success. [2010-12-20 17:14:07] jbreton at kronostechnologes dot com You haven't tried mysql5.1.49 which was specified in squarious' description. I just tried with php 5.3.4 stable and mysql5.1.49 without success. [2010-12-20 16:51:45] and...@php.net I can't reproduce the problem :( [2010-12-20 16:50:58] and...@php.net libmysql + MySQL 5.1.55 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. mysqlnd + MySQL 5.1.55 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. [2010-12-20 16:02:05] and...@php.net libmysql + MySQL 5.0.90 and...@poohie:~PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. libmysql + MySQL 5.5.8 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. 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=53483 -- Edit this bug report at http://bugs.php.net/bug.php?id=53483&edit=1
Bug #53577 [Dup]: Regression (5.3.3-5.3.4) in open_basedir with a trailing forward slash
Edit report at http://bugs.php.net/bug.php?id=53577&edit=1
ID: 53577
User updated by:lekensteyn at gmail dot com
Reported by:lekensteyn at gmail dot com
Summary:Regression (5.3.3-5.3.4) in open_basedir with a
trailing forward slash
Status: Duplicate
Type: Bug
Package:Safe Mode/open_basedir
Operating System: Windows 7
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
This is related to bug #53352 , but not an exact duplicate.
I've just added a patch on fopen_wrappers.c from the PHP 5.3 branch,
r305698 (
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/main/fopen_wrappers.c?view=markup&pathrev=305698
)
The patch fixed it for me.
Previous Comments:
[2010-12-20 07:34:40] ahar...@php.net
Duplicate of bug #53352.
[2010-12-19 23:58:32] lekensteyn at gmail dot com
I'm just guessing, replacing the following:
-- snip --
if (basedir[strlen(basedir) - 1] == PHP_DIR_SEPARATOR) {
if (resolved_basedir[resolved_basedir_len - 1] !=
PHP_DIR_SEPARATOR)
{
resolved_basedir[resolved_basedir_len] =
PHP_DIR_SEPARATOR;
resolved_basedir[++resolved_basedir_len] = '\0';
}
} else {
resolved_basedir[resolved_basedir_len++] =
PHP_DIR_SEPARATOR;
resolved_basedir[resolved_basedir_len] = '\0';
}
-- snip --
with
-- snip --
if (basedir[strlen(basedir) - 1] == PHP_DIR_SEPARATOR) {
if (resolved_basedir[resolved_basedir_len - 1] !=
PHP_DIR_SEPARATOR)
{
resolved_basedir[resolved_basedir_len] =
PHP_DIR_SEPARATOR;
resolved_basedir[++resolved_basedir_len] = '\0';
}
#if defined(PHP_WIN32) || defined(NETWARE)
} else if (basedir[strlen(basedir) - 1] != '/') {
#else
} else {
#endif
resolved_basedir[resolved_basedir_len++] =
PHP_DIR_SEPARATOR;
resolved_basedir[resolved_basedir_len] = '\0';
}
-- snip --
should work.
Under Windows, PHP_DIR_SEPARATOR is a backslash. So we check here if it
is a forward slash.
[2010-12-19 23:44:46] lekensteyn at gmail dot com
Description:
Downloaded PHP 5.3.3 from:
http://windows.php.net/downloads/releases/archives/php-5.3.3-nts-Win32-VC9-x86.zip
Downloaded PHP 5.3.4 from:
http://windows.php.net/downloads/releases/php-5.3.4-nts-Win32-VC9-x86.zip
The following settings has the expected results in both PHP 5.3.3 and
PHP 5.3.4
open_basedir="C:\twlan\"
open_basedir="C:\twlan"
open_basedir="C:/twlan"
open_basedir="C:/twlan\"
The following setting breaks open_basedir in PHP 5.3.4, but works fine
in 5.3.3.
open_basedir="C:/twlan/"
So, the trailing forward slash on open_basedir makes every path
invalid.
Changes between 5.3.3 and 5.3.4:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/main/fopen_wrappers.c?r1=301440&r2=306091
I think the bug was introduced in
http://svn.php.net/viewvc/php/php-src/trunk/main/fopen_wrappers.c?r1=305098&r2=305698
--- begin code ---
@@ -228,6 +234,9 @@
resolved_basedir[resolved_basedir_len] =
PHP_DIR_SEPARATOR;
resolved_basedir[++resolved_basedir_len] = '\0';
}
+ } else {
+ resolved_basedir[resolved_basedir_len++] =
PHP_DIR_SEPARATOR;
+ resolved_basedir[resolved_basedir_len] = '\0';
}
resolved_name_len = strlen(resolved_name);
--- end code ---
PHP_DIR_SEPARATOR is "\\" on Windows.
Test script:
---
Expected result:
string(22) "C:\twlan\htdocs\combot"
string(15) "C:\twlan\htdocs"
string(8) "C:\twlan"
Warning: realpath(): open_basedir restriction in effect. File(C:\) is
not within the allowed path(s): (C:/twlan/) in
C:\twlan\htdocs\combot\php-bug.php on line 7
bool(false)
Actual result:
--
Warning: realpath(): open_basedir restriction in effect.
File(C:\twlan\htdocs) is not within the allowed path(s): (C:/twlan/) in
C:\twlan\htdocs\combot\php-bug.php on line 5
bool(false)
Warning: realpath(): open_basedir restriction in effect.
File(C:\twlan\htdocs) is not within the allowed path(s): (C:/twlan/) in
C:\twlan\htdocs\combot\php-bug.php on line 5
bool(false)
Warning: realpath(): open_basedir restriction in effect. File(C:\twlan
Bug #53569 [Fbk->Opn]: Intermittent Seg Fault during DOMDocument clean up
Edit report at http://bugs.php.net/bug.php?id=53569&edit=1
ID: 53569
User updated by:chris dot richard at gmail dot com
Reported by:chris dot richard at gmail dot com
Summary:Intermittent Seg Fault during DOMDocument clean up
-Status: Feedback
+Status: Open
Type: Bug
Package:DOM XML related
Operating System: Linux (Ubuntu 10)
PHP Version:5.3.2
Block user comment: N
Private report: N
New Comment:
This script reproduces the issue fairly consistently on my machine:
loadXML(
"".
'http://www.w3.org/TR/html4/strict.dtd"; [
]>'.
"");
$fragment = $doc->createDocumentFragment();
$fragment->appendXML("");
$doc->documentElement->appendChild($fragment);
ob_start();
?>
lorem ipsum dolor sit amet lorem ipsum dolor sit amet lorem ipsum
dolor sit
amet
lorem ipsum dolor sit amet lorem ipsum dolor sit amet
lorem ipsum dolor sit amet lorem ipsum dolor sit amet
lorem ipsum dolor sit amet lorem ipsum dolor sit amet
lorem ipsum dolor sit amet lorem ipsum dolor sit amet
lorem ipsum dolor sit amet lorem ipsum dolor sit amet
When the mortgage rate is 'fixed' it means that the rate (%) is set
for the
duration of the term, whereas with a variable mortgage rate, the rate
fluctuates
with the market interest rate, known as the 'prime rate'. So, for
example, if
the 5 year fixed mortgage rate is 4%, then you will pay 4% interest
throughout
the term of the mortgage.
lorem ipsum dolor sit amet lorem ipsum dolor sit amet
Popularity of the 5-year fixed rate
Mortgages by length of term and age group
Age group
18-34 35-54 55+ All
ages
1 year term
5%
7%
6%
6%
2-4 year term
27%
18%
12%
20%
5 year term
66%
65%
69%
66%
6-10 year term
3%
9%
10%
7%
>10 year term
0
0
2%
1%
createDocumentFragment();
$fragment->appendXML($output);
$xpath = new DOMXpath($doc);
$insert = $xpath->query(".//insert")->item(0);
$insert->parentNode->replaceChild($fragment, $insert);
echo $doc->saveHTML();
?>
Previous Comments:
[2010-12-18 16:57:51] cataphr...@php.net
Can you provide a small script that reproduces this issue?
It's complicated to find the error from backtraces that happen in the
destruction phase; by this time the harm has long been done.
Also please use the latest version of PHP.
Thank you.
[2010-12-18 06:16:59] chris dot richard at gmail dot com
PHP 5.3.2
libxml 2.7.6
[2010-12-18 06:11:31] chris dot richard at gmail dot com
Description:
libxml causes a seg fault *intermittently* after all PHP user code has
finished
running.
I'm using DOMFragment to parse chunks of XHTML and append them to a
DOMDocument
which gets output (via saveHTML) once it's completely assembled. The
output
completes successfully but at least half the time I get seg fault
related to the
clean up of the DOMDocument and no response is sent to the client.
Core Dump:
#0 0x7fb2f77c6e6f in xmlDictOwns () from /usr/lib/libxml2.so.2
#1 0x7fb2f77276a7 in xmlFreeNodeList () from /usr/lib/libxml2.so.2
#2 0x7fb2f76ff85f in ?? () from /usr/lib/libxml2.so.2
#3 0x7fb2f772f256 in xmlHashFree () from /usr/lib/libxml2.so.2
#4 0x7fb2f7727335 in xmlFreeDtd () from /usr/lib/libxml2.so.2
#5 0x7fb2f772746a in xmlFreeDoc () from /usr/lib/libxml2.so.2
#6 0x7fb2f8409d5b in php_libxml_decrement_doc_ref ()
from /usr/lib/apache2/modules/libphp5.so
#7 0x7fb2f842e8cf in ?? () from
/usr/lib/apache2/modules/libphp5.so
#8 0x7fb2f8661adc in zend_objects_store_del_ref_by_handle_ex ()
from /usr/lib/apache2/modules/libphp5.so
#9 0x7fb2f8661b03 in zend_objects_store_del_ref ()
from /usr/lib/apache2/modules/libphp5.so
#10 0x7fb2f86301cd in _zval_ptr_dtor () from
/usr/lib/apache2/modules/libphp5.so
#11 0x7fb2f8649198 in zend_hash_destroy () from
/usr/lib/apache2/modules/libphp5.so
#12 0x7fb2f863c19f in _zval_dtor_func () from
/usr/lib/apache2/modules/libphp5.so
#13 0x7fb2f86301cd in _zval_ptr_dtor () from
/usr/lib/apache2/modules/libphp5.so
#14 0x7fb2f8649198 in zend_hash_destroy () from
/usr/lib/apache2/modules/libphp5.so
#15 0x7fb2f865e0d9 in zend_object_std_dtor () from
/usr/lib/apache2/modules/libphp5.so
#16 0x7fb2f865e0f9 in zend_objects_free_object_storage ()
from /usr/lib/apache2/modules/libphp5.so
#17 0x00
Bug #53483 [Com]: using mysqli_stmt::send_long_data() makes execute() fail
Edit report at http://bugs.php.net/bug.php?id=53483&edit=1 ID: 53483 Comment by: jbreton at kronostechnologes dot com Reported by:squarious at gmail dot com Summary:using mysqli_stmt::send_long_data() makes execute() fail Status: Open Type: Bug Package:MySQLi related Operating System: linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: You haven't tried mysql5.1.49 which was specified in squarious' description. I just tried with php 5.3.4 stable and mysql5.1.49 without success. Previous Comments: [2010-12-20 17:14:07] jbreton at kronostechnologes dot com You haven't tried mysql5.1.49 which was specified in squarious' description. I just tried with php 5.3.4 stable and mysql5.1.49 without success. [2010-12-20 16:51:45] and...@php.net I can't reproduce the problem :( [2010-12-20 16:50:58] and...@php.net libmysql + MySQL 5.1.55 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. mysqlnd + MySQL 5.1.55 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. [2010-12-20 16:02:05] and...@php.net libmysql + MySQL 5.0.90 and...@poohie:~PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. libmysql + MySQL 5.5.8 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. [2010-12-20 15:55:06] and...@php.net mysqlnd with MySQL 5.0.90 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. Error executing prepared statement. Got a packet bigger than 'max_allowed_packet' bytes 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=53483 -- Edit this bug report at http://bugs.php.net/bug.php?id=53483&edit=1
Bug #53483 [Com]: using mysqli_stmt::send_long_data() makes execute() fail
Edit report at http://bugs.php.net/bug.php?id=53483&edit=1 ID: 53483 Comment by: jbreton at kronostechnologes dot com Reported by:squarious at gmail dot com Summary:using mysqli_stmt::send_long_data() makes execute() fail Status: Open Type: Bug Package:MySQLi related Operating System: linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: You haven't tried mysql5.1.49 which was specified in squarious' description. I just tried with php 5.3.4 stable and mysql5.1.49 without success. Previous Comments: [2010-12-20 16:51:45] and...@php.net I can't reproduce the problem :( [2010-12-20 16:50:58] and...@php.net libmysql + MySQL 5.1.55 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. mysqlnd + MySQL 5.1.55 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. [2010-12-20 16:02:05] and...@php.net libmysql + MySQL 5.0.90 and...@poohie:~PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. libmysql + MySQL 5.5.8 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. [2010-12-20 15:55:06] and...@php.net mysqlnd with MySQL 5.0.90 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. Error executing prepared statement. Got a packet bigger than 'max_allowed_packet' bytes [2010-12-20 15:10:31] and...@php.net with mysqlnd and MySQL 5.5.8 GA and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. Seems there was a problem in 5.5.5 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=53483 -- Edit this bug report at http://bugs.php.net/bug.php?id=53483&edit=1
Bug #53483 [Opn]: using mysqli_stmt::send_long_data() makes execute() fail
Edit report at http://bugs.php.net/bug.php?id=53483&edit=1 ID: 53483 Updated by: and...@php.net Reported by:squarious at gmail dot com Summary:using mysqli_stmt::send_long_data() makes execute() fail Status: Open Type: Bug Package:MySQLi related Operating System: linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: I can't reproduce the problem :( Previous Comments: [2010-12-20 16:50:58] and...@php.net libmysql + MySQL 5.1.55 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. mysqlnd + MySQL 5.1.55 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. [2010-12-20 16:02:05] and...@php.net libmysql + MySQL 5.0.90 and...@poohie:~PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. libmysql + MySQL 5.5.8 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. [2010-12-20 15:55:06] and...@php.net mysqlnd with MySQL 5.0.90 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. Error executing prepared statement. Got a packet bigger than 'max_allowed_packet' bytes [2010-12-20 15:10:31] and...@php.net with mysqlnd and MySQL 5.5.8 GA and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. Seems there was a problem in 5.5.5 [2010-12-08 16:24:53] and...@php.net Looks a problem because of this MySQL Server bug http://bugs.mysql.com/bug.php?id=26824 After trying the script with 5.3.4-dev , libmysql from Ubuntu 9.10 and mysqlnd, and two different MySQL versions 5.1.51 and 5.5.5-m3. MySQL 5.1 libmysql : OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. myslqnd: OK: Executed prepared statement with blob less than max_allowed_packet. and then few errors because of Packet out of order - an error packet interleaving (see the MySQL bug description for more information) MySQL 5.5 libmysql : OK: Executed prepared statement with blob less than max_allowed_packet. Error executing prepared statement. Incorrect arguments to mysqld_stmt_execute mysqlnd: OK: Executed prepared statement with blob less than max_allowed_packet. Error executing prepared statement. Incorrect arguments to mysqld_stmt_execute This needs more investigation with wireshark, something changed in the server but in any case there was a problem. Haven't checked with MySQL 5.0, as I don't have one handy. 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=53483 -- Edit this bug report at http://bugs.php.net/bug.php?id=53483&edit=1
Bug #53483 [Opn]: using mysqli_stmt::send_long_data() makes execute() fail
Edit report at http://bugs.php.net/bug.php?id=53483&edit=1 ID: 53483 Updated by: and...@php.net Reported by:squarious at gmail dot com Summary:using mysqli_stmt::send_long_data() makes execute() fail Status: Open Type: Bug Package:MySQLi related Operating System: linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: libmysql + MySQL 5.1.55 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. mysqlnd + MySQL 5.1.55 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. Previous Comments: [2010-12-20 16:02:05] and...@php.net libmysql + MySQL 5.0.90 and...@poohie:~PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. libmysql + MySQL 5.5.8 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. [2010-12-20 15:55:06] and...@php.net mysqlnd with MySQL 5.0.90 and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. Error executing prepared statement. Got a packet bigger than 'max_allowed_packet' bytes [2010-12-20 15:10:31] and...@php.net with mysqlnd and MySQL 5.5.8 GA and...@poohie:~/PHP_5_3$ ./php a.php OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. Seems there was a problem in 5.5.5 [2010-12-08 16:24:53] and...@php.net Looks a problem because of this MySQL Server bug http://bugs.mysql.com/bug.php?id=26824 After trying the script with 5.3.4-dev , libmysql from Ubuntu 9.10 and mysqlnd, and two different MySQL versions 5.1.51 and 5.5.5-m3. MySQL 5.1 libmysql : OK: Executed prepared statement with blob less than max_allowed_packet. OK: Executed prepared statement with blob bigger than max_allowed_packet, sent at chunks. myslqnd: OK: Executed prepared statement with blob less than max_allowed_packet. and then few errors because of Packet out of order - an error packet interleaving (see the MySQL bug description for more information) MySQL 5.5 libmysql : OK: Executed prepared statement with blob less than max_allowed_packet. Error executing prepared statement. Incorrect arguments to mysqld_stmt_execute mysqlnd: OK: Executed prepared statement with blob less than max_allowed_packet. Error executing prepared statement. Incorrect arguments to mysqld_stmt_execute This needs more investigation with wireshark, something changed in the server but in any case there was a problem. Haven't checked with MySQL 5.0, as I don't have one handy. [2010-12-08 15:49:40] jbreton at kronostechnologies dot com I am experiencing the same problem, but I'm starting to think it is related to MySQL. I'm also using php5.3.3 and mysql5.1.49, but colleague is using php5.3.3 and mysql5.1.41 and your test passes without any problem. 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=53483 -- Edit this bug report at http://bugs.php.net/bug.php?id=53483&edit=1
Bug #53483 [Opn]: using mysqli_stmt::send_long_data() makes execute() fail
Edit report at http://bugs.php.net/bug.php?id=53483&edit=1
ID: 53483
Updated by: and...@php.net
Reported by:squarious at gmail dot com
Summary:using mysqli_stmt::send_long_data() makes execute()
fail
Status: Open
Type: Bug
Package:MySQLi related
Operating System: linux
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
libmysql + MySQL 5.0.90
and...@poohie:~PHP_5_3$ ./php a.php
OK: Executed prepared statement with blob less than max_allowed_packet.
OK: Executed prepared statement with blob bigger than
max_allowed_packet, sent at chunks.
libmysql + MySQL 5.5.8
and...@poohie:~/PHP_5_3$ ./php a.php
OK: Executed prepared statement with blob less than max_allowed_packet.
OK: Executed prepared statement with blob bigger than
max_allowed_packet, sent at chunks.
Previous Comments:
[2010-12-20 15:55:06] and...@php.net
mysqlnd with MySQL 5.0.90
and...@poohie:~/PHP_5_3$ ./php a.php
OK: Executed prepared statement with blob less than max_allowed_packet.
Error executing prepared statement. Got a packet bigger than
'max_allowed_packet' bytes
[2010-12-20 15:10:31] and...@php.net
with mysqlnd and MySQL 5.5.8 GA
and...@poohie:~/PHP_5_3$ ./php a.php
OK: Executed prepared statement with blob less than max_allowed_packet.
OK: Executed prepared statement with blob bigger than
max_allowed_packet, sent at chunks.
Seems there was a problem in 5.5.5
[2010-12-08 16:24:53] and...@php.net
Looks a problem because of this MySQL Server bug
http://bugs.mysql.com/bug.php?id=26824
After trying the script with 5.3.4-dev , libmysql from Ubuntu 9.10 and
mysqlnd, and two different MySQL versions 5.1.51 and 5.5.5-m3.
MySQL 5.1
libmysql :
OK: Executed prepared statement with blob less than max_allowed_packet.
OK: Executed prepared statement with blob bigger than
max_allowed_packet, sent at chunks.
myslqnd:
OK: Executed prepared statement with blob less than max_allowed_packet.
and then few errors because of Packet out of order - an error packet
interleaving (see the MySQL bug description for more information)
MySQL 5.5
libmysql :
OK: Executed prepared statement with blob less than max_allowed_packet.
Error executing prepared statement. Incorrect arguments to
mysqld_stmt_execute
mysqlnd:
OK: Executed prepared statement with blob less than max_allowed_packet.
Error executing prepared statement. Incorrect arguments to
mysqld_stmt_execute
This needs more investigation with wireshark, something changed in the
server but in any case there was a problem. Haven't checked with MySQL
5.0, as I don't have one handy.
[2010-12-08 15:49:40] jbreton at kronostechnologies dot com
I am experiencing the same problem, but I'm starting to think it is
related to
MySQL.
I'm also using php5.3.3 and mysql5.1.49, but colleague is using php5.3.3
and
mysql5.1.41 and your test passes without any problem.
[2010-12-06 12:22:36] squarious at gmail dot com
Description:
This bug was found from a framework test units after a system upgrade
(ubuntu/10.04 -> ubuntu/10.10). The bug was tracked that the
send_long_data() stopped working completely. If I try to use it for
large packets, the following execute() command will fail with error
"Error executing prepared statement. Incorrect arguments to
mysqld_stmt_execute".
I made a script that reproduces 100% the bug and I ran it at
ubuntu/10.04(php5.3.2, mysql5.1.41) PASS,
ubuntu/10.10(php5.3.3, mysql5.1.49) FAIL,
debian/squeeze(php5.3.3, mysql5.1.49) FAIL.
So I assume its a regression at php's 5.3.3.
Test script:
---
//Full test @ http://codepad.org/eKnJnWnC
// Code chunk that trigger the problem.
if (!$stmt->bind_param('b', $null))
die("Error binding parameters. {$stmt->error}\n");
foreach(str_split($big_data, $max_allowed_packet) as $packet )
if (!$stmt->send_long_data(0, $packet))
die("Error sending long packet. {$stmt->error}\n");
if (!$stmt->execute())
die("Error executing prepared statement. {$stmt->error}\n");
Expected result:
OK: Executed prepared statement with blob less than max_allowed_packet.
OK: Executed prepared statement with blob bigger than
max_allowed_packet, sent at chunks.
Actual result:
--
OK: Executed prepared statement with blob less than max_allowed_packet.
Error executing prepared statement. Incorrect arguments to
mysqld_stmt_execute
--
E
Bug #53483 [Opn]: using mysqli_stmt::send_long_data() makes execute() fail
Edit report at http://bugs.php.net/bug.php?id=53483&edit=1
ID: 53483
Updated by: and...@php.net
Reported by:squarious at gmail dot com
Summary:using mysqli_stmt::send_long_data() makes execute()
fail
Status: Open
Type: Bug
Package:MySQLi related
Operating System: linux
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
mysqlnd with MySQL 5.0.90
and...@poohie:~/PHP_5_3$ ./php a.php
OK: Executed prepared statement with blob less than max_allowed_packet.
Error executing prepared statement. Got a packet bigger than
'max_allowed_packet' bytes
Previous Comments:
[2010-12-20 15:10:31] and...@php.net
with mysqlnd and MySQL 5.5.8 GA
and...@poohie:~/PHP_5_3$ ./php a.php
OK: Executed prepared statement with blob less than max_allowed_packet.
OK: Executed prepared statement with blob bigger than
max_allowed_packet, sent at chunks.
Seems there was a problem in 5.5.5
[2010-12-08 16:24:53] and...@php.net
Looks a problem because of this MySQL Server bug
http://bugs.mysql.com/bug.php?id=26824
After trying the script with 5.3.4-dev , libmysql from Ubuntu 9.10 and
mysqlnd, and two different MySQL versions 5.1.51 and 5.5.5-m3.
MySQL 5.1
libmysql :
OK: Executed prepared statement with blob less than max_allowed_packet.
OK: Executed prepared statement with blob bigger than
max_allowed_packet, sent at chunks.
myslqnd:
OK: Executed prepared statement with blob less than max_allowed_packet.
and then few errors because of Packet out of order - an error packet
interleaving (see the MySQL bug description for more information)
MySQL 5.5
libmysql :
OK: Executed prepared statement with blob less than max_allowed_packet.
Error executing prepared statement. Incorrect arguments to
mysqld_stmt_execute
mysqlnd:
OK: Executed prepared statement with blob less than max_allowed_packet.
Error executing prepared statement. Incorrect arguments to
mysqld_stmt_execute
This needs more investigation with wireshark, something changed in the
server but in any case there was a problem. Haven't checked with MySQL
5.0, as I don't have one handy.
[2010-12-08 15:49:40] jbreton at kronostechnologies dot com
I am experiencing the same problem, but I'm starting to think it is
related to
MySQL.
I'm also using php5.3.3 and mysql5.1.49, but colleague is using php5.3.3
and
mysql5.1.41 and your test passes without any problem.
[2010-12-06 12:22:36] squarious at gmail dot com
Description:
This bug was found from a framework test units after a system upgrade
(ubuntu/10.04 -> ubuntu/10.10). The bug was tracked that the
send_long_data() stopped working completely. If I try to use it for
large packets, the following execute() command will fail with error
"Error executing prepared statement. Incorrect arguments to
mysqld_stmt_execute".
I made a script that reproduces 100% the bug and I ran it at
ubuntu/10.04(php5.3.2, mysql5.1.41) PASS,
ubuntu/10.10(php5.3.3, mysql5.1.49) FAIL,
debian/squeeze(php5.3.3, mysql5.1.49) FAIL.
So I assume its a regression at php's 5.3.3.
Test script:
---
//Full test @ http://codepad.org/eKnJnWnC
// Code chunk that trigger the problem.
if (!$stmt->bind_param('b', $null))
die("Error binding parameters. {$stmt->error}\n");
foreach(str_split($big_data, $max_allowed_packet) as $packet )
if (!$stmt->send_long_data(0, $packet))
die("Error sending long packet. {$stmt->error}\n");
if (!$stmt->execute())
die("Error executing prepared statement. {$stmt->error}\n");
Expected result:
OK: Executed prepared statement with blob less than max_allowed_packet.
OK: Executed prepared statement with blob bigger than
max_allowed_packet, sent at chunks.
Actual result:
--
OK: Executed prepared statement with blob less than max_allowed_packet.
Error executing prepared statement. Incorrect arguments to
mysqld_stmt_execute
--
Edit this bug report at http://bugs.php.net/bug.php?id=53483&edit=1
Req #28427 [Opn->Wfx]: &&= feature request
Edit report at http://bugs.php.net/bug.php?id=28427&edit=1 ID: 28427 Updated by: j...@php.net Reported by:fgasper at uiuc dot edu Summary:&&= feature request -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: n/a PHP Version:4.3.6 Block user comment: N Private report: N New Comment: Pointless, no other lang has this and it would be quite ambiguous. Previous Comments: [2004-05-18 06:05:16] fgasper at uiuc dot edu Description: Could a &&= operator be added to PHP? In other words: $a = $a && $b would become $a &&= $b -- Edit this bug report at http://bugs.php.net/bug.php?id=28427&edit=1
Req #33396 [Opn->Csd]: Scope Resolution Operator usage seems flawed
Edit report at http://bugs.php.net/bug.php?id=33396&edit=1
ID: 33396
Updated by: j...@php.net
Reported by:gabriel at helicoid dot net
Summary:Scope Resolution Operator usage seems flawed
-Status: Open
+Status: Closed
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:Class/Object related
Operating System: Any
PHP Version:4.3.11
-Assigned To:
+Assigned To:jani
Block user comment: N
Private report: N
New Comment:
Works in 5.3.4 at least. Some warnings though, but it does work. :)
Previous Comments:
[2005-06-20 00:11:19] php at taupehat dot com
Not only is the cause of the error a bit >odd< but the error message
itself is pretty opaque. Perhaps it could be switched to
T_DOUBLE_COLON? Yeah, it was a funny joke, but php has kind of reached
beyond its roots now and ought to start to shed that sort of silliness.
[2005-06-19 10:35:28] gabriel at helicoid dot net
number = $somenum;
TestTwo::testFunc();
}
}
class TestTwo {
function testFunc()
{
echo "{$this->number}\n";
}
}
$obj = new TestOne(3);
?>
This kind of functionality can't be replicated using call_user_func as a
workaround.
[2005-06-19 09:52:27] tony2...@php.net
You can use call_user_func() while this is not implemented.
[2005-06-19 05:42:14] gabriel at helicoid dot net
Description:
I believe there is a flaw in how the scope resolution operator works.
You can use a variable containing the name of the method you want to
call on the right hand side of the operator, which works fine. However,
if you try to have the class name on the left hand side in a variable,
you get a parse error:
Parse error: parse error, unexpected T_PAAMAYIM_NEKUDOTAYIM
I dare say that having the class name in a variable is actually more
useful than having the method name in a variable. You can already have
the class name in a variable if you're using the 'new' keyword, as my
example code shows, so the operation of the scope resolution operator
doesn't seem very consistent with this, which it should be.
A work around would be to actually instantiate an object from the class,
as my example code shows, however I don't think this is a particularly
good solution to this problem. eval()ing a section of code with the
class name as a variable would also work, but again, I don't think this
is a good solution either.
I don't _think_ allowing the scope resolution operator to operate in
this manner would break any existing scripts either, but I may be wrong.
Reproduce code:
---
class TestOne {
function testMethod($num)
{
echo "In testMethod - num is $num\n";
}
}
$method = 'testMethod';
$class = 'TestOne';
TestOne::$method('3');
//$class::testMethod('3'); // This doesn't work, and I believe it
should.
$obj =& new $class;
$obj->testMethod('4');
Expected result:
I expect $class::testMethod('3') to really evaluate to
TestOne::testMethod('3')
Actual result:
--
Parse error: parse error, unexpected T_PAAMAYIM_NEKUDOTAYIM
--
Edit this bug report at http://bugs.php.net/bug.php?id=33396&edit=1
Bug #53483 [Opn]: using mysqli_stmt::send_long_data() makes execute() fail
Edit report at http://bugs.php.net/bug.php?id=53483&edit=1
ID: 53483
Updated by: and...@php.net
Reported by:squarious at gmail dot com
Summary:using mysqli_stmt::send_long_data() makes execute()
fail
Status: Open
Type: Bug
Package:MySQLi related
Operating System: linux
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
with mysqlnd and MySQL 5.5.8 GA
and...@poohie:~/PHP_5_3$ ./php a.php
OK: Executed prepared statement with blob less than max_allowed_packet.
OK: Executed prepared statement with blob bigger than
max_allowed_packet, sent at chunks.
Seems there was a problem in 5.5.5
Previous Comments:
[2010-12-08 16:24:53] and...@php.net
Looks a problem because of this MySQL Server bug
http://bugs.mysql.com/bug.php?id=26824
After trying the script with 5.3.4-dev , libmysql from Ubuntu 9.10 and
mysqlnd, and two different MySQL versions 5.1.51 and 5.5.5-m3.
MySQL 5.1
libmysql :
OK: Executed prepared statement with blob less than max_allowed_packet.
OK: Executed prepared statement with blob bigger than
max_allowed_packet, sent at chunks.
myslqnd:
OK: Executed prepared statement with blob less than max_allowed_packet.
and then few errors because of Packet out of order - an error packet
interleaving (see the MySQL bug description for more information)
MySQL 5.5
libmysql :
OK: Executed prepared statement with blob less than max_allowed_packet.
Error executing prepared statement. Incorrect arguments to
mysqld_stmt_execute
mysqlnd:
OK: Executed prepared statement with blob less than max_allowed_packet.
Error executing prepared statement. Incorrect arguments to
mysqld_stmt_execute
This needs more investigation with wireshark, something changed in the
server but in any case there was a problem. Haven't checked with MySQL
5.0, as I don't have one handy.
[2010-12-08 15:49:40] jbreton at kronostechnologies dot com
I am experiencing the same problem, but I'm starting to think it is
related to
MySQL.
I'm also using php5.3.3 and mysql5.1.49, but colleague is using php5.3.3
and
mysql5.1.41 and your test passes without any problem.
[2010-12-06 12:22:36] squarious at gmail dot com
Description:
This bug was found from a framework test units after a system upgrade
(ubuntu/10.04 -> ubuntu/10.10). The bug was tracked that the
send_long_data() stopped working completely. If I try to use it for
large packets, the following execute() command will fail with error
"Error executing prepared statement. Incorrect arguments to
mysqld_stmt_execute".
I made a script that reproduces 100% the bug and I ran it at
ubuntu/10.04(php5.3.2, mysql5.1.41) PASS,
ubuntu/10.10(php5.3.3, mysql5.1.49) FAIL,
debian/squeeze(php5.3.3, mysql5.1.49) FAIL.
So I assume its a regression at php's 5.3.3.
Test script:
---
//Full test @ http://codepad.org/eKnJnWnC
// Code chunk that trigger the problem.
if (!$stmt->bind_param('b', $null))
die("Error binding parameters. {$stmt->error}\n");
foreach(str_split($big_data, $max_allowed_packet) as $packet )
if (!$stmt->send_long_data(0, $packet))
die("Error sending long packet. {$stmt->error}\n");
if (!$stmt->execute())
die("Error executing prepared statement. {$stmt->error}\n");
Expected result:
OK: Executed prepared statement with blob less than max_allowed_packet.
OK: Executed prepared statement with blob bigger than
max_allowed_packet, sent at chunks.
Actual result:
--
OK: Executed prepared statement with blob less than max_allowed_packet.
Error executing prepared statement. Incorrect arguments to
mysqld_stmt_execute
--
Edit this bug report at http://bugs.php.net/bug.php?id=53483&edit=1
Bug #47624 [Com]: SOAP response has int type for a key value that is out of range
Edit report at http://bugs.php.net/bug.php?id=47624&edit=1 ID: 47624 Comment by: dmitry dot revenko at gmail dot com Reported by:akshah123 at hotmail dot com Summary:SOAP response has int type for a key value that is out of range Status: Open Type: Bug Package:SOAP related Operating System: Linux PHP Version:5.3.1 Block user comment: N Private report: N New Comment: Just encountered the same problem. It's a shame this not fixed till now. Don't even know - what should I do with it now. Previous Comments: [2010-02-04 22:50:05] akshah123 at hotmail dot com The problem persists with php 5.3.1 as well. [2009-11-10 15:42:56] akshah123 at hotmail dot com I have tested this with 5.2.11 and the issue is there as well. Please let me know if I can provide any additional information that would help resolve this issue. I cannot upgrade my system and use cool new features in PHP 5.3 as this is blocking a major functionality in the application. Thanks. [2009-09-10 20:00:45] akshah123 at hotmail dot com The script on server side (temp.php): http://pastie.org/612784 The client side script to test: http://pastie.org/612787 Again, the error is: /Reports/test.php line 5 - SOAP-ERROR: Encoding: Can't decode apache map, only Strings or Longs are allowd as keys. Using the __getLastResponse() function I received following xml: http://pastie.org/612791 [2009-09-10 19:33:40] akshah123 at hotmail dot com The sample WSDL: http://pastie.org/612742 I am getting this error with another php script i run on a different servers. I have been able to reproduce this error on several machines with php version ranging from 5.2.2 to 5.3.0 [2009-09-07 20:22:18] sjo...@php.net Thank you for your bug report. Could you please supply us with a piece of WSDL describing the array? Also, which client are you using which gives this error? If I understand correctly, the problem occurs with the soapenc:array type and the Axis 1 SOAP library. 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=47624 -- Edit this bug report at http://bugs.php.net/bug.php?id=47624&edit=1
Bug #53227 [Fbk->Opn]: PHP Warning: mysql_pconnect(): MySQL server has gone away
Edit report at http://bugs.php.net/bug.php?id=53227&edit=1 ID: 53227 User updated by:tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:PHP Warning: mysql_pconnect(): MySQL server has gone away -Status: Feedback +Status: Open Type: Bug Package:MySQL related PHP Version:5.3.3 Block user comment: N Private report: N New Comment: mysqlnd Tyrael Previous Comments: [2010-12-20 14:22:52] and...@php.net do you use libmysql or mysqlnd? [2010-11-02 12:13:04] tyra3l at gmail dot com Description: On of my co-worker experienced, that some of the mysql_pconnect calls are returning this error. The exact same symptoms are described in the manual: http://php.net/manual/en/function.mysql-pconnect.php#99380 the code which produce this was working fine before migrating to 5.3 Test script: --- http://bugs.php.net/bug.php?id=53227&edit=1
Req #50595 [Opn->Fbk]: Mysqlnd extension needs to read my.ini file for sanity
Edit report at http://bugs.php.net/bug.php?id=50595&edit=1 ID: 50595 Updated by: and...@php.net Reported by:tallyce at gmail dot com Summary:Mysqlnd extension needs to read my.ini file for sanity -Status: Open +Status: Feedback Type: Feature/Change Request Package:MySQLi related Operating System: Windows7 PHP Version:5.3.1 Block user comment: N Private report: N New Comment: Can you give us an example code which has problems because of the missing settings. The datadir option in my.ini is in the [mysqld] section and thus to be read by the server, not by the client. It might be used by some utilities that work directly with the data on disk, thus skipping the server. I don't see how LOAD DATA LOCAL INFILE is affected, as the data is on the client side. LOAD DATA is in every way system specific because the MySQL installation specifics may vary. Previous Comments: [2010-01-02 13:51:02] tallyce at gmail dot com In my case, the data files are too big to fit on the C: driver, so placing them in the MySQL subdirectory (under program files) is not an option. So, the "datadir" setting in my.ini is set to be elsewhere. (In the end I used a Windows7 symlink as a workaround, but this feels like a rather unsatisfactory hack.) I don't know which settings are still read by the MySQL server process, but this one at least is ignored by PHP. Either way, it seems odd that one should go through the process of setting up and tuning a MySQL server and then have the key program that reads the data simply ignore the settings, following the release of PHP 5.3.x. [2009-12-29 12:12:45] johan...@php.net Which settings would you actually need to set for the client in my.cnf? - The server will read it's settings anyways. [2009-12-28 19:53:21] tallyce at gmail dot com Description: http://au2.php.net/manual/en/migration53.incompatible.php states that the Mysqlnd driver doesn't read the my.ini file but instead that mysqli_options() should be used to tell PHP about settings. Can I plead the developers to have a mysqlnd.inifile option or similar? This latest change is very regressive: it means that, for instance, if your database files are stored in a non-standard location, e.g. a data rather than OS C: disk (as specified in my.ini), or any other performance-related setting, these all have to be manually added to script files, making them completely non-portable, or editing through third-party apps (making it time-consuming to upgrade). If such an ini option were added, might it just be a case of just parsing the specified file and passing the found values into whatever interface mysqli_options is using? Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit this bug report at http://bugs.php.net/bug.php?id=50595&edit=1
Bug #53171 [Opn->Fbk]: Problem with accented characterers
Edit report at http://bugs.php.net/bug.php?id=53171&edit=1
ID: 53171
Updated by: and...@php.net
Reported by:kesler dot alwin at gmail dot com
Summary:Problem with accented characterers
-Status: Open
+Status: Feedback
Type: Bug
Package:MySQL related
Operating System: Windows XP
PHP Version:5.2SVN-2010-10-26 (snap)
Block user comment: N
Private report: N
New Comment:
Do you get this also with 5.3?
Previous Comments:
[2010-10-26 17:44:30] kesler dot alwin at gmail dot com
Description:
When i use mysql_real_escape_string() with mysql_set_charset() forcing
to use 'latin1' the accented characters dissapear from the insert
string.
SHOW VARIABLES LIKE 'character_set%';
character_set_client latin1
character_set_connection latin1
character_set_databaselatin1
character_set_filesystem binary
character_set_results latin1
character_set_server latin1
character_set_system utf8
PHP info
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
I realize that if i comment the mysql_set_charset() command i have no
problems. anyway, if i try to get the connection character (with or
without this command) i'll always get 'latin1', but i just think that
this commando shouldn't cause problems.. till today i have it trying to
stabilize my framework environment
Test script:
---
# From the very beginning i disable the magic quotes if it's set
ini_set('magic_quotes_gpc', 0);
# I create a connection like this
$link = mysql_connect(SQL_HOST, SQL_USER, SQL_PASS);
mysql_select_db(SQL_INSTANCE, $link);
# Use the "forced" character set for the connection
mysql_set_charset('latin1', $link);
# In my code i have a class that performs all validation according to
the type of content i'm specting... in this case string's validation
Class vaccine
{
public static function forString($value)
{
if($value == null || $value == 'null')
return 'NULL';
return strlen($value)
? '\''. mysql_real_escape_string($value) .'\''
: 'NULL';
}
}
# then if i'm going to insert in db
$query = "INSERT INTO TABLE VALUES(". Vaccine::forString('this text has
accents from here áéÃóú') .")"
--
Edit this bug report at http://bugs.php.net/bug.php?id=53171&edit=1
Bug #53227 [Opn->Fbk]: PHP Warning: mysql_pconnect(): MySQL server has gone away
Edit report at http://bugs.php.net/bug.php?id=53227&edit=1 ID: 53227 Updated by: and...@php.net Reported by:tyra3l at gmail dot com Summary:PHP Warning: mysql_pconnect(): MySQL server has gone away -Status: Open +Status: Feedback Type: Bug Package:MySQL related PHP Version:5.3.3 Block user comment: N Private report: N New Comment: do you use libmysql or mysqlnd? Previous Comments: [2010-11-02 12:13:04] tyra3l at gmail dot com Description: On of my co-worker experienced, that some of the mysql_pconnect calls are returning this error. The exact same symptoms are described in the manual: http://php.net/manual/en/function.mysql-pconnect.php#99380 the code which produce this was working fine before migrating to 5.3 Test script: --- http://bugs.php.net/bug.php?id=53227&edit=1
Req #41459 [Asn->Opn]: [PATCH] PDO::pgsqlGetNotify()
Edit report at http://bugs.php.net/bug.php?id=41459&edit=1 ID: 41459 Updated by: j...@php.net Reported by:spher...@php.net Summary:[PATCH] PDO::pgsqlGetNotify() -Status: Assigned +Status: Open Type: Feature/Change Request -Package:Feature/Change Request +Package:PostgreSQL related Operating System: Mac OS X 10.4.9 PHP Version:5CVS-2007-05-21 (CVS) -Assigned To:edink +Assigned To: Block user comment: N Private report: N Previous Comments: [2007-10-22 08:14:31] spher...@php.net Changed patch address to http://spheroid.fi/tmp/pgsqlGetNotify.diff [2007-05-21 14:46:06] spher...@php.net Description: I read Wez was working on PDO::pgsqlGetNotify(), but since I couldn't find any implementation, I made a crude copy&paste from ext/pgsql. The following patch should do it: http://spheroid.fi/pgsqlGetNotify.diff -- Edit this bug report at http://bugs.php.net/bug.php?id=41459&edit=1
Req #21973 [Asn->Csd]: 'configure' script can't find libpng.(a|so), openldap, libjava...
Edit report at http://bugs.php.net/bug.php?id=21973&edit=1 ID: 21973 Updated by: j...@php.net Reported by:j-devenish at users dot sourceforge dot net Summary:'configure' script can't find libpng.(a|so), openldap, libjava... -Status: Assigned +Status: Closed Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: Solaris 8 PHP Version:4.3.3RC2-dev -Assigned To: +Assigned To:jani Block user comment: N Private report: N New Comment: Use --with-libdir, we hold hands here. ;) Previous Comments: [2003-08-06 09:54:23] sni...@php.net Another 64bit issue found in bug #24950 (oracle) [2003-07-14 06:42:30] j-devenish at users dot sourceforge dot net > I'll look into adding the macro to make the configure > be a bit friendlier. Thank you for looking into this and suggesting something that would let users to work around the brain-dead ./configure design. It will be helpful if the problem and its solution are obvious to people (e.g. if it is possible to generate good error messages). At the time of my original submission, PHP was just using a stupid library detection method. This was with regard to PNG and JPEG support -- which almost all other software (maybe not xpdf -- I can't recall) seems to be able to find by itself. Presumably this is because such software uses the linker to carry out the tests. Perhaps PHP has some new requirement that prevents it from carrying out a conventional test? It would have made more sense if PHP only fell back to its brute-force file matching if a linker test failed. In fact, I think my solution to PHP's behaviour was to delete out a few 'exit' statements -- no actual practical problem existed. I think that it got worse with 4.3.2 because the faulty configuration motif occurred multiple times within ./configure. > Sparc64: > > */lib/sparcv9/ PHP seems to be in an exclusive club of software that requires this extensive hand holding. Problems that are not solved by this workaround: - PHP needs to be taught about every different distro, - PHP needs to be told about each different site. For example, Solaris on UltraSPARC supports multiple ABIs (and presumably Mac OS X and Linux now do, too). A particular *site* may choose to compile PHP for a 32-bit OR a 64-bit ABI (or both, though that is only likely to occur when there are site-specific constraints that require it). Thus PHP can't be shipped with this prior knowledge -- it needs to be told on a site-by-site basis. In my scope of activities, the only other software requiring this much ABI knowledge is that which uses assembly code (e.g. OpenSSL). [2003-07-12 23:12:51] sni...@php.net We can add a new macro to the configure, which is used always for the direct search of a library files. Now the list of common paths are: /usr/local/lib /usr/lib With 64bit linux distros: /usr/lib/lib64/ (not sure if if e.g. /usr/local/lib64 can exist too?) Sparc64: */lib/sparcv9/ I'll look into adding the macro to make the configure be a bit friendlier. :) [2003-01-31 05:28:14] he...@php.net If you want support your environment we would have to change all configure files. We would have to change all lines of the form .../lib/... with ../$LIB_DIR/... and add some configure magic to determine what $LIB_DIR should be (in your case it would be sparcv9). [2003-01-31 03:34:09] j-devenish at users dot sourceforge dot net In response to (1): This makes no difference. I'm not sure if we're on the same planet. I'm not quite sure what the patch was meant to achieve (and thus I don't understand what I was supposed to do to take advantage of it once configure was regenerated). I think the loop that fails to find libpng is indeed the one you've provided the patch for, so you and I are possibly within the same universe. In response to (2): > Since you obviated a system immanent feature... Hey, I'm really confused now. I'm not at all sure what nuance you're implying with those words. I really don't understand why you said it at all. Can I try saying this to you: /usr/local/include/libpng/png.h (for both arch) /usr/local/include/libpng/pngconf.h (for both arch) /usr/local/lib/libpng12.so (32-bit) /usr/local/lib/sparcv9/libpng12.so (64-bit) PHP needs to use the files in /usr/local/include/libpng and /usr/local/lib/sparcv9. The library path is already known by the compiler, linker, and
Req #46240 [Com]: Build in foreach else support
Edit report at http://bugs.php.net/bug.php?id=46240&edit=1
ID: 46240
Comment by: rick dot sketchy at gmail dot com
Reported by:kjarli at gmail dot com
Summary:Build in foreach else support
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *
PHP Version:5.2.6
Block user comment: N
Private report: N
New Comment:
I have to agree with the OP. foreachelse (or something similar) is
really
needed. I do like the suggestion posted by cerlestes at googlemail dot
com:
foreach($arr as $var)
{
doCode();
}
onFail
{
failHandling();
}
A fail handler would prove useful,however I can see it may have some
limitations, in which case an else option on the foreach would be
satisfactory.
Whilst we're at it, it may as well be added to while statements too.
Previous Comments:
[2010-02-13 19:44:15] cerlestes at googlemail dot com
ADDITION:
Why I would like to have this is because of the following situation:
$test = (float)0; // This would be the return of a function.
// Failhandling
if(!$test)
{
doFailhandling();
}else ...
This method has room for misinterpretations.
Ofc, you could test for "$test === false", but I think a general
onFail-handler would be way nicer.
Thanks for reading
[2010-02-13 19:38:00] cerlestes at googlemail dot com
To be honest, I'd like to have a general "onFail{}" handler to put after
every function, not only foreach.
Like:
foreach($arr as $var)
{
doCode();
}
onFail
{
failHandling();
}
or
file("file.txt")
onFail
{
failHandling();
}
Inside of the onFail-brackets a constant __ERROR__ would be available,
with further information on the error.
Basically, that onFail-handler would be executed upon receiving the
constant FAIL from the function before the onFail-command.
Regards
[2009-10-06 08:37:09] ptmcnally at gmail dot com
I agree, this would be a nice addition to PHP6.
[2009-09-07 01:13:01] john at brahy dot com
Please add a foreach else. It would save so much programming time and
eliminate so much room for error. It's so simple... foreach (){} else
{}
PLEASE PLEASE PLEASE PLEASE PLEASE PLEASE
[2008-10-06 08:57:14] kjarli at gmail dot com
Description:
Each time you want to foreach an array, you first have to check with
a count or empty if you want to give a message or w/e to notify there
is no entry to an array (or object if implements like iterator).
If possible add a else option to foreach.
Reproduce code:
---
0) {
foreach($myArray as $key => $value) {
}
}
//new style
foreach($myArray as $key => $value) {
} else {
// empty array/object
}
(kinda like how smarty implements it)
--
Edit this bug report at http://bugs.php.net/bug.php?id=46240&edit=1
Req #19574 [Asn->Csd]: Quoted printable encode
Edit report at http://bugs.php.net/bug.php?id=19574&edit=1 ID: 19574 Updated by: j...@php.net Reported by:fporta at angelfire dot com Summary:Quoted printable encode -Status: Assigned +Status: Closed Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues -Operating System: any +Operating System: * -PHP Version:4.2.2 +PHP Version:* -Assigned To:moriyoshi +Assigned To:tony2001 Block user comment: N Private report: N New Comment: Was added PHP 5.3.0. Previous Comments: [2002-09-24 05:09:22] fporta at angelfire dot com Please add a function quoted_printable_encode(), like imap_8bit() but independent from imap module. Thanks a lot. Francesco Porta -- Edit this bug report at http://bugs.php.net/bug.php?id=19574&edit=1
Bug #53578 [Opn]: php_curl init time (3 big seconds)
Edit report at http://bugs.php.net/bug.php?id=53578&edit=1 ID: 53578 User updated by:tanguy dot pruvot at gmail dot com Reported by:tanguy dot pruvot at gmail dot com Summary:php_curl init time (3 big seconds) Status: Open Type: Bug Package:cURL related Operating System: Win7/Vista x86 PHP Version:5.3.4 (Since 5.2.14/5.3) Block user comment: N Private report: N New Comment: Hmm no, in fact i use mod_fcgid for another CGI... WDScript :) since 2010 http://sourceforge.net/apps/trac/wdscript/attachment/wiki/FastCGI/ProtocoleFastCGI .png PHP was used as apache module, to skip this kind of bug and reduce loading times ;) But i will also try a switch, now mod_fcgid seems stable on Win32 too ;) Previous Comments: [2010-12-20 13:21:41] paj...@php.net If you use fcgid with apache, then you can use VC9 php builds right now, without switching to a VC9 apache. [2010-12-20 13:12:39] tanguy dot pruvot at gmail dot com Yea... i think i will. I was reading that on this site one hour ago ;) i've seen mod_fcgid 2.3.6 and eAccelerator are available on this site... its now time to switch and say goodbye to my VC6 VM :) [2010-12-20 12:57:03] paj...@php.net I will update teh VC6 builds later tonight. However I would recommend to use the VC9 versions instead, VC9 builds of Apache can be found at http://apachelounge.com [2010-12-20 11:34:01] tanguy dot pruvot at gmail dot com Thanks for these precisions. But i use VC6 to use same apache DLLs (on a vista virtual machine to use the "recent" Win32 SDK) Do you know where we can find the fixed lib for VC6 x86 ? I ve used the 7.21.0 available here but i think its the old one : http://pecl2.php.net/downloads/php-windows-builds/php-libs/VC6/x86/ Also, and i dunno why but phpinfo() curl block says libcurl 7.20 instead of 7.21 I need it to fix the problem on my Wamp package EWS (detected one year ago to check version informations) http://ews.wdscript.fr [2010-12-20 11:14:38] paj...@php.net btw, I just applied this change to my tree as well: https://github.com/pierrejoye/curl nmake /f Makefile.vc9 WINDOWS_SSPI=1 USE_IPV6=1 WITH_DEVEL=g:\php-sdk\lib_builds\vc9\x86\deps CFG=release-ssh2-ssl-dll-zlib to build it for PHP's VC9 (with almost all protocols, incl. ssh2). As long as you copied the dependencies in ..\deps (like for php's builds). 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=53578 -- Edit this bug report at http://bugs.php.net/bug.php?id=53578&edit=1
Req #16758 [Asn->Csd]: Configure "Libraries have been installed in" and where they really are
Edit report at http://bugs.php.net/bug.php?id=16758&edit=1 ID: 16758 Updated by: j...@php.net Reported by:PLancashire at Columbia dot com Summary:Configure "Libraries have been installed in" and where they really are -Status: Assigned +Status: Closed Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: Solaris 2.8 PHP Version:4.1.2 -Assigned To: +Assigned To:jani Block user comment: N Private report: N New Comment: This was "fixed" long time ago, the path where shared modules are installed is shown when you do 'make install'. Previous Comments: [2002-04-23 19:12:54] sni...@php.net Reclassified. The configure options to control this and the other stuff installed are not working that well. btw. Update to PHP 4.2.0 first. Then check the --with-layout and --prefix and --libdir options. --Jani [2002-04-23 11:30:31] PLancashire at Columbia dot com configure reports wrong location of where the java.so extension is for updating the LD_LIBRARY_PATH ---Environment Solaris Sparc 2.8 Patchkit as of 5/Apr/2002 Gcc 3.0.3 (Sunfreeware) binutils 2.11.2 (Sunfreeware) GNU Make version 3.79.1 (Sunfreeware) GNU libtool 1.4 (1.920 2001/04/24 23:26:18) (Sunfreeware) java j2sdk1.4.0 Zlib 1.1.4 (source) php 4.1.2 PATH includes /usr/j2sdk1.4.0/bin JAVA_HOME /usr/j2sdk1.4.0 --- ---configure--- ./configure \ --with-apxs=/usr/local/apache/bin/apxs \ --with-config-file-path=/usr/local/apache/httpd/conf \ --without-mysql \ --with-zlib-dir=/usr/local \ --with-zlib=/usr/local \ --with-java=/usr/j2sdk1.4.0 --- --- Libraries have been installed in: /usr/local/build/php4-200204230600/modules If you ever happen to want to link against installed libraries [snip] --- Gives the build (source) directory path not the make install path: /usr/local/lib/php/extensions/no-debug-non-zts-20010901/java.so Also question: How do I change the directory this extension is placed in ? Thanks -pete -- Edit this bug report at http://bugs.php.net/bug.php?id=16758&edit=1
Req #49461 [Opn->Bgs]: parse_ini_file: semicolon in section header
Edit report at http://bugs.php.net/bug.php?id=49461&edit=1
ID: 49461
Updated by: j...@php.net
Reported by:sebastian dot schleussner at angstrom dot uu dot se
Summary:parse_ini_file: semicolon in section header
-Status: Open
+Status: Bogus
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: Linux
PHP Version:5.3.0
Block user comment: N
Private report: N
New Comment:
See the 3rd (optional) parameter to parse_ini_file(), INI_SCANNER_RAW is
used internally for the browscap stuff.
Previous Comments:
[2009-09-09 06:45:14] sebastian dot schleussner at angstrom dot uu dot
se
Just tried the second part of your suggestion, oc3ans. Here's another
inconsistency.
A *key* with an escaped semicolon is *ignored* in PHP 5.2.10.
But in PHP 5.3.0 it causes the parsing to quit silently - it does not
fail as with unescaped semicolons in sections, and returns the lines
before the "malformed" one, but does not read any further.
[2009-09-09 06:30:02] sebastian dot schleussner at angstrom dot uu dot
se
Okay, classification as "bug" may be debatable, and note that I have
made this a "Feature/Change Request".
At the very least, it is an undocumented and irritating change of
functionality.
Next, it is a change that breaks normal parsing of the widely used
browscaps.ini, which PHP's own get_browser still reads flawlessly.
Most importantly, semicolons ARE allowed inside quotes, and I think it
is very logical to interpret the square brackets of section titles as
quoting, too (as pre-5.3 PHP did). There is no legitimate use of a
semicolon *for starting a comment* before the closing square bracket, so
there is no reason to interpret it as such. If one wants to add a
comment on the title line, one can do so after the closing bracket.
As to accepted standards: On the one hand my experience is that there is
a lot of variation in the format of INI files, so a parser should be
reasonably lenient. On the other hand I have never seen backslash
escaping in INI files and I'm not at all sure it is part of any
"accepted standard" for them.
It only works partly anyway, and inconsistently.
Take this file:
;sample3.ini
[a\;b];c
x=y\;z
y="a;b"
z="a\;b"
and run print_r(parse_ini_file("sample3.ini", true));
You get (PHP 5.2.10 and 5.3.0):
Array
(
[a\;b] => Array
(
[x] => y\
[y] => a;b
[z] => a\;b
)
)
No bailout, but (a) the backslash remains inside title and quotes, (b)
the escaping does not work in values. No good, IMHO.
Variable z shows that titles and quoted strings are still considered
equally in terms of backslashes, and x demos that unquoted ;'s are
always filtered, but while the unescaped ; in y is allowed, it's not in
the title in 5.3 -- that's inconsistent and should be reverted.
I rest my case.
[2009-09-09 05:40:48] oc3ans at gmail dot com
According to accepted standards of ini files the semicolon is starting a
comment that lasts till the end of the line, so IMHO this is not a bug,
if you want to include semicolons in the keys or sections you should
escape it with a backslash.
[2009-09-03 20:17:37] sebastian dot schleussner at angstrom dot uu dot
se
Description:
This is a follow-up to Bug #49443.
The character breaking parse_ini_file of PHP 5.3.0 with browscap.ini is
actually the comment character ";" inside section headers - not one of
the special characters.
Reproduce code:
---
;sample1.ini
; demonstration of what works in 5.2 and 5.3
[a(b){c}&~![^]
x=y
;sample2.ini
; demonstration of the problem
[a;b];c
x=y
Code:
-
Expected result:
As in PHP 5.2.10 -- the header's square brackets being interpreted as
quoting:
Array
(
[a(b){c}&~![^] => Array
(
[x] => y
)
)
Array
(
[a;b] => Array
(
[x] => y
)
)
Actual result:
--
Array
(
[a(b){c}&~![^] => Array
(
[x] => y
)
)
PHP Warning: syntax error, unexpected $end, expecting ']' in
sample2.ini on line 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=49461&edit=1
Bug #53578 [Opn]: php_curl init time (3 big seconds)
Edit report at http://bugs.php.net/bug.php?id=53578&edit=1 ID: 53578 Updated by: paj...@php.net Reported by:tanguy dot pruvot at gmail dot com Summary:php_curl init time (3 big seconds) Status: Open Type: Bug Package:cURL related Operating System: Win7/Vista x86 PHP Version:5.3.4 (Since 5.2.14/5.3) Block user comment: N Private report: N New Comment: If you use fcgid with apache, then you can use VC9 php builds right now, without switching to a VC9 apache. Previous Comments: [2010-12-20 13:12:39] tanguy dot pruvot at gmail dot com Yea... i think i will. I was reading that on this site one hour ago ;) i've seen mod_fcgid 2.3.6 and eAccelerator are available on this site... its now time to switch and say goodbye to my VC6 VM :) [2010-12-20 12:57:03] paj...@php.net I will update teh VC6 builds later tonight. However I would recommend to use the VC9 versions instead, VC9 builds of Apache can be found at http://apachelounge.com [2010-12-20 11:34:01] tanguy dot pruvot at gmail dot com Thanks for these precisions. But i use VC6 to use same apache DLLs (on a vista virtual machine to use the "recent" Win32 SDK) Do you know where we can find the fixed lib for VC6 x86 ? I ve used the 7.21.0 available here but i think its the old one : http://pecl2.php.net/downloads/php-windows-builds/php-libs/VC6/x86/ Also, and i dunno why but phpinfo() curl block says libcurl 7.20 instead of 7.21 I need it to fix the problem on my Wamp package EWS (detected one year ago to check version informations) http://ews.wdscript.fr [2010-12-20 11:14:38] paj...@php.net btw, I just applied this change to my tree as well: https://github.com/pierrejoye/curl nmake /f Makefile.vc9 WINDOWS_SSPI=1 USE_IPV6=1 WITH_DEVEL=g:\php-sdk\lib_builds\vc9\x86\deps CFG=release-ssh2-ssl-dll-zlib to build it for PHP's VC9 (with almost all protocols, incl. ssh2). As long as you copied the dependencies in ..\deps (like for php's builds). [2010-12-20 10:42:34] paj...@php.net As I said, the libcurl previous release (for our build only) has been modified to do not call this function anymore. The latest libcurl release should have the fix too. 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=53578 -- Edit this bug report at http://bugs.php.net/bug.php?id=53578&edit=1
Bug #53578 [Opn]: php_curl init time (3 big seconds)
Edit report at http://bugs.php.net/bug.php?id=53578&edit=1 ID: 53578 User updated by:tanguy dot pruvot at gmail dot com Reported by:tanguy dot pruvot at gmail dot com Summary:php_curl init time (3 big seconds) Status: Open Type: Bug Package:cURL related Operating System: Win7/Vista x86 PHP Version:5.3.4 (Since 5.2.14/5.3) Block user comment: N Private report: N New Comment: Yea... i think i will. I was reading that on this site one hour ago ;) i've seen mod_fcgid 2.3.6 and eAccelerator are available on this site... its now time to switch and say goodbye to my VC6 VM :) Previous Comments: [2010-12-20 12:57:03] paj...@php.net I will update teh VC6 builds later tonight. However I would recommend to use the VC9 versions instead, VC9 builds of Apache can be found at http://apachelounge.com [2010-12-20 11:34:01] tanguy dot pruvot at gmail dot com Thanks for these precisions. But i use VC6 to use same apache DLLs (on a vista virtual machine to use the "recent" Win32 SDK) Do you know where we can find the fixed lib for VC6 x86 ? I ve used the 7.21.0 available here but i think its the old one : http://pecl2.php.net/downloads/php-windows-builds/php-libs/VC6/x86/ Also, and i dunno why but phpinfo() curl block says libcurl 7.20 instead of 7.21 I need it to fix the problem on my Wamp package EWS (detected one year ago to check version informations) http://ews.wdscript.fr [2010-12-20 11:14:38] paj...@php.net btw, I just applied this change to my tree as well: https://github.com/pierrejoye/curl nmake /f Makefile.vc9 WINDOWS_SSPI=1 USE_IPV6=1 WITH_DEVEL=g:\php-sdk\lib_builds\vc9\x86\deps CFG=release-ssh2-ssl-dll-zlib to build it for PHP's VC9 (with almost all protocols, incl. ssh2). As long as you copied the dependencies in ..\deps (like for php's builds). [2010-12-20 10:42:34] paj...@php.net As I said, the libcurl previous release (for our build only) has been modified to do not call this function anymore. The latest libcurl release should have the fix too. [2010-12-20 10:12:20] tanguy dot pruvot at gmail dot com Just to confirm : I tried all 5.3.4 and 5.2.16 versions (TS/NTS VC6/VC9), even a self compiled one from sources and the problem always appears on Vista and Seven x86 I posted a bug report to curl team... but i cant find RAND_screen() call in their lastest release... 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=53578 -- Edit this bug report at http://bugs.php.net/bug.php?id=53578&edit=1
Bug #53513 [Opn->Fbk]: PHP 5.3.4 does not copy pear, peardev and pecl binaries into place.
Edit report at http://bugs.php.net/bug.php?id=53513&edit=1 ID: 53513 Updated by: j...@php.net Reported by:thepixeldeveloper at googlemail dot com Summary:PHP 5.3.4 does not copy pear, peardev and pecl binaries into place. -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: Ubuntu 10.10 maverick PHP Version:5.3.4 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ The configure line you provided worked just fine for me and I did get pear/pecl/etc. as expected.. Previous Comments: [2010-12-10 05:27:03] thepixeldeveloper at googlemail dot com Description: PHP 5.3.4 does not put pear, peardev and pecl binaries into the bin directory. ./configure script log - https://gist.github.com/ff52ad3603b7d6999d02 make log - https://gist.github.com/98565ae779cc9f3b5866 make install log - https://gist.github.com/0c7f4078a9e1df11c628 Test script: --- ./configure --prefix=/opt/php-5.3.4 --with-openssl --with-mcrypt --with-mysqli --with-mysql=mysqlnd --with-mysql-sock --with-gd --with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr --with-freetype-dir=/usr --with-tidy --with-curl --enable-fpm --enable-gd-native-ttf --enable-gd-jis-conv --enable-mbstring --disable-xmlreader --disable-xmlwriter --disable-phar --without-sqlite --without-sqlite3 --disable-pdo --disable-posix --with-pear=/opt/php-5.3.4/pear --with-pdo-mysql --enable-pdo --without-pdo-sqlite --enable-pcntl Expected result: [mat...@thepixeldeveloper php-5.3.4]$ ls /opt/php-5.3.3/bin/ pear peardev pecl php php-config phpize Actual result: -- [mat...@thepixeldeveloper php-5.3.4]$ ls /opt/php-5.3.4/bin/ php php-config phpize -- Edit this bug report at http://bugs.php.net/bug.php?id=53513&edit=1
Req #53348 [Fbk->Bgs]: building with apxs can fail when compiler doesn't match apr library
Edit report at http://bugs.php.net/bug.php?id=53348&edit=1 ID: 53348 Updated by: j...@php.net Reported by:mike at harschsystems dot com Summary:building with apxs can fail when compiler doesn't match apr library -Status: Feedback +Status: Bogus Type: Feature/Change Request Package:Compile Failure Operating System: Solaris and others PHP Version:trunk-SVN-2010-11-18 (SVN) Block user comment: N Private report: N New Comment: See above. Previous Comments: [2010-11-23 22:23:49] srina...@php.net this should be a bug within solaris and not within php because solaris build process should not expose the compiler flags within apxs. please raise a bug within solaris. right way place to do this would be defect.opensolaris.org would recommend closing this bug as not a valid bug. [2010-11-19 00:25:04] mike at harschsystems dot com Description: The build system uses the apr-1-config command to retrieve flags from the apr library to use for building shared object targets (e.g. sapi/apache2handler/config.m4). If however, the compiler used to build the apr library was different (and supports different flags) than your current compiler, you may end up with incompatible compiler flags in your Makefile for these targets. This problem manifests itself in Solaris when trying to build php using gcc, while trying to use the binary version of apache shipped with your distribution (which was compiled with sun's forte compiler 'cc'). The first symptom from the user's perspective is the following compile failure: mkdir sapi/apache2handler/.libs cc -DSSL_EXPERIMENTAL -DSSL_ENGINE -I/usr/apache2/2.2/include -DSOLARIS2=11 - D_POSIX_PTHREAD_SEMANTICS -mt -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 - I/usr/apr/1.3/include -I/usr/apr-util/1.3/include - I/wd/builds/sfw/proto/root_i386/usr/include -Isapi/apache2handler/ - I/var/tmp/php-trunk/sapi/apache2handler/ -DPHP_ATOM_INC -I/var/tmp/php- trunk/include -I/var/tmp/php-trunk/main -I/var/tmp/php-trunk -I/var/tmp/php- trunk/ext/date/lib -I/var/tmp/php-trunk/ext/ereg/regex -I/usr/include/libxml2 - I/usr/X11/include -I/usr/include/freetype2 -I/var/tmp/php- trunk/ext/mbstring/oniguruma -I/var/tmp/php-trunk/ext/mbstring/libmbfl - I/var/tmp/php-trunk/ext/mbstring/libmbfl/mbfl -I/var/tmp/php- trunk/ext/sqlite3/libsqlite -I/usr/include/tidy -I/var/tmp/php-trunk/TSRM - I/var/tmp/php-trunk/Zend -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -g -O0 -Wall -c /var/tmp/php-trunk/sapi/apache2handler/mod_php5.c -fPIC -DPIC -o sapi/apache2handler/.libs/mod_php5.o cc1: error: invalid option `t' make: *** [sapi/apache2handler/mod_php5.lo] Error 1 The error is coming from the "-mt" flag, which gcc doesn't understand. It turns out, "-mt" is a valid sun forte 'cc' flag. Where did this come from? Looking at sapi/apache2handler/config.m4, we see the build system asking apr for cpp flags like this: $ apxs -q APR_CONFIG /usr/apr/1.3/bin/apr-1-config $ apr-1-config --cppflags --includes -DSOLARIS2=11 -D_POSIX_PTHREAD_SEMANTICS -mt -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -I/usr/apr/1.3/include Asking apr about compiler it's built with shows the problem (it's not gcc): $ apr-1-config --cc cc -m32 In this case, some googling revealed that "-mt" is equivalent to "-D_REENTRANT", so manually replacing these flags in the Makefile works around the problem. It would be nice if the build system did a check to see if `APR_CONFIG --cc` matches the current compiler - and warns you if there is a mismatch. Also, it would be nice to have an override switch to specify the flags to use manually, rather than deriving them from apr. Test script: --- This problem is reproducible on solaris when trying to compile php with gcc, and using --with-apxs2 pointing to an apache binary built with sun's cc rather than gcc (as is the case if using the ips packages available for opensolaris, etc). -- Edit this bug report at http://bugs.php.net/bug.php?id=53348&edit=1
Bug #53578 [Opn]: php_curl init time (3 big seconds)
Edit report at http://bugs.php.net/bug.php?id=53578&edit=1 ID: 53578 Updated by: paj...@php.net Reported by:tanguy dot pruvot at gmail dot com Summary:php_curl init time (3 big seconds) Status: Open Type: Bug Package:cURL related Operating System: Win7/Vista x86 PHP Version:5.3.4 (Since 5.2.14/5.3) Block user comment: N Private report: N New Comment: I will update teh VC6 builds later tonight. However I would recommend to use the VC9 versions instead, VC9 builds of Apache can be found at http://apachelounge.com Previous Comments: [2010-12-20 11:34:01] tanguy dot pruvot at gmail dot com Thanks for these precisions. But i use VC6 to use same apache DLLs (on a vista virtual machine to use the "recent" Win32 SDK) Do you know where we can find the fixed lib for VC6 x86 ? I ve used the 7.21.0 available here but i think its the old one : http://pecl2.php.net/downloads/php-windows-builds/php-libs/VC6/x86/ Also, and i dunno why but phpinfo() curl block says libcurl 7.20 instead of 7.21 I need it to fix the problem on my Wamp package EWS (detected one year ago to check version informations) http://ews.wdscript.fr [2010-12-20 11:14:38] paj...@php.net btw, I just applied this change to my tree as well: https://github.com/pierrejoye/curl nmake /f Makefile.vc9 WINDOWS_SSPI=1 USE_IPV6=1 WITH_DEVEL=g:\php-sdk\lib_builds\vc9\x86\deps CFG=release-ssh2-ssl-dll-zlib to build it for PHP's VC9 (with almost all protocols, incl. ssh2). As long as you copied the dependencies in ..\deps (like for php's builds). [2010-12-20 10:42:34] paj...@php.net As I said, the libcurl previous release (for our build only) has been modified to do not call this function anymore. The latest libcurl release should have the fix too. [2010-12-20 10:12:20] tanguy dot pruvot at gmail dot com Just to confirm : I tried all 5.3.4 and 5.2.16 versions (TS/NTS VC6/VC9), even a self compiled one from sources and the problem always appears on Vista and Seven x86 I posted a bug report to curl team... but i cant find RAND_screen() call in their lastest release... [2010-12-20 07:43:47] tanguy dot pruvot at gmail dot com Ok, hmm after a night of debug, i think the code is in the static libcurl_a.lib i've tried to build a module with standard libcurl dlls (php_curl of 64k) but seems to have a bad address for the curl_global_init() call I think we need to follow this issue to curl team :p 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=53578 -- Edit this bug report at http://bugs.php.net/bug.php?id=53578&edit=1
Bug #52191 [Com]: any PHP version above 5.3.0 causes Apache above 2.2.11 to die on start
Edit report at http://bugs.php.net/bug.php?id=52191&edit=1 ID: 52191 Comment by: pxjianke at hotmail dot com Reported by:therealloonylion at yahoo dot co dot uk Summary:any PHP version above 5.3.0 causes Apache above 2.2.11 to die on start Status: Bogus Type: Bug Package:Reproducible crash Operating System: Windows XP/2003 PHP Version:5.3.2 Block user comment: N Private report: N New Comment: only copies php5ts.dll to WINDOWS/system32,then reset apache.so it is ok. Previous Comments: [2010-07-07 10:43:20] paj...@php.net Duplicate of #51298 [2010-07-07 04:47:02] lj0425 at gmail dot com It's still NW on PHP 5.3.2 + Apache 2.2.15 + XP professional SP3 if comment out PHPIniDir "C:/PHP/" -> #PHPIniDir "C:/PHP/" in httpd.conf ,Apache start. [2010-06-27 13:22:17] therealloonylion at yahoo dot co dot uk The only information in the backtraces that I didn't paste was: Type of Analysis Performed Crash Analysis Machine Name SARABI Operating System Windows XP Service Pack 3 Number Of Processors 2 Process ID 516 Process Image C:\Program Files\Apache Software Foundation\Apache2.2\bin\httpd.exe System Up-Time 05:46:54 Process Up-Time 00:00:03 There's an entry point in the backtraces (already pasted) but nothing about main() [2010-06-26 23:17:19] ka...@php.net Hi, your backtrace doesn't seem to include all of it, like the application entry point at main(), is there any chance you can get those remaining trace bits? [2010-06-26 19:13:37] therealloonylion at yahoo dot co dot uk It seems to no longer occur with PHP 5.3.2 although it did last time I tried it (a month or so ago) and when it first was released (tested on Apache 2.2.13 and 2.2.14 at the time). It still occurs with 5.3.1, however, so I have attached backtraces from tests with that version and the following version matrix: Apache 2.2.11 2.2.13 2.2.14 2.2.15 PHP 5.3.0W W W W 5.3.1NWNW NW NW 5.3.2W W W W W = working NW = not working Apache 2.2.11: apache log: [Sat Jun 26 15:43:39 2010] [notice] Child 5332: All worker threads have exited. [Sat Jun 26 15:43:39 2010] [notice] Child 5332: Child process is exiting [Sat Jun 26 15:44:23 2010] [crit] (OS 6)The handle is invalid. : master_main: create child process failed. Exiting. [Sat Jun 26 15:44:23 2010] [notice] Parent: Forcing termination of child process 36 backtrace: Thread 0 - System ID 1208 Entry point httpd+1ecf Create time 26/06/2010 15:55:10 Time spent in user mode 0 Days 0:0:0.46 Time spent in kernel mode 0 Days 0:0:0.203 Function Arg 1 Arg 2 Arg 3 Source php5ts!php_date_get_timezone_ce+39c 0134 7c90d99a 7c810f63 kernel32!CreateFileA+30 0003 0134 0x8000` 77c61aa0 0006facc 77c2c16e msvcrt!_unlock+15 0004 77c2c215 005bbc80 msvcrt!calloc+ab 0020 00ca6924 php5ts!zend_error+498 77c47660 77c47660 0020 php5ts!spprintf+19 0020 00ca68d4 012b2288 php5ts!php_verror+554 PHP5TS!PHP_DATE_GET_TIMEZONE_CE+39CWARNING - DebugDiag was not able to locate debug symbols for php5ts.dll, so the information below may be incomplete. In httpd__PID__3272__Date__06_26_2010__Time_03_55_46PM__671__Second_Chance_Exception_C005.dmp the assembly instruction at php5ts!php_date_get_timezone_ce+39c in W:\PHP\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x0045 on thread 0 Module Information Image Name: W:\PHP\php5ts.dll Symbol Type: Export Base address: 0x0097 Time Stamp: Thu Nov 19 10:17:25 2009 Checksum: 0x Comments: COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Script Interpreter ISAPIFilter: False File Version: 5.3.1 Managed DLL: False Internal Name: PHP Script Interpreter VB DLL: False Legal Copyright: Copyright © 1997-2009 The PHP Group Loaded Image Name: php5ts.dll Legal Trademarks: PHP Mapped Image Name: W:\PHP\php5ts.dll Original filename: php5ts.dll Module name: php5ts Private Build: Single Threaded: False Product Name: PHP Module Size: 5.45 MBytes Product Version: 5.3.1 Symbol File Name: php5ts.
Bug #53579 [Asn->Csd]: stream_get_contents() segfaults on ziparchive streams
Edit report at http://bugs.php.net/bug.php?id=53579&edit=1
ID: 53579
Updated by: bj...@php.net
Reported by:paulgao at yeah dot net
-Summary:stream_get_contents failed
+Summary:stream_get_contents() segfaults on ziparchive
streams
-Status: Assigned
+Status: Closed
Type: Bug
Package:Zip Related
Operating System: irrelevant
PHP Version:5.3.4
Assigned To:bjori
Block user comment: N
Private report: 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-12-20 12:00:29] bj...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revision&revision=306493
Log: Fixed bug#53579 (stream_get_contents() segfaults on ziparchive
streams)
Also added the filename being access to the stream_get_meta_data() array
[2010-12-20 07:05:57] paulgao at yeah dot net
trunk code is same.
[2010-12-20 06:58:22] paulgao at yeah dot net
Description:
Segmentation fault
backtrace:
(gdb) bt
#0 0x003510e79320 in strchr () from /lib64/libc.so.6
#1 0x0065a23c in php_zip_ops_stat (stream=, ssb=0x7fff6bb223e0) at /root/php-5.3.4/ext/zip/zip_stream.c:111
#2 0x006c22c5 in _php_stream_copy_to_mem (src=0xd2d6038,
buf=0x7fff6bb224c8, maxlen=35, persistent=0) at
/root/php-5.3.4/main/streams/streams.c:1275
#3 0x0063019e in zif_stream_get_contents (ht=, return_value=0xd2d5f08, return_value_ptr=,
this_ptr=, return_value_used=)
at /root/php-5.3.4/ext/standard/streamsfuncs.c:443
#4 0x0064506c in suhosin_execute_internal
(execute_data_ptr=0x2ac667a0b050, return_value_used=1) at
/root/php-5.3.4/ext/suhosin/execute.c:1673
#5 0x00746475 in zend_do_fcall_common_helper_SPEC
(execute_data=0x2ac667a0b050) at
/root/php-5.3.4/Zend/zend_vm_execute.h:318
#6 0x0071e15c in execute (op_array=0xd2d43c8) at
/root/php-5.3.4/Zend/zend_vm_execute.h:107
#7 0x006455b9 in suhosin_execute_ex (op_array=0xd2d43c8, zo=0,
dummy=0) at /root/php-5.3.4/ext/suhosin/execute.c:585
#8 0x006fb95d in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.3.4/Zend/zend.c:1194
#9 0x006ab9cd in php_execute_script
(primary_file=0x7fff6bb24d70) at /root/php-5.3.4/main/main.c:2265
#10 0x007803ac in main (argc=2, argv=0x7fff6bb24fe8) at
/root/php-5.3.4/sapi/cli/php_cli.c:1193
Test script:
---
open('test.jar') !== TRUE)
{
return FALSE;
}
if ($za->statName($target_file) !== FALSE)
{
$fd = $za->getStream($target_file);
}
else
{
$fd = FALSE;
}
$za->close();
if (is_resource($fd))
{
echo strlen(stream_get_contents($fd));
}
?>
Expected result:
273
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/bug.php?id=53579&edit=1
Bug #53578 [Opn]: php_curl init time (3 big seconds)
Edit report at http://bugs.php.net/bug.php?id=53578&edit=1 ID: 53578 User updated by:tanguy dot pruvot at gmail dot com Reported by:tanguy dot pruvot at gmail dot com Summary:php_curl init time (3 big seconds) Status: Open Type: Bug Package:cURL related Operating System: Win7/Vista x86 PHP Version:5.3.4 (Since 5.2.14/5.3) Block user comment: N Private report: N New Comment: Thanks for these precisions. But i use VC6 to use same apache DLLs (on a vista virtual machine to use the "recent" Win32 SDK) Do you know where we can find the fixed lib for VC6 x86 ? I ve used the 7.21.0 available here but i think its the old one : http://pecl2.php.net/downloads/php-windows-builds/php-libs/VC6/x86/ Also, and i dunno why but phpinfo() curl block says libcurl 7.20 instead of 7.21 I need it to fix the problem on my Wamp package EWS (detected one year ago to check version informations) http://ews.wdscript.fr Previous Comments: [2010-12-20 11:14:38] paj...@php.net btw, I just applied this change to my tree as well: https://github.com/pierrejoye/curl nmake /f Makefile.vc9 WINDOWS_SSPI=1 USE_IPV6=1 WITH_DEVEL=g:\php-sdk\lib_builds\vc9\x86\deps CFG=release-ssh2-ssl-dll-zlib to build it for PHP's VC9 (with almost all protocols, incl. ssh2). As long as you copied the dependencies in ..\deps (like for php's builds). [2010-12-20 10:42:34] paj...@php.net As I said, the libcurl previous release (for our build only) has been modified to do not call this function anymore. The latest libcurl release should have the fix too. [2010-12-20 10:12:20] tanguy dot pruvot at gmail dot com Just to confirm : I tried all 5.3.4 and 5.2.16 versions (TS/NTS VC6/VC9), even a self compiled one from sources and the problem always appears on Vista and Seven x86 I posted a bug report to curl team... but i cant find RAND_screen() call in their lastest release... [2010-12-20 07:43:47] tanguy dot pruvot at gmail dot com Ok, hmm after a night of debug, i think the code is in the static libcurl_a.lib i've tried to build a module with standard libcurl dlls (php_curl of 64k) but seems to have a bad address for the curl_global_init() call I think we need to follow this issue to curl team :p [2010-12-20 04:03:25] tanguy dot pruvot at gmail dot com If you want to try the difference, here is the patched php_curl dll. http://tanguy.wdscript.fr/files/php_curl.534vc6ts.Patched.zip I'm now compiling php with openssl comment... to check if its the cause of the problem... i dont understand why this code is in php_curl dll code... 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=53578 -- Edit this bug report at http://bugs.php.net/bug.php?id=53578&edit=1
Bug #53578 [Opn]: php_curl init time (3 big seconds)
Edit report at http://bugs.php.net/bug.php?id=53578&edit=1 ID: 53578 Updated by: paj...@php.net Reported by:tanguy dot pruvot at gmail dot com Summary:php_curl init time (3 big seconds) Status: Open Type: Bug Package:cURL related Operating System: Win7/Vista x86 PHP Version:5.3.4 (Since 5.2.14/5.3) Block user comment: N Private report: N New Comment: btw, I just applied this change to my tree as well: https://github.com/pierrejoye/curl nmake /f Makefile.vc9 WINDOWS_SSPI=1 USE_IPV6=1 WITH_DEVEL=g:\php-sdk\lib_builds\vc9\x86\deps CFG=release-ssh2-ssl-dll-zlib to build it for PHP's VC9 (with almost all protocols, incl. ssh2). As long as you copied the dependencies in ..\deps (like for php's builds). Previous Comments: [2010-12-20 10:42:34] paj...@php.net As I said, the libcurl previous release (for our build only) has been modified to do not call this function anymore. The latest libcurl release should have the fix too. [2010-12-20 10:12:20] tanguy dot pruvot at gmail dot com Just to confirm : I tried all 5.3.4 and 5.2.16 versions (TS/NTS VC6/VC9), even a self compiled one from sources and the problem always appears on Vista and Seven x86 I posted a bug report to curl team... but i cant find RAND_screen() call in their lastest release... [2010-12-20 07:43:47] tanguy dot pruvot at gmail dot com Ok, hmm after a night of debug, i think the code is in the static libcurl_a.lib i've tried to build a module with standard libcurl dlls (php_curl of 64k) but seems to have a bad address for the curl_global_init() call I think we need to follow this issue to curl team :p [2010-12-20 04:03:25] tanguy dot pruvot at gmail dot com If you want to try the difference, here is the patched php_curl dll. http://tanguy.wdscript.fr/files/php_curl.534vc6ts.Patched.zip I'm now compiling php with openssl comment... to check if its the cause of the problem... i dont understand why this code is in php_curl dll code... [2010-12-20 02:34:29] tanguy dot pruvot at gmail dot com Here is an asm dump of lib_curl.dll 5.3.4 VC6 TS where RAND_screen is used : 0035DB10 > \E8 FF360100 call 0035DB15 . E8 F4360100 call 0035DB1A . 85C0 testeax, eax ; kernel32.BaseThreadInitThunk 0035DB1C . 75 01 jnz short php_curl.0035DB1F 0035DB1E . C3ret 0035DB1F > E8 E4360100 call 0035DB24 . E8 D9360100 call 0035DB29 . B8 0100 mov eax, 1 0035DB2E . C3ret A simple replace of E8 D9360100 by 90 90909090 will fix the problem... but maybe a call to the regular rand() function could be needed elsewhere... 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=53578 -- Edit this bug report at http://bugs.php.net/bug.php?id=53578&edit=1
Bug #53578 [Opn]: php_curl init time (3 big seconds)
Edit report at http://bugs.php.net/bug.php?id=53578&edit=1 ID: 53578 Updated by: paj...@php.net Reported by:tanguy dot pruvot at gmail dot com Summary:php_curl init time (3 big seconds) Status: Open Type: Bug Package:cURL related Operating System: Win7/Vista x86 PHP Version:5.3.4 (Since 5.2.14/5.3) Block user comment: N Private report: N New Comment: As I said, the libcurl previous release (for our build only) has been modified to do not call this function anymore. The latest libcurl release should have the fix too. Previous Comments: [2010-12-20 10:12:20] tanguy dot pruvot at gmail dot com Just to confirm : I tried all 5.3.4 and 5.2.16 versions (TS/NTS VC6/VC9), even a self compiled one from sources and the problem always appears on Vista and Seven x86 I posted a bug report to curl team... but i cant find RAND_screen() call in their lastest release... [2010-12-20 07:43:47] tanguy dot pruvot at gmail dot com Ok, hmm after a night of debug, i think the code is in the static libcurl_a.lib i've tried to build a module with standard libcurl dlls (php_curl of 64k) but seems to have a bad address for the curl_global_init() call I think we need to follow this issue to curl team :p [2010-12-20 04:03:25] tanguy dot pruvot at gmail dot com If you want to try the difference, here is the patched php_curl dll. http://tanguy.wdscript.fr/files/php_curl.534vc6ts.Patched.zip I'm now compiling php with openssl comment... to check if its the cause of the problem... i dont understand why this code is in php_curl dll code... [2010-12-20 02:34:29] tanguy dot pruvot at gmail dot com Here is an asm dump of lib_curl.dll 5.3.4 VC6 TS where RAND_screen is used : 0035DB10 > \E8 FF360100 call 0035DB15 . E8 F4360100 call 0035DB1A . 85C0 testeax, eax ; kernel32.BaseThreadInitThunk 0035DB1C . 75 01 jnz short php_curl.0035DB1F 0035DB1E . C3ret 0035DB1F > E8 E4360100 call 0035DB24 . E8 D9360100 call 0035DB29 . B8 0100 mov eax, 1 0035DB2E . C3ret A simple replace of E8 D9360100 by 90 90909090 will fix the problem... but maybe a call to the regular rand() function could be needed elsewhere... [2010-12-20 02:07:57] tanguy dot pruvot at gmail dot com I'm using the 5.3.4-VC6-TS version (as Apache 2.2 module) 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=53578 -- Edit this bug report at http://bugs.php.net/bug.php?id=53578&edit=1
Bug #53579 [Opn->Asn]: stream_get_contents failed
Edit report at http://bugs.php.net/bug.php?id=53579&edit=1
ID: 53579
Updated by: bj...@php.net
Reported by:paulgao at yeah dot net
Summary:stream_get_contents failed
-Status: Open
+Status: Assigned
Type: Bug
Package:Zip Related
Operating System: irrelevant
PHP Version:5.3.4
-Assigned To:
+Assigned To:bjori
Block user comment: N
Private report: N
Previous Comments:
[2010-12-20 07:05:57] paulgao at yeah dot net
trunk code is same.
[2010-12-20 06:58:22] paulgao at yeah dot net
Description:
Segmentation fault
backtrace:
(gdb) bt
#0 0x003510e79320 in strchr () from /lib64/libc.so.6
#1 0x0065a23c in php_zip_ops_stat (stream=, ssb=0x7fff6bb223e0) at /root/php-5.3.4/ext/zip/zip_stream.c:111
#2 0x006c22c5 in _php_stream_copy_to_mem (src=0xd2d6038,
buf=0x7fff6bb224c8, maxlen=35, persistent=0) at
/root/php-5.3.4/main/streams/streams.c:1275
#3 0x0063019e in zif_stream_get_contents (ht=, return_value=0xd2d5f08, return_value_ptr=,
this_ptr=, return_value_used=)
at /root/php-5.3.4/ext/standard/streamsfuncs.c:443
#4 0x0064506c in suhosin_execute_internal
(execute_data_ptr=0x2ac667a0b050, return_value_used=1) at
/root/php-5.3.4/ext/suhosin/execute.c:1673
#5 0x00746475 in zend_do_fcall_common_helper_SPEC
(execute_data=0x2ac667a0b050) at
/root/php-5.3.4/Zend/zend_vm_execute.h:318
#6 0x0071e15c in execute (op_array=0xd2d43c8) at
/root/php-5.3.4/Zend/zend_vm_execute.h:107
#7 0x006455b9 in suhosin_execute_ex (op_array=0xd2d43c8, zo=0,
dummy=0) at /root/php-5.3.4/ext/suhosin/execute.c:585
#8 0x006fb95d in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.3.4/Zend/zend.c:1194
#9 0x006ab9cd in php_execute_script
(primary_file=0x7fff6bb24d70) at /root/php-5.3.4/main/main.c:2265
#10 0x007803ac in main (argc=2, argv=0x7fff6bb24fe8) at
/root/php-5.3.4/sapi/cli/php_cli.c:1193
Test script:
---
open('test.jar') !== TRUE)
{
return FALSE;
}
if ($za->statName($target_file) !== FALSE)
{
$fd = $za->getStream($target_file);
}
else
{
$fd = FALSE;
}
$za->close();
if (is_resource($fd))
{
echo strlen(stream_get_contents($fd));
}
?>
Expected result:
273
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/bug.php?id=53579&edit=1
Bug #53578 [Opn]: php_curl init time (3 big seconds)
Edit report at http://bugs.php.net/bug.php?id=53578&edit=1 ID: 53578 User updated by:tanguy dot pruvot at gmail dot com Reported by:tanguy dot pruvot at gmail dot com Summary:php_curl init time (3 big seconds) Status: Open Type: Bug Package:cURL related -Operating System: Win7 x86 +Operating System: Win7/Vista x86 PHP Version:5.3.4 (Since 5.2.14/5.3) Block user comment: N Private report: N New Comment: Just to confirm : I tried all 5.3.4 and 5.2.16 versions (TS/NTS VC6/VC9), even a self compiled one from sources and the problem always appears on Vista and Seven x86 I posted a bug report to curl team... but i cant find RAND_screen() call in their lastest release... Previous Comments: [2010-12-20 07:43:47] tanguy dot pruvot at gmail dot com Ok, hmm after a night of debug, i think the code is in the static libcurl_a.lib i've tried to build a module with standard libcurl dlls (php_curl of 64k) but seems to have a bad address for the curl_global_init() call I think we need to follow this issue to curl team :p [2010-12-20 04:03:25] tanguy dot pruvot at gmail dot com If you want to try the difference, here is the patched php_curl dll. http://tanguy.wdscript.fr/files/php_curl.534vc6ts.Patched.zip I'm now compiling php with openssl comment... to check if its the cause of the problem... i dont understand why this code is in php_curl dll code... [2010-12-20 02:34:29] tanguy dot pruvot at gmail dot com Here is an asm dump of lib_curl.dll 5.3.4 VC6 TS where RAND_screen is used : 0035DB10 > \E8 FF360100 call 0035DB15 . E8 F4360100 call 0035DB1A . 85C0 testeax, eax ; kernel32.BaseThreadInitThunk 0035DB1C . 75 01 jnz short php_curl.0035DB1F 0035DB1E . C3ret 0035DB1F > E8 E4360100 call 0035DB24 . E8 D9360100 call 0035DB29 . B8 0100 mov eax, 1 0035DB2E . C3ret A simple replace of E8 D9360100 by 90 90909090 will fix the problem... but maybe a call to the regular rand() function could be needed elsewhere... [2010-12-20 02:07:57] tanguy dot pruvot at gmail dot com I'm using the 5.3.4-VC6-TS version (as Apache 2.2 module) [2010-12-20 02:06:17] tanguy dot pruvot at gmail dot com Please comment this line to fix the problem : php-5.3.4\ext\openssl\openssl.c PHP_FUNCTION(openssl_random_pseudo_bytes) line 4898 : #ifdef WINDOWS RAND_screen(); #endif 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=53578 -- Edit this bug report at http://bugs.php.net/bug.php?id=53578&edit=1
[PHP-BUG] Bug #53580 [NEW]: During resize gdImageCopyResampled cause colors change
From: Operating system: Windows, Ubuntu, CentOS, any? PHP version: 5.2.16 Package: GD related Bug Type: Bug Bug description:During resize gdImageCopyResampled cause colors change Description: Reproduce: To test resize image containing solid white background. After resize pixels with color different from #FF will appear. Probable cause: gdImageSetPixel parameters (red, green, blue, alpha) are casted to int in gdImageCopyResampled which cause them to floor so 254.999 became 254 instead of 255. Issues seem to be related: http://bugs.php.net/bug.php?id=30591 http://bugs.php.net/bug.php?id=41820 -- Edit bug report at http://bugs.php.net/bug.php?id=53580&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53580&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53580&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53580&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53580&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53580&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53580&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53580&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53580&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53580&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53580&r=support Expected behavior: http://bugs.php.net/fix.php?id=53580&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53580&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53580&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53580&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53580&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53580&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53580&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53580&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53580&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53580&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53580&r=mysqlcfg
Req #49654 [Opn->Fbk]: there is no Operator define in class
Edit report at http://bugs.php.net/bug.php?id=49654&edit=1 ID: 49654 Updated by: j...@php.net Reported by:msd dot mazarei at gmail dot com Summary:there is no Operator define in class -Status: Open +Status: Feedback Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: * PHP Version:5.3.0 Block user comment: N Private report: N New Comment: Example? As in: What are you requesting here? Operator overloading? Or what? Previous Comments: [2009-09-24 10:35:37] msd dot mazarei at gmail dot com Description: in classes sometimes we need to define special operator, like dates or money or any thing else , but in PHP we can not define Operator for a class , and i think this is an important thing. -- Edit this bug report at http://bugs.php.net/bug.php?id=49654&edit=1
Req #50083 [Opn->Wfx]: Bit shift
Edit report at http://bugs.php.net/bug.php?id=50083&edit=1 ID: 50083 Updated by: j...@php.net Reported by:talk at apfeldot dot de Summary:Bit shift -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: Win 7 PHP Version:5.3.0 Block user comment: N Private report: N New Comment: http://www.php.net/manual/en/language.operators.bitwise.php There's big warning with note: "Use functions from the gmp extension for bitwise manipulation on numbers beyond PHP_INT_MAX." Previous Comments: [2009-11-04 23:27:47] talk at apfeldot dot de Description: I think there is an integer overflow, which should be prevented. Reproduce code: --- Expected result: There should be int(0), because the 1 was shifted out of the integer representation and the binary code should be 0...0. Actual result: -- int(2) Binary represantation: 00...0010 -- Edit this bug report at http://bugs.php.net/bug.php?id=50083&edit=1
