Bug #51347 [Opn-Fbk]: mysqli_close / connection memory leak
Edit report at http://bugs.php.net/bug.php?id=51347edit=1 ID: 51347 Updated by: johan...@php.net Reported by: mat999 at gmail dot com Summary: mysqli_close / connection memory leak -Status: Open +Status: Feedback Type: Bug Package: MySQLi related Operating System: Debian Lenny / Linux PHP Version: 5.3.2 Assigned To: mysql New Comment: Keeping it on Feedback till there was actual feedback. Previous Comments: [2010-04-15 13:01:42] mat999 at gmail dot com ok on the weekend Ill remake my build environment and see what I can do. [2010-04-15 12:50:54] and...@php.net Can you try with 5.3.3-dev. I am sure I fixed this. Not a real leak, more like streams were freeing memory too late. Please try a snapshot from snaps.php.net [2010-04-06 07:38:40] mat999 at gmail dot com Gee, no responses on a proven bug... Heres valgrind info, sorry no debug symbols for php5-mysql [...] ==49959== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 52 from 4) --49959-- --49959-- supp: 22 dl-hack4-64bit-addr-1 --49959-- supp: 2 dl-hack3-cond-2 --49959-- supp: 27 dl-hack3-cond-1 --49959-- supp: 1 dl-hack4-64bit-addr-2 ==49959== malloc/free: in use at exit: 6,394 bytes in 22 blocks. ==49959== malloc/free: 31,095 allocs, 31,073 frees, 4,718,692 bytes allocated. ==49959== ==49959== searching for pointers to 22 not-freed blocks. ==49959== checked 1,626,688 bytes. ==49959== ==49959== 5 bytes in 1 blocks are indirectly lost in loss record 1 of 11 ==49959==at 0x4C2260E: malloc (vg_replace_malloc.c:207) ==49959==by 0x9161D71: strdup (in /lib/libc-2.7.so) ==49959==by 0x91A0036: (within /lib/libc-2.7.so) ==49959==by 0x91A1F78: getaddrinfo (in /lib/libc-2.7.so) ==49959==by 0xA5C017E: ??? ==49959==by 0xA5C030D: ??? ==49959==by 0xA5C0488: ??? ==49959==by 0xA5C04A9: ??? ==49959==by 0xA5C7D96: ??? ==49959==by 0xA38C5FC: ??? ==49959==by 0x74A6CA: zend_startup_module_ex (in /usr/bin/php5) ==49959==by 0x752E3A: zend_hash_apply (in /usr/bin/php5) ==49959== ==49959== ==49959== 12 bytes in 1 blocks are still reachable in loss record 2 of 11 ==49959==at 0x4C2260E: malloc (vg_replace_malloc.c:207) ==49959==by 0x9161D71: strdup (in /lib/libc-2.7.so) ==49959==by 0x555354: zm_startup_intl (in /usr/bin/php5) ==49959==by 0x74A6CA: zend_startup_module_ex (in /usr/bin/php5) ==49959==by 0x752E3A: zend_hash_apply (in /usr/bin/php5) ==49959==by 0x74DC29: zend_startup_modules (in /usr/bin/php5) ==49959==by 0x6F1399: php_module_startup (in /usr/bin/php5) ==49959==by 0x7D7B4C: php_cli_startup (in /usr/bin/php5) ==49959==by 0x7D850F: main (in /usr/bin/php5) ==49959== ==49959== ==49959== 12 bytes in 1 blocks are still reachable in loss record 3 of 11 ==49959==at 0x4C2260E: malloc (vg_replace_malloc.c:207) ==49959==by 0x777588D: uprv_getDefaultLocaleID_3_8 (in /usr/lib/libicuuc.so.38.1) ==49959==by 0x77AC129: (within /usr/lib/libicuuc.so.38.1) ==49959==by 0x77AC2AE: icu_3_8::Locale::getDefault() (in /usr/lib/libicuuc.so.38.1) ==49959==by 0x77AD7C8: (within /usr/lib/libicuuc.so.38.1) ==49959==by 0x55534C: zm_startup_intl (in /usr/bin/php5) ==49959==by 0x74A6CA: zend_startup_module_ex (in /usr/bin/php5) ==49959==by 0x752E3A: zend_hash_apply (in /usr/bin/php5) ==49959==by 0x74DC29: zend_startup_modules (in /usr/bin/php5) ==49959==by 0x6F1399: php_module_startup (in /usr/bin/php5) ==49959==by 0x7D7B4C: php_cli_startup (in /usr/bin/php5) ==49959==by 0x7D850F: main (in /usr/bin/php5) ==49959== ==49959== ==49959== 32 bytes in 1 blocks are still reachable in loss record 4 of 11 ==49959==at 0x4C203E4: calloc (vg_replace_malloc.c:397) ==49959==by 0x66C73DF: (within /lib/libdl-2.7.so) ==49959==by 0x66C6F20: dlopen (in /lib/libdl-2.7.so) ==49959==by 0x752274: zend_load_extension (in /usr/bin/php5) ==49959==by 0x73D30D: zend_llist_apply (in /usr/bin/php5) ==49959==by 0x6F8226: php_ini_register_extensions (in /usr/bin/php5) ==49959==by 0x6F1394: php_module_startup (in /usr/bin/php5) ==49959==by 0x7D7B4C: php_cli_startup (in /usr/bin/php5) ==49959==by 0x7D850F: main (in /usr/bin/php5) ==49959== ==49959== ==49959== 53 bytes in 2 blocks are definitely lost in loss record 5 of 11 ==49959==at 0x4C2260E: malloc (vg_replace_malloc.c:207) ==49959==by 0xA5BF317: ??? ==49959==by 0xA5C0269: ??? ==49959==by 0xA5C030D: ??? ==49959==by 0xA5C0488: ??? ==49959==by 0xA5C04A9: ??? ==49959==by 0xA5C7D96: ??? ==49959==by 0xA38C5FC: ??? ==49959==by 0x74A6CA: zend_startup_module_ex (in
Bug #50583 [Asn]: PHP Installer needs to support side by side installlation of 5.2 and 5.3 version
Edit report at http://bugs.php.net/bug.php?id=50583edit=1 ID: 50583 Updated by: paj...@php.net Reported by: ksingla at microsoft dot com Summary: PHP Installer needs to support side by side installlation of 5.2 and 5.3 version Status: Assigned Type: Bug Package: Windows Installer Operating System: Windows PHP Version: 5.3.1 -Assigned To: jmertic +Assigned To: pajoye New Comment: This plan can only partially work for what we described and need. That's not what we can or will implement. Taking the hand over that one. I will discuss with John about the possible solutions and get them into our roadmap. Previous Comments: [2010-04-15 20:47:37] rusl...@php.net The proposed plan for enabling this is described below: 1. Choose different upgrade codes for PHP 5.2, PHP 5.3 and PHP 6.0 2. Use folder php52, php53 or php60 under %programfiles% for copying files instead of fixed one %programfiles%\php. 3. Use different registry paths for different versions. 4. Do not set PHPRC environment variable at system level. This is required to make different versions of PHP pick different php.ini in a SxS environment for non-FastCGI SAPI's. This request is tracked by a separate bug: http://bugs.php.net/bug.php?id=51536. 5. Add detection mechanism to detect if other versions are installed. If so, show a warning message telling people to uninstall and then install if they don't want SxS install. Also say that php.ini configuration of other version won't be picked when SxS is happening. [2010-03-25 18:53:48] jmer...@php.net Currently assessing whether we can do this across all SAPIs or not. [2010-01-21 21:21:15] ruslany at microsoft dot com In addition to that it would be nice if PHP installer allowed user to choose whether to upgrade an existing PHP installation or install a new version side by side. For example, on the very first page of the installer there can be options presented: 1. Upgrade existing installation 2. Install side-by-side and make this a default version 3. Install side-by-side but keep existing version as a default. In case of installing on IIS that would mean: In #1 the installer will upgrade the PHP installation as it does today. In #2 the installer will install binaries into a new folder and then configure FastCGI handler mapping on a server level and make it the top in the handler mapping list so that it is used by all sites. In #3 the installer will install binaries into a new folder, configure FastCGI handler mapping, but will not re-order the existing FastCGI handler mapping so that previosly installed PHP vesion is still used. [2009-12-26 23:28:17] ksingla at microsoft dot com Description: In order to support side-by-side installation of PHP 5.2 and 5.3 by Microsoft Web Platform Installer, PHP installer needs to support side by side setup. To get to a version specific installation, I think following changes will be required a. Currently, PHP is installed to %PROGRAMFILES(X86)%\PHP or %PROGRAMFILES%\PHP. This should change to %PROGRAMFILES(X86)%\PHP\version or %PROGRAMFILES%\PHP\version b. Currently PHP sets the following registry keys: i. HKLM\SOFTWARE\Wow6432Node\PHP on 64-bit systems. ii. HKLM\SOFTWARE\PHP on 32-bit systemsc. Change the registry keys to: i. HKLM\SOFTWARE\Wow6432Node\PHP\version on 64-bit systems. ii. HKLM\SOFTWARE\PHP on 32-bit systems\versiond. Set an environment variable called PHPLOC with the path to the latest installed PHP c. When IIS-FastCGI install is selected, installer should let users add the PHP handler at site or application level as well so that a particular PHP version can be used for that site or application. Currently the handler is always added at the server level. -- Edit this bug report at http://bugs.php.net/bug.php?id=50583edit=1
Bug #49764 [NoF-Asn]: number_format() fails (randomly?)
Edit report at http://bugs.php.net/bug.php?id=49764edit=1 ID: 49764 Updated by: paj...@php.net Reported by: tec at baufi24 dot de Summary: number_format() fails (randomly?) -Status: No Feedback +Status: Assigned Type: Bug Package: Math related Operating System: Windows Server 2003 RC2 PHP Version: 5.2.11 -Assigned To: +Assigned To: pajoye New Comment: I will ask our test team to try to reproduce it. Previous Comments: [2010-04-15 20:24:54] derek dot ethier at humber dot ca I've been experiencing a similar problem on 5.2.12 and 5.2.13 on a Windows Server 2003 environment (not R2). I haven't been able to nail down any sort of specifics as it happens so randomly. The only consistent element seems to centre around odd numbers (specifically with 9) format incorrectly in a similar manner to the one originally described (with a colon in the middle). I'm not sure if this helps at all, but I thought I'd add a comment anyway. [2009-12-21 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-12-13 18:13:29] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-10-12 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-10-04 18:03:36] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49764 -- Edit this bug report at http://bugs.php.net/bug.php?id=49764edit=1
Bug #51566 [Bgs]: __set() is called twice for each assignment operation and overwrites values
Edit report at http://bugs.php.net/bug.php?id=51566edit=1
ID: 51566
User updated by: link at dtalbert dot com
Reported by: link at dtalbert dot com
Summary: __set() is called twice for each assignment operation
and overwrites values
Status: Bogus
Type: Bug
Package: Class/Object related
Operating System: CentOS
PHP Version: 5.2.13
New Comment:
Thank you for the prompt reply. Your solution was, of course, correct.
My fault entirely, thanks for helping move on.
Previous Comments:
[2010-04-16 00:05:59] ras...@php.net
You are doing that to yourself. You meant to do:
$tmp = $this-$key;
$tmp['value'] = $value;
Otherwise it is going to do the $key['value'] part first which ends up
being the
same as $key[0] where $key = 'privVarName' so index 0 of that string is
going to
be 'p'.
[2010-04-15 23:56:37] link at dtalbert dot com
Description:
my PHP version is actually 5.2.6
I have overloaded the __set() and __get() functions in one of my classes
and put logging statements around some test assignment lines. Here's an
abbreviated version of that class:
class MyClass {
private privVarName = array('value' = null);
public function __set($key, $value) {
$this-$key['value'] = $value;
}
public function __get($key) {
return $this-$key['value'];
}
}
When I execute a line like:
$instanceOfMyClass-privVarName = 17;
My log will show me that the __set() function was called twice; once
with the name privVarName, and again with the name p. It is always
the first letter of the variable name and it is always set to the same
value as I gave to the full variable name.
Additionally, if I add another line like:
$instanceOfMyClass-plarg = 4;
then __set is again called twice (for plarg and for p) and the value
of $instanceOfMyClass-privVarName becomes 4. When I read the values for
each member var back from the class they are set to whatever the last
variable name with the same first letter was set to. Also, it does the
same double calling and overwriting for variables that are not declared
in the class file.
The double calling and overwriting of same-first-letter variable names
does not happen if I change my __set() and __get() functions to not use
arrays, as in the following:
public function __set($key, $value) {
$this-$key = $value;
}
public function __get($key) {
return $this-$key;
}
but of course this doesn't do what I need. If I needed this behavior I
would just declare my member variables to be public and not overload the
__set() and __get() at all.
Expected result:
I expect it to call __set() only once.
I expect that setting 2 different member variables to different values
will not affect each other.
Actual result:
--
__set() is called twice for every assignment statement executed, the
second time with the variable name being just the first letter of the
actual variable name.
all member variables with the same first letter in their names are
overwritten by subsequent calls to __set()
--
Edit this bug report at http://bugs.php.net/bug.php?id=51566edit=1
[PHP-BUG] Bug #51570 [NEW]: is_subclass_of fails to autoload the classes
From:
Operating system: Debian
PHP version: 5.2.13
Package: Reproducible crash
Bug Type: Bug
Bug description:is_subclass_of fails to autoload the classes
Description:
is_subclass_of fails to autoload the classes causing PHP do die and apache
returns an empty page. NO error is triggered ! It was very hard to find the
cause
My php config it's here:
http://alex.softdev.ro/info.php
Failing function:
function ClassIsA($object_class, $class)
{
if ($object_class == $class)
return true;
return (is_subclass_of($object_class, $class));
}
If changed it works:
function ClassIsA($object_class, $class)
{
// use this to force the load of the classes
if (!class_exists($object_class))
throw new Exception(Class $object_class not found);
// use this to force the load of the classes
if (!class_exists($class))
throw new Exception(Class $class not found);
if ($object_class == $class)
return true;
return (is_subclass_of($object_class, $class));
}
looks like calling class_exists calls autoload and works fine
Thanks,
Alex
Test script:
---
Failing function:
function ClassIsA($object_class, $class)
{
if ($object_class == $class)
return true;
return (is_subclass_of($object_class, $class));
}
If changed it works:
function ClassIsA($object_class, $class)
{
// use this to force the load of the classes
if (!class_exists($object_class))
throw new Exception(Class $object_class not found);
// use this to force the load of the classes
if (!class_exists($class))
throw new Exception(Class $class not found);
if ($object_class == $class)
return true;
return (is_subclass_of($object_class, $class));
}
--
Edit bug report at http://bugs.php.net/bug.php?id=51570edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51570r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51570r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51570r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51570r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51570r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51570r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51570r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51570r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51570r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51570r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51570r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51570r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51570r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51570r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51570r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51570r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51570r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51570r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51570r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51570r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51570r=mysqlcfg
[PHP-BUG] Bug #51571 [NEW]: Problems with character spacing in imagettftext/imagefttext
From: Operating system: SUSE Ent. Linux v9 SP4 64bit PHP version: 5.2.13 Package: GD related Bug Type: Bug Bug description:Problems with character spacing in imagettftext/imagefttext Description: Our dev server was recently upgraded to PHP v5.2.13. With that upgrade we have found that our png images are having kerning/tracking/spacing problems. We've tried numerous fonts and haven't found a good solution yet. imagettftextwithtracking - http://www.php.net/manual/en/function.imagettfbbox.php#51373 - is helping some but still isn't as nice as the old version of PHP was. We are creating images using the GD library and writing text to the images using font files and the imagettftext() or imagefttext() functions. I'm including examples of the new and old tahoma bold. Other fonts (bold and non-bold) have the same problem. Some letters and numbers seem like they're off-center or something like that. Thanks!! Test script: --- ImageTTFText($imFinalImage,13,0,$x,$y, $black,/fonts/tahomabd.ttf,$titleText); //I stripped that down some (taking out vars so you had the basic info) //but that's the format along with our font size font. Expected result: The usual text old PHP v5.2.11 (the words are slightly different because this is our dev server and the other one is the live server) http://yfrog.com/i3goodlp Actual result: -- Messy text new PHP http://yfrog.com/i3badej -- Edit bug report at http://bugs.php.net/bug.php?id=51571edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51571r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51571r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51571r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51571r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51571r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51571r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51571r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51571r=needscript Try newer version: http://bugs.php.net/fix.php?id=51571r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51571r=support Expected behavior: http://bugs.php.net/fix.php?id=51571r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51571r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51571r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51571r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51571r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51571r=dst IIS Stability: http://bugs.php.net/fix.php?id=51571r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51571r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51571r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51571r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51571r=mysqlcfg
[PHP-BUG] Bug #51572 [NEW]: Broscap crash on shutdown
From: Operating system: Linux PHP version: 5.3.2 Package: Reproducible crash Bug Type: Bug Bug description:Broscap crash on shutdown Description: I am running pgp-cgi in fast cgi mode and when I shutdown the server with killall php-cgi it crashes. Below is the backtrace, I am not sure how to reproduce exactly but I only use get_browser once per request and it always crashes killing after it has been running for a while. Test script: --- ?php $b = get_browser(); Expected result: Shutdown gracefully Actual result: -- #0 0x7fed7590ba75 in *__GI_raise (sig=value optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x7fed7590f5c0 in *__GI_abort () at abort.c:92 #2 0x7fed759454fb in __libc_message (do_abort=value optimized out, fmt=value optimized out) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #3 0x7fed7594f5b6 in malloc_printerr (action=3, str=0x7fed75a1e2e2 corrupted double-linked list, ptr=value optimized out) at malloc.c:6264 #4 0x7fed75952a25 in _int_free (av=0x7fed75c55e40, p=0x1671ec0) at malloc.c:4954 #5 0x7fed75955e53 in *__GI___libc_free (mem=value optimized out) at malloc.c:3738 #6 0x00692c58 in browscap_entry_dtor (zvalue=0x1670c48) at /usr/src/php-5.3.2/ext/standard/browscap.c:41 #7 0x00750750 in zend_hash_destroy (ht=0xebdcc0) at /usr/src/php- 5.3.2/Zend/zend_hash.c:526 #8 0x00692bfb in zm_shutdown_browscap (type=value optimized out, module_number=value optimized out) at /usr/src/php- 5.3.2/ext/standard/browscap.c:236 #9 0x0068fc65 in zm_shutdown_basic (type=1, module_number=32) at /usr/src/php-5.3.2/ext/standard/basic_functions.c:3685 #10 0x0074a56f in module_destructor (module=0x1170bf0) at /usr/src/php- 5.3.2/Zend/zend_API.c:2098 #11 0x007503e2 in zend_hash_apply_deleter (ht=0xec4f40, p=0x1170b90) at /usr/src/php-5.3.2/Zend/zend_hash.c:611 #12 0x00750698 in zend_hash_graceful_reverse_destroy (ht=0xec4f40) at /usr/src/php-5.3.2/Zend/zend_hash.c:646 #13 0x00744d18 in zend_shutdown () at /usr/src/php-5.3.2/Zend/zend.c:759 #14 0x006f097d in php_module_shutdown () at /usr/src/php- 5.3.2/main/main.c:2138 #15 0x007cc9e5 in main (argc=1, argv=0x7fffab6ce008) at /usr/src/php- 5.3.2/sapi/cgi/cgi_main.c:2231 -- Edit bug report at http://bugs.php.net/bug.php?id=51572edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51572r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51572r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51572r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51572r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51572r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51572r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51572r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51572r=needscript Try newer version: http://bugs.php.net/fix.php?id=51572r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51572r=support Expected behavior: http://bugs.php.net/fix.php?id=51572r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51572r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51572r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51572r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51572r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51572r=dst IIS Stability: http://bugs.php.net/fix.php?id=51572r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51572r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51572r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51572r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51572r=mysqlcfg
Bug #51571 [Opn-Fbk]: Problems with character spacing in imagettftext/imagefttext
Edit report at http://bugs.php.net/bug.php?id=51571edit=1 ID: 51571 Updated by: paj...@php.net Reported by: leottan at imsweb dot com Summary: Problems with character spacing in imagettftext/imagefttext -Status: Open +Status: Feedback Type: Bug Package: GD related Operating System: SUSE Ent. Linux v9 SP4 64bit PHP Version: 5.2.13 New Comment: Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2010-04-16 17:01:15] leottan at imsweb dot com Description: Our dev server was recently upgraded to PHP v5.2.13. With that upgrade we have found that our png images are having kerning/tracking/spacing problems. We've tried numerous fonts and haven't found a good solution yet. imagettftextwithtracking - http://www.php.net/manual/en/function.imagettfbbox.php#51373 - is helping some but still isn't as nice as the old version of PHP was. We are creating images using the GD library and writing text to the images using font files and the imagettftext() or imagefttext() functions. I'm including examples of the new and old tahoma bold. Other fonts (bold and non-bold) have the same problem. Some letters and numbers seem like they're off-center or something like that. Thanks!! Test script: --- ImageTTFText($imFinalImage,13,0,$x,$y, $black,/fonts/tahomabd.ttf,$titleText); //I stripped that down some (taking out vars so you had the basic info) //but that's the format along with our font size font. Expected result: The usual text old PHP v5.2.11 (the words are slightly different because this is our dev server and the other one is the live server) http://yfrog.com/i3goodlp Actual result: -- Messy text new PHP http://yfrog.com/i3badej -- Edit this bug report at http://bugs.php.net/bug.php?id=51571edit=1
[PHP-BUG] Bug #51573 [NEW]: ctype_alpha function
From:
Operating system: Windows XP
PHP version: 5.2.13
Package: Strings related
Bug Type: Bug
Bug description:ctype_alpha function
Description:
I ran a test of numbers from -1000 to 1000. I passed the values into
'ctype_alpha', which I expected ALL output to be Failure::xx. However, I
receive Success::xx output on a variety of numbers from -125 to 255.
Test script:
---
for ($x = -1000;$x 1000;$x++) {
echo ((ctype_alpha ($x)) ? Success::{$x} : Failure::{$x}) .
PHP_EOL;
}
Expected result:
I expect to see nothing but Failure::{xx} all the way down.
--
Edit bug report at http://bugs.php.net/bug.php?id=51573edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51573r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51573r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51573r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51573r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51573r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51573r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51573r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51573r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51573r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51573r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51573r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51573r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51573r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51573r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51573r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51573r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51573r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51573r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51573r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51573r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51573r=mysqlcfg
[PHP-BUG] Req #51574 [NEW]: Modify range() function to support A to ZZZZ
From:
Operating system:
PHP version: Irrelevant
Package: Arrays related
Bug Type: Feature/Change Request
Bug description:Modify range() function to support A to
Description:
This is a low low low priority feature request, but it would be nice if the
range() function supported letters beyond just A to Z.
For example:
echo count(range('A',''));
returns 26, but in many other languages once you get to Z it continues to
AA
For example in perl:
perl -e '$_=()=A..;print'
you get 475254
Test script:
---
$a = count(range('A',''));
if ($a == 475254 ) {
echo 'RANGE IS WORKING!'
} else {
echo 'RANGE STOPS AT Z. Foo. '
}
Expected result:
RANGE IS WORKING!
Actual result:
--
RANGE STOPS AT Z. Foo.
--
Edit bug report at http://bugs.php.net/bug.php?id=51574edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51574r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51574r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51574r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51574r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51574r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51574r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51574r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51574r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51574r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51574r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51574r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51574r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51574r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51574r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51574r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51574r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51574r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51574r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51574r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51574r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51574r=mysqlcfg
Bug #51316 [Com]: Undefined first referenced symbol in file mysql_set_character_set ext/mysql/.li
Edit report at http://bugs.php.net/bug.php?id=51316edit=1 ID: 51316 Comment by: progmanpaul at gmail dot com Reported by: andressucer at gmail dot com Summary: Undefined first referenced symbol in file mysql_set_character_set ext/mysql/.li Status: Open Type: Bug Package: Compile Failure Operating System: Solaris PHP Version: 5.3.2 New Comment: If you omit --with-openssl then the GD Lib portion fails because it requires libssl - FYI. Previous Comments: [2010-03-31 03:33:40] gene at neckosoft dot com I have the same problem. Here's my configure options: ./configure --prefix=/apps/local/phpdev --with-curl=/apps/local/curl --with-openssl=/apps/local/openssl \ --with-mysql=/apps/local/mysql-5.1.45-solaris10-sparc --with-apxs2=/usr/apache2/bin/apxs -âwith-readline=/opt/sfw and here's the error I am getting: Undefined first referenced symbol in file mysql_set_character_set ext/mysql/.libs/php_mysql.o ld: fatal: Symbol referencing errors. No output written to sapi/cli/php collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `sapi/cli/php' [2010-03-21 20:48:09] hholz...@php.net Does this also happen when not using -with-openssl ? Seems to be similar to http://www.phpfreaks.com/forums/index.php?topic=170577.0 [2010-03-17 22:15:59] andressucer at gmail dot com Description: Estoy intentando compilar php con mysql de la siguiente forma: tar -xvf php-5.3.2.tar cd php-5.3.2 export PATH=/usr/local/ssl/bin/:/aplicaciones/mysql5136/bin:/aplicaciones/mysql5136/:/l ib/:/usr/local/:/aplicaciones/libxml2- 2.6.31/:/aplicaciones/zlib/lib/:/usr/local/lib/:/usr/ccs/bin/:/usr/sfw/bin/:/usr /sbin/:/usr/bin/:/bin/:/sbin/:/usr/local/bin/:/opt/csw/bin/:/usr/sfw/bin/:/usr/s fw/lib:/usr/lib/:/usr/local/include/:/opt/sfw/lib/:/usr/local/lib/ export LD_LIBRARY_PATH=/usr/local/ssl/lib/:/aplicaciones/mysql5136/lib/:/aplicaciones/m ysql5136/:/lib/:/usr/local/:/aplicaciones/libxml2- 2.6.31/:/aplicaciones/zlib/lib/:/usr/local/lib/:/usr/ccs/bin/:/usr/sfw/bin/:/usr /sbin/:/usr/bin/:/bin/:/sbin/:/usr/local/bin/:/opt/csw/bin/:/usr/sfw/bin/:/usr/s fw/lib:/usr/lib/:/usr/local/include/:/opt/sfw/lib/:/usr/local/lib/ ./configure --prefix=/aplicaciones/phpPrueba --with- apxs2=/aplicaciones/apachePrueba/bin/apxs --with-pgsql=/aplicaciones/pgsql843 -- enable-ftp --enable-mbstring --with-gd=/aplicaciones/gd-2.0.35 --with-jpeg- dir=/aplicaciones/jpeg-6b --with-zlib=/aplicaciones/zlib --with- curl=/aplicaciones/curl --with-config-file-path=/aplicaciones/phpPrueba --with- freetype-dir=/aplicaciones/freetype-2.3.1 --with-openssl=/usr/local/ssl -- enable-soap --with-mysql=/aplicaciones/mysql5136/ --with-readline --enable- sockets make pero me presenta el siguiente error: Undefined first referenced symbol in file mysql_set_character_set ext/mysql/.libs/php_mysql.o mysql_set_server_option ext/mysql/.libs/php_mysql.o ld: fatal: Symbol referencing errors. No output written to sapi/cli/php collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `sapi/cli/php' si elimino la opcion --with-mysql=/aplicaciones/mysql5136/ compila sin problema, pero no me sirve porque necesito el mysql -- Edit this bug report at http://bugs.php.net/bug.php?id=51316edit=1
[PHP-BUG] Bug #51575 [NEW]: S modifier causes preg_match to behave incorrectly
From:
Operating system:
PHP version: 5.2.13
Package: PCRE related
Bug Type: Bug
Bug description:S modifier causes preg_match to behave incorrectly
Description:
With some UTF-8 letters of Cyrillic block preg_match behaves incorrectly
with S
modifier.
Test script:
---
?=(preg_match('#Ф#uiS', 'Ñ') == preg_match('#Ф#ui', 'Ñ')) ? passed :
failed?
Expected result:
passed
Actual result:
--
failed
--
Edit bug report at http://bugs.php.net/bug.php?id=51575edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51575r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51575r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51575r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51575r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51575r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51575r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51575r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51575r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51575r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51575r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51575r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51575r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51575r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51575r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51575r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51575r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51575r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51575r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51575r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51575r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51575r=mysqlcfg
Bug #35050 [Com]: Capital I letters in func/class method names do not work with turkish locale
Edit report at http://bugs.php.net/bug.php?id=35050edit=1
ID: 35050
Comment by: sweiss at stylesight dot com
Reported by: satanistlav at mail dot ru
Summary: Capital I letters in func/class method names do not
work with turkish locale
Status: Wont fix
Type: Bug
Package: Scripting Engine problem
Operating System: Linux
PHP Version: 5CVS-2005-11-01 (cvs)
New Comment:
Requesting a fix for this... this has been going on for almost 5 years,
yet the
proper fix for the problem also only takes that many lines of code,
according to
a different bug report, which was rejected on a technicality. The
workaround
suggested means that none of my turkish is capitalized correctly. This
is
really not going over well. Please, please, please, at least make the
fix
listed in Bug #35050 an option that we can set in the php.ini or ideally
with
ini_set or *something*, if it causes problems for other programmers, and
if it
doesn't, can it just be fixed already? It is not going to be pretty
when I have
to go tell them that the turkish translation they've made is going to be
permanently crippled until PHP 6 is released, and our code is updated to
support
it... and it looks like PHP 6 just went back to square one so this could
be
quite a long time.
Previous Comments:
[2007-09-06 11:22:42] j...@php.net
Patch by Tomas Kuliavas:
http://www.topolis.lt/php/#35050
[2005-11-15 13:39:07] der...@php.net
We discussed it and this will not be addressed in PHP 5, but only from
PHP 6 and higher. Please make sure your set the correct locale before
starting the script - or before including files that define elements
that contain upper case I's.
[2005-11-01 15:17:54] satanistlav at mail dot ru
I have uploaded your code to the server and I still have the same error!
http://www.yda.com.tr/test.php
[2005-11-01 15:14:14] satanistlav at mail dot ru
I have multilingual site. Locales are set to en_US.ISO-8859-1 in Enlgish
side of the site and tr_TR.ISO-8859-9 in Turkish for LC_ALL
[2005-11-01 15:12:29] der...@php.net
I can reproduce this with the following short script:
?php
class foo
{
function IsHere()
{
echo here\n;
}
}
echo setlocale(LC_ALL, 'tr_TR'), \n;
$f = new foo();
$f-IsHere();
?
(You need to have the tr_TR locale installed for this).
It does work properly with PHP 5.1 actually, and it has to to with the
zend_str_tolower() function which uses the tolower() libc call, which
uses the locale. As in Turkish the I does not lowercase to i you can get
weird things. This is why we should get rid of case insensitive function
names.
It also works with normal function names (instead of classes' methods)
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=35050
--
Edit this bug report at http://bugs.php.net/bug.php?id=35050edit=1
Bug #50623 [Com]: odbc_field_name
Edit report at http://bugs.php.net/bug.php?id=50623edit=1
ID: 50623
Comment by: rony_tobins at hotmail dot com
Reported by: bpelletier at alct dot ca
Summary: odbc_field_name
Status: Open
Type: Bug
Package: ODBC related
Operating System: Windows XP Pro
PHP Version: 5.3.1
New Comment:
why not bump up char name[32]; to char name[256]; in
php_odbc_includes.h?
Previous Comments:
[2009-12-31 14:42:09] bpelletier at alct dot ca
Description:
I use odbc_connect to connect to my sql server 2005.
When I want a column where the field name longer than 31 characters,
odbc_result cuts the name to 31 characters.
I really need to know how to overrite the struct to have the
possibilities to have at least 64 characters.
Thanks for you help.
I see many bugs reporting the same but no solution are proposes.
Reproduce code:
---
$requete= SELECT * FROM Usagers WHERE NomUsager = ' . $p_nomUsager .
';;
$resultat= ExecuterRequete($requete);
ProchainEnregistrement($resultat);
for ($i=1; $i odbc_num_fields($resultat) + 1; $i++)
echo odbc_field_name($resultat, $i). - ;
function ExecuterRequete($p_requete)
{
return odbc_exec($_SESSION['BDConnection'], $p_requete);
}
function ProchainEnregistrement($p_resultat)
{
return odbc_fetch_row($p_resultat);
}
Expected result:
I want the full name of the fields.
Actual result:
--
NomUsager - NoEmployeALCT - UsagerActif - DerniereLangueUtiliseUsager -
MotDePasseUsager - AccesProgrammeGestionALCT -
AccesProgrammeInternational - AccesProgrammeFacturation -
AccesGestionALCTConsulterEmploy - AccesGestionALCTAjouterEmploye -
AccesGestionALCTModifierEmploye - AccesGestionALCTSupprimerEmploy -
AccesGestionALCTConsulterRappor - AccesInternationalConsulterClie -
AccesInternationalAjouterClient - AccesInternationalModifierClien -
AccesInternationalSupprimerClie - AccesInternationalConsulterCont -
AccesInternationalAjouterContac - AccesInternationalModifierConta -
AccesInternationalSupprimerCont - AccesInternationalConsulterProd -
AccesInternationalAjouterProdui - AccesInternationalModifierProdu -
AccesInternationalSupprimerProd - AccesInternationalConsulterCour -
AccesInternationalAjouterCourti - AccesInternationalModifierCourt -
AccesInternationalSupprimerCour - AccesInternationalConsulterComp -
AccesInternationalAjouterCompte - AccesInternationalModifierCompt -
AccesInternationalSupprimerComp - AccesInternationalConsulterTran -
AccesInternationalAjouterTransp - AccesInternationalModifierTrans -
AccesInternationalSupprimerTran - AccesInternationalConsulterCont -
AccesInternationalAjouterContac - AccesInternationalModifierConta -
AccesInternationalSupprimerCont - AccesInternationalConsulterProv -
AccesInternationalAjouterProvin - AccesInternationalModifierProvi -
AccesInternationalSupprimerProv - AccesInternationalConsulterRapp -
AccesInternationalConsulterSoum - AccesInternationalAjouterSoumis -
AccesInternationalModifierSoumi - AccesInternationalSupprimerSoum -
AccesInternationalConsulterDema - AccesInternationalAjouterDemand -
AccesInternationalModifierDeman - AccesInternationalSupprimerDema -
AccesInternationalReviserDemand - AccesConfiguration - UsagerAjoutPar -
UsagerDateAjout - UsagerDerniereMiseAJourPar - UsagerDerniereMiseAJour
-
Warning: odbc_result() [function.odbc-result]: Field
AccesGestionALCTSupprimerEmploye not found in
C:\wamp\www\FIK_CE\Fonctions_PHP\Utilitaires.php on line 79
Warning: odbc_result() [function.odbc-result]: Field
AccesGestionALCTConsulterEmploye not found in
C:\wamp\www\FIK_CE\Fonctions_PHP\Utilitaires.php on line 79
Warning: odbc_result() [function.odbc-result]: Field
AccesGestionALCTConsulterRapport not found in
C:\wamp\www\FIK_CE\Fonctions_PHP\Utilitaires.php on line 79
Warning: odbc_result() [function.odbc-result]: Field
AccesInternationalModifierClient not found in
C:\wamp\www\FIK_CE\Fonctions_PHP\Utilitaires.php on line 79
Warning: odbc_result() [function.odbc-result]: Field
AccesInternationalSupprimerClient not found in
C:\wamp\www\FIK_CE\Fonctions_PHP\Utilitaires.php on line 79
Warning: odbc_result() [function.odbc-result]: Field
AccesInternationalConsulterClient not found in
C:\wamp\www\FIK_CE\Fonctions_PHP\Utilitaires.php on line 79
Warning: odbc_result() [function.odbc-result]: Field
AccesInternationalAjouterContactClient not found in
C:\wamp\www\FIK_CE\Fonctions_PHP\Utilitaires.php on line 79
...
--
Edit this bug report at http://bugs.php.net/bug.php?id=50623edit=1
[PHP-BUG] Bug #51576 [NEW]: compile failure on zend_float.c
From: Operating system: AIX 5.3 PHP version: 5.3.2 Package: Compile Failure Bug Type: Bug Bug description:compile failure on zend_float.c Description: Compiler IBM visual age ver 6 .../php-5.3.2/Zend/zend_float.c, line 33.9: 1506-579 (W) The __asm directive is ignored. .../php-5.3.2/Zend/zend_float.c, line 34.9: 1506-579 (W) The __asm directive is ignored. .../php-5.3.2/Zend/zend_float.c, line 44.10: 1506-276 (S) Syntax error: possible missing 'while'? .../php-5.3.2/Zend/zend_float.c, line 48.17: 1506-579 (W) The __asm directive is ignored. .../php-5.3.2/Zend/zend_float.c, line 51.9: 1506-276 (S) Syntax error: possible missing 'while'? .../php-5.3.2/Zend/zend_float.c, line 55.1: 1506-276 (S) Syntax error: possible missing 'while'? .../php-5.3.2/Zend/zend_float.c, line 62.9: 1506-579 (W) The __asm directive is ignored. .../php-5.3.2/Zend/zend_float.c, line 64.10: 1506-204 (S) Unexpected end of file. make: *** [Zend/zend_float.lo] Error 1 -- Edit bug report at http://bugs.php.net/bug.php?id=51576edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51576r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51576r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51576r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51576r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51576r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51576r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51576r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51576r=needscript Try newer version: http://bugs.php.net/fix.php?id=51576r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51576r=support Expected behavior: http://bugs.php.net/fix.php?id=51576r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51576r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51576r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51576r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51576r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51576r=dst IIS Stability: http://bugs.php.net/fix.php?id=51576r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51576r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51576r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51576r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51576r=mysqlcfg
Bug #47643 [Com]: array_diff() takes over 3000 times longer than php 5.2.4
Edit report at http://bugs.php.net/bug.php?id=47643edit=1
ID: 47643
Comment by: sylvain at jamendo dot com
Reported by: viper7 at viper-7 dot com
Summary: array_diff() takes over 3000 times longer than php
5.2.4
Status: Assigned
Type: Bug
Package: Performance problem
Operating System: *
PHP Version: 5.*, 6CVS (2009-04-13)
Assigned To: felipe
New Comment:
I would also appreciate a patch, this issue made our servers crash after
a php 5.3
upgrade :-/
thanks!
Previous Comments:
[2010-02-17 20:53:53] maarten at talkin dot nl
Why dont you only reset ptr if (behavior DIFF_ASSOC) ?
[2010-01-17 12:09:15] emiel dot bruijntjes at copernica dot com
This bug is now open for 10 months. Are you still working on this?
[2009-07-09 20:38:20] j...@php.net
As Dmitry's noted, this is side-effect your fix caused.
[2009-07-01 15:32:01] dmi...@php.net
The problems occurs because of bad patch for bug #42838.
The diff algorithm sorts arrays using qsort and then assumes that they
are sorted correctly. But in case of user compaison function it can't be
guaranteed. Thus in ext/standard/tests/array/bug42838.phpt
key_compare_func() can't sort array correctly because expressions (0
'a') and (0 'a') both false ('a' is interpreted as a number 0).
It should be fixed in some way
[2009-06-30 15:22:24] der...@php.net
Dmitry, could you have a look? I have no idea why this occurs.
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=47643
--
Edit this bug report at http://bugs.php.net/bug.php?id=47643edit=1
Bug #51540 [Opn-Bgs]: insert data
Edit report at http://bugs.php.net/bug.php?id=51540edit=1
ID: 51540
Updated by: s...@php.net
Reported by: houssam dot asaad at hiast dot edu dot sy
Summary: insert data
-Status: Open
+Status: Bogus
Type: Bug
Package: OCI8 related
Operating System: win2003 server
PHP Version: 5.2.13
-Assigned To:
+Assigned To: sixd
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
I believe you also asked this question on
http://forums.oracle.com/forums/message.jspa?messageID=4218368
Please ask further questions using that forum.
Previous Comments:
[2010-04-12 11:12:37] houssam dot asaad at hiast dot edu dot sy
Description:
i use oci to insert data, but result is nothing
Test script:
---
$conn = oci_connect('username', 'password', 'HOST_IP/orcl',
'AR8MSWIN1256');
$query = 'INSERT INTO STUDENTS (IDNO, START_DATE) VALUES (:idno_v,
:startDate_v)';
$stid = oci_parse($conn, $query);
$idno = 999;
$startDate = date(d-M-y);
oci_bind_by_name($stid, ':idno_v', $idno);
oci_bind_by_name($stid, ':startDate_v', $startDate);
oci_execute($stid);
Expected result:
show data in STUDENTS table
Actual result:
--
no data inserted
--
Edit this bug report at http://bugs.php.net/bug.php?id=51540edit=1
[PHP-BUG] Bug #51577 [NEW]: Uninitialized memory reference with oci_bind_array_by_name
From: sixd Operating system: n/a PHP version: 5.3SVN-2010-04-16 (SVN) Package: OCI8 related Bug Type: Bug Bug description:Uninitialized memory reference with oci_bind_array_by_name Description: gcov.php.net shows all oci_bind_array_by_name tests giving a trace like: ==14231== Conditional jump or move depends on uninitialised value(s) ==14231==at 0x8542271: php_oci_bind_pre_exec (oci8_statement.c:816) ==14231==by 0x8AFE59E: zend_hash_apply_with_argument (zend_hash.c:697) ==14231==by 0x853DD3F: php_oci_statement_execute (oci8_statement.c:456) ==14231==by 0x8557E7E: zif_oci_execute (oci8_interface.c:1295) ==14231==by 0x8B38E49: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:313) ==14231==by 0x8B43391: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1603) ==14231==by 0x8B378EE: execute (zend_vm_execute.h:104) ==14231==by 0x8AE2869: zend_execute_scripts (zend.c:1194) ==14231==by 0x8A10176: php_execute_script (main.c:2260) ==14231==by 0x8CAE9E9: main (php_cli.c:1192) ==14231== ==14231== Use of uninitialised value of size 4 ==14231==at 0x854227A: php_oci_bind_pre_exec (oci8_statement.c:816) ==14231==by 0x8AFE59E: zend_hash_apply_with_argument (zend_hash.c:697) ==14231==by 0x853DD3F: php_oci_statement_execute (oci8_statement.c:456) ==14231==by 0x8557E7E: zif_oci_execute (oci8_interface.c:1295) ==14231==by 0x8B38E49: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:313) ==14231==by 0x8B43391: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1603) ==14231==by 0x8B378EE: execute (zend_vm_execute.h:104) ==14231==by 0x8AE2869: zend_execute_scripts (zend.c:1194) ==14231==by 0x8A10176: php_execute_script (main.c:2260) ==14231==by 0x8CAE9E9: main (php_cli.c:1192) ==14231== This is due to the oci_bind_by_name type check introduced http://svn.php.net/viewvc?view=revisionrevision=289264 This problem is present in OCI8 1.4.0 and 1.4.1 -- Edit bug report at http://bugs.php.net/bug.php?id=51577edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51577r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51577r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51577r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51577r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51577r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51577r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51577r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51577r=needscript Try newer version: http://bugs.php.net/fix.php?id=51577r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51577r=support Expected behavior: http://bugs.php.net/fix.php?id=51577r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51577r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51577r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51577r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51577r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51577r=dst IIS Stability: http://bugs.php.net/fix.php?id=51577r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51577r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51577r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51577r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51577r=mysqlcfg
Bug #51577 [Opn-Csd]: Uninitialized memory reference with oci_bind_array_by_name
Edit report at http://bugs.php.net/bug.php?id=51577edit=1 ID: 51577 Updated by: s...@php.net Reported by: s...@php.net Summary: Uninitialized memory reference with oci_bind_array_by_name -Status: Open +Status: Closed Type: Bug Package: OCI8 related Operating System: n/a PHP Version: 5.3SVN-2010-04-16 (SVN) -Assigned To: +Assigned To: sixd 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. Fixed in OCI8 1.4.2 and PHP 5.3.3 Previous Comments: [2010-04-16 22:36:42] s...@php.net Automatic comment from SVN on behalf of sixd Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=298086 Log: Fixed Bug #51577 (Uninitialized memory reference with oci_bind_array_by_name) [2010-04-16 22:34:39] s...@php.net Description: gcov.php.net shows all oci_bind_array_by_name tests giving a trace like: ==14231== Conditional jump or move depends on uninitialised value(s) ==14231==at 0x8542271: php_oci_bind_pre_exec (oci8_statement.c:816) ==14231==by 0x8AFE59E: zend_hash_apply_with_argument (zend_hash.c:697) ==14231==by 0x853DD3F: php_oci_statement_execute (oci8_statement.c:456) ==14231==by 0x8557E7E: zif_oci_execute (oci8_interface.c:1295) ==14231==by 0x8B38E49: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:313) ==14231==by 0x8B43391: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1603) ==14231==by 0x8B378EE: execute (zend_vm_execute.h:104) ==14231==by 0x8AE2869: zend_execute_scripts (zend.c:1194) ==14231==by 0x8A10176: php_execute_script (main.c:2260) ==14231==by 0x8CAE9E9: main (php_cli.c:1192) ==14231== ==14231== Use of uninitialised value of size 4 ==14231==at 0x854227A: php_oci_bind_pre_exec (oci8_statement.c:816) ==14231==by 0x8AFE59E: zend_hash_apply_with_argument (zend_hash.c:697) ==14231==by 0x853DD3F: php_oci_statement_execute (oci8_statement.c:456) ==14231==by 0x8557E7E: zif_oci_execute (oci8_interface.c:1295) ==14231==by 0x8B38E49: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:313) ==14231==by 0x8B43391: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1603) ==14231==by 0x8B378EE: execute (zend_vm_execute.h:104) ==14231==by 0x8AE2869: zend_execute_scripts (zend.c:1194) ==14231==by 0x8A10176: php_execute_script (main.c:2260) ==14231==by 0x8CAE9E9: main (php_cli.c:1192) ==14231== This is due to the oci_bind_by_name type check introduced http://svn.php.net/viewvc?view=revisionrevision=289264 This problem is present in OCI8 1.4.0 and 1.4.1 -- Edit this bug report at http://bugs.php.net/bug.php?id=51577edit=1
Bug #51576 [Com]: compile failure on zend_float.c
Edit report at http://bugs.php.net/bug.php?id=51576edit=1 ID: 51576 Comment by: i2r at pacbell dot net Reported by: i2r at pacbell dot net Summary: compile failure on zend_float.c Status: Open Type: Bug Package: Compile Failure Operating System: AIX 5.3 PHP Version: 5.3.2 New Comment: version of zend_float.c /* $Id: zend_float.c 293155 2010-01-05 20:46:53Z sebastian $ */ Previous Comments: [2010-04-16 21:39:59] i2r at pacbell dot net Description: Compiler IBM visual age ver 6 .../php-5.3.2/Zend/zend_float.c, line 33.9: 1506-579 (W) The __asm directive is ignored. .../php-5.3.2/Zend/zend_float.c, line 34.9: 1506-579 (W) The __asm directive is ignored. .../php-5.3.2/Zend/zend_float.c, line 44.10: 1506-276 (S) Syntax error: possible missing 'while'? .../php-5.3.2/Zend/zend_float.c, line 48.17: 1506-579 (W) The __asm directive is ignored. .../php-5.3.2/Zend/zend_float.c, line 51.9: 1506-276 (S) Syntax error: possible missing 'while'? .../php-5.3.2/Zend/zend_float.c, line 55.1: 1506-276 (S) Syntax error: possible missing 'while'? .../php-5.3.2/Zend/zend_float.c, line 62.9: 1506-579 (W) The __asm directive is ignored. .../php-5.3.2/Zend/zend_float.c, line 64.10: 1506-204 (S) Unexpected end of file. make: *** [Zend/zend_float.lo] Error 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=51576edit=1
[PHP-BUG] Req #51579 [NEW]: ob_gzhandler/header(304) incompatibility
From:
Operating system: irrelevant
PHP version: 5.2.13
Package: Unknown/Other Function
Bug Type: Feature/Change Request
Bug description:ob_gzhandler/header(304) incompatibility
Description:
test script below will produce a response with not empty body (it will
contain gzip stream header) which breaks the W3C standart that requires 304
response to have empty body.
The idea was to speed up things with compression and leveraging client side
caching, but end up firefox (v.3.6.3) prepending with that body some of
conseqent responces (css file in my case, which broken styles rendering -
that was really really hard to find - i just coudn't understand why my
server returns corrupted file and only to firefox)
Test script:
---
?php
ob_start(ob_gzhandler);
header('HTTP/1.1 304 Not Modified');
ob_end_flush();
?
Expected result:
ob_gzhandler() to look into response headers and wipe out buffer and
disable compression if 304 is set. Cause it's a subtle thing about 304
header, its body and the way ob_gzhandler() works and others can run into
same problem while trying to speed up website as compression and
client-side caching are 2 main things to do.
--
Edit bug report at http://bugs.php.net/bug.php?id=51579edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51579r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51579r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51579r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51579r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51579r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51579r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51579r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51579r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51579r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51579r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51579r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51579r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51579r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51579r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51579r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51579r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51579r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51579r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51579r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51579r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51579r=mysqlcfg
[PHP-BUG] Bug #51580 [NEW]: socket_select randomly crashes when used together with fork and Unix signals
From: Operating system: Debian Linux PHP version: 5.3.2 Package: PCNTL related Bug Type: Bug Bug description:socket_select randomly crashes when used together with fork and Unix signals Description: When firing unix signals onto a forked process with pcntl_signal handlers active and a socket_select currently running, socket_select may crash. Run the test script with php test.php 1339, and then launch some kill -s 10 child pid on it. After some, maybe just one, kill's, the script will crash. Test script: --- http://php.pastebin.com/Td68vtMn Expected result: Installing signal handlers Installing handler for signal 15 Installing handler for signal 10 child-pid 20030 running ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 (etc) Actual result: -- Installing signal handlers Installing handler for signal 15 Installing handler for signal 10 child-pid 20030 running ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 ma...@vs932:~/php_daemon$ PHP Warning: socket_select(): unable to select [4]: Interrupted system call in /home/marco/php_daemon/test.php on line 39 socket_select failed: Interrupted system call end ma...@vs932:~/php_daemon$ -- Edit bug report at http://bugs.php.net/bug.php?id=51580edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51580r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51580r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51580r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51580r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51580r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51580r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51580r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51580r=needscript Try newer version: http://bugs.php.net/fix.php?id=51580r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51580r=support Expected behavior: http://bugs.php.net/fix.php?id=51580r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51580r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51580r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51580r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51580r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51580r=dst IIS Stability: http://bugs.php.net/fix.php?id=51580r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51580r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51580r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51580r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51580r=mysqlcfg
[PHP-BUG] Bug #51581 [NEW]: getDefaultProperties incorrect for static properties
From:
Operating system: Mac OSx 10.6
PHP version: 5.3.2
Package: Reflection related
Bug Type: Bug
Bug description:getDefaultProperties incorrect for static properties
Description:
The array ReflectionClass's getDefaultProperties() method changes for
static
properties, depending upon what value the static property currently holds.
I suppose there is an argument to be made that this is expected/desired,
since
static properties are meant to hold across all instances of the class.
However, it
doesn't seem like it necessarily fits as part of a function to get the
*default*
property.
Test script:
---
?php
class foo {
static public $bar = 'true default value';
}
$r = new ReflectionClass('foo');
print_r($r-getDefaultProperties());
foo::$bar = 'new static value, no longer default though';
print_r($r-getDefaultProperties());
?
Expected result:
Array
(
[bar] = true default value
)
Array
(
[bar] = true default value
)
Actual result:
--
Array
(
[bar] = true default value
)
Array
(
[bar] = new static value, no longer default though
)
--
Edit bug report at http://bugs.php.net/bug.php?id=51581edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51581r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51581r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51581r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51581r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51581r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51581r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51581r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51581r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51581r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51581r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51581r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51581r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51581r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51581r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51581r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51581r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51581r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51581r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51581r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51581r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51581r=mysqlcfg
Bug #51580 [Opn-Fbk]: socket_select randomly crashes when used together with fork and Unix signals
Edit report at http://bugs.php.net/bug.php?id=51580edit=1 ID: 51580 Updated by: paj...@php.net Reported by: marco at vmsoft-gbr dot de Summary: socket_select randomly crashes when used together with fork and Unix signals -Status: Open +Status: Feedback Type: Bug Package: PCNTL related Operating System: Debian Linux PHP Version: 5.3.2 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Previous Comments: [2010-04-17 02:11:01] marco at vmsoft-gbr dot de Description: When firing unix signals onto a forked process with pcntl_signal handlers active and a socket_select currently running, socket_select may crash. Run the test script with php test.php 1339, and then launch some kill -s 10 child pid on it. After some, maybe just one, kill's, the script will crash. Test script: --- http://php.pastebin.com/Td68vtMn Expected result: Installing signal handlers Installing handler for signal 15 Installing handler for signal 10 child-pid 20030 running ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 (etc) Actual result: -- Installing signal handlers Installing handler for signal 15 Installing handler for signal 10 child-pid 20030 running ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 ma...@vs932:~/php_daemon$ PHP Warning: socket_select(): unable to select [4]: Interrupted system call in /home/marco/php_daemon/test.php on line 39 socket_select failed: Interrupted system call end ma...@vs932:~/php_daemon$ -- Edit this bug report at http://bugs.php.net/bug.php?id=51580edit=1
Bug #50847 [Com]: strip_tags() fails with extremely long tags (attributes)
Edit report at http://bugs.php.net/bug.php?id=50847edit=1 ID: 50847 Comment by: sarun37823 at bigfoot dot com Reported by: grayson at levy dot org dot il Summary: strip_tags() fails with extremely long tags (attributes) Status: Closed Type: Bug Package: Strings related Operating System: * PHP Version: 5.*, 6 New Comment: http://th.php.net/ChangeLog-5.php#5.2.13  greater then 1023 bytes should change to greater than 1023 bytes  Previous Comments: [2010-02-01 12:59:21] il...@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-02-01 12:59:09] s...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revisionrevision=294303 Log: Fixed bug #50847 (strip_tags() removes all tags greater then 1023 bytes long) [2010-01-26 17:18:19] j...@php.net It doesn't matter what the tag is. Or what it contains. Single char repeated enough times will make a mess.. [2010-01-26 15:06:38] grayson at levy dot org dot il Description: strip_tags() removes long param tags even when param is in the exclude list. Reproduce code: --- $var = param value=\file=http://www.whitehouse.gov/videos/2010/January/011910_FallsChurchVA.m4vpath_to_plugins=http://www.whitehouse.gov/sites/default/modules/wh_multimedia/wh_jwplayer/pluginspath_to_player=http://www.whitehouse.gov/sites/all/modules/swftools/shared/flash_media_playerskin=http://www.whitehouse.gov/sites/all/modules/swftools/shared/flash_media_player/skins/EOP_skin.swfcaptions_url=http://www.whitehouse.gov/sites/default/files/av_closedcaption/011910_Race_to_the_Top_for_Education_Reform.srtI=http://www.whitehouse.gov/sites/default/files/audio-video/video_thumbnail/P011910LJ-0100-3_0.jpgcontrolbar=bottomfrontcolor=AAplugins=http://www.whitehouse.gov/sites/default/modules/wh_multimedia/wh_jwplayer/plugins/privacy/privacy,http://www.whitehouse.gov/sites/default/modules/wh_multimedia/wh_jwplayer/plugins/hat/hat,http://www.whitehouse.gov/sites/default/modules/wh_multimedia/wh_jwplayer/plugins/share/share,http://www.whitehouse.gov/sites/default/modules/wh_multimedia/w h_jwplayer/plugins/captions/captionscaptions.file=http://www.whitehouse.gov/sites/default/files/av_closedcaption/011910_Race_to_the_Top_for_Education_Reform.srt\; name=\flashvars\ /; $var = strip_tags($var, param); Expected result: $var should be unchanged. Actual result: -- $var is empty. -- Edit this bug report at http://bugs.php.net/bug.php?id=50847edit=1
Req #40846 [Com]: pcre.backtrack_limit too restrictive
Edit report at http://bugs.php.net/bug.php?id=40846edit=1
ID: 40846
Comment by: wclark at xoom dot org
Reported by: crisp at xs4all dot nl
Summary: pcre.backtrack_limit too restrictive
Status: Open
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: all
PHP Version: 5.2.1
New Comment:
Please just set the PHP limits to match the default PCRE limits. People
asked for
that three years ago.. what's the holdup? I run into this problem quite
regularly
when using UNGREEDY matches, which frankly makes no sense (why would
UN-greedy
matches need more backtracking?) but I'll chalk that up to PCRE's poor
implementation. Regardless, if the PHP defaults were set higher I would
never
encounter these issues in the first place.
Previous Comments:
[2009-08-28 08:54:44] tom at r dot je
This is still an issue in 5.3.
The low limit causes scripts which hit it to fail without a warning,
notice or error, creating hard to track down bugs For example, something
which works fine for one set of data stops working on another set
because the data is just longer.
This cannot be the expected behaviour, surely?
At minimum there needs to be a warning. Ideally though, the limit needs
to be put to the pcre defaults.
[2007-12-10 14:18:11] daan at react dot nl
This issue is still a problem, plus this low setting is also the cause
of segfaults.
(see http://bugs.php.net/bug.php?id=43031)
At the moment even this simple regexp segfaults 5.2.5:
preg_match('/(.)*/', str_repeat('x', 6000));
I hope that is not intended behavior, as is suggested in the reply in
bug report 43031.
[2007-08-16 19:00:13] drnick at physics dot byu dot edu
I just wanted to throw out that I completely agree with crisp. We
recently updated PHP on our webserver to 5.2.3 and had issues with our
template system on input sizes of a certain size (100K).
The idea of allowing PHP to enforce limits on the PCRE library is fine,
but having the default action (when recursion_limit and backtrack_limit
are commented-out) be PHP overriding PCRE's internal limits is VERY
problematic. Aside from being incredibly anti backwards-compatible, I
believe PHP should not make arbitrary assumptions such as these.
I believe PHP should be changed so that the default action is to make
use of PCRE's internal limits, and if people want to enforce their own,
they can make that decision via the options. Perhaps modify
php.ini-recommended to explain the options and say why having external
limits can be good.
[2007-08-16 15:58:08] brandon at invisionpower dot com
Installations of 5.2 are causing this issue for us with relatively
simple regex. Users can submit an arbitrary amount of data (I work on a
bulletin board software) that is parsed out for bbcode tags. Even
simple expressions are causing problems.
$txt = preg_replace_callback(
#\[code\](.+?)\[/code\]#is, array(
$this, 'regex_code_tag' ), $txt );
var_dump( preg_last_error() );
The callback function is not being hit at all and the output is int(2)
(backtrack limit hit). Increasing backtrack limit to 1,000,000
resolves the issue, but with shared hosting plans it's unrealistic to
expect hosts to make php.ini changes to allow this.
I agree with crisp - the limit in PHP should bet set to the internal
PCRE options, with the php.ini settings allowing you to reduce them if
you wish. PHP should not arbitrarily reduce them.
[2007-05-20 11:22:00] crisp at xs4all dot nl
PHP 5.2.0 includes an update of the PCRE library (version 6.7), so some
problems may not be totally due to the restrictive limits of the PCRE
settings in PHP but could be a bug/regression in PCRE itself.
PCRE has always been very poor in internal optimisation of expressions
that contain look-aheads or look-behinds, especially when they are
combined with some OR'ed subexpression. It's backtracking mechanism is
quite simplistic and doesn't rule out execution paths that are sure not
to result in a match - in fact, it doesn't have any sort of execution
planner.
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=40846
--
Edit this bug report at http://bugs.php.net/bug.php?id=40846edit=1
