Req #54098 [Com]: Overly high defaults in config
Edit report at http://bugs.php.net/bug.php?id=54098&edit=1 ID: 54098 Comment by: marco at mimecom dot net Reported by:marco at mimecom dot net Summary:Overly high defaults in config Status: Assigned Type: Feature/Change Request Package:FPM related Operating System: Linux PHP Version:trunk-SVN-2011-02-25 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: Further arguing the low memory systems a bit: I commonly get myself a 512M slice to start development of a site. It's fast enough to develop on - and when time come to deploy, I'd ramp it up to something faster. So the low memory scenario is highly valid in my case. And even if we are not talking clouds, I think many places in the world would have low-memory hardware due to cost reasons. In the cloud, slices commonly start at 256M even - although even I feel it's too low. Compare to MySQL - a default install is tuned for the lowest common denominator as well, making sure it runs. The nice dining of large systems comes with a tuning dessert... Previous Comments: [2011-02-25 08:25:13] marco at mimecom dot net Well, since the configuration is active - not commented out - I'd say it is pretty much a default. A default make install would run with this configuration without modifications. You are right that my statement of there being a lot of 1Gb servers out there is taken out of the air - but I run a few (and two with 512Mb - still snappy), I know they are cheap (and it gets pretty expensive when you try to run larger servers) so it's just my *suspicion* that they are common. In any case, since the settings effectively are a default per above, I'd much rather see the software underperform than bring servers down. One way to fix it would be to comment out that setting and not let php-fpm start unless you go configuring yourself. But do mention in that comment to crosscheck with php's memory setting. It took a giant jump from a default 16M to 128M, which is why I think these settings kill servers. Before, at 16M, 50 was actually great. P.S. I don't really know what prompted that jump above, but it's not my concern... I guess there were reasons for it. [2011-02-25 08:05:19] f...@php.net It's not a bug it a feature ;) The subject will be discussed with other dev soon. I'll keep you updated. For me, default value, especialy those one should not be called "default value", but "exemple values". Saying that FPM is widely used in VPS with 512Mb of RAM is just a wrong assumption. As saying that FPM is widely used with physical servers with 12Gb of RAM. It depends on the server on which FPM runs but on the code itself. At the end, the sysadm is the only one who can set the right values. So if 50 is too high for some, they will lower it to 6. For others 50 will be too low and they will higher it to 200 or whatever. >From my point of vue, 50 is maybe quite too high, but the proposed value are too low. If you really want to lower the max and still use the dynamic PM, we can set: pm.max_children = 10 ;pm.start_servers = 2 ;pm.min_spare_servers = 1 ;pm.max_spare_servers = 4 [2011-02-25 05:56:06] marco at mimecom dot net Description: The default setting in the pool sets pm.max_children to 50, which with php's upped default memory_limit of 128Mb makes many moderately equipped machines to crash from out-of-memory. The settings combined makes it possible to consume 6GB of memory in a bad scenario. Since I suspect many a server nowadays are 1Gb (or even 512Mb) VPS's running on the different clouds out there, the settings are grossly excessive. I reported a bug against Ubuntu at first, but I think this is really the right place for it. https://bugs.launchpad.net/ubuntu/+source/php5/+bug/723480 pm.max_children should be more like 6 initially, with an explanation to increase the number if memory permits. Ether that or the default memory_limit should be lowered. I have read posts about running VPS where operators have to reboot every so often, and I think it *might* have to do with this problem, since I'm sure nginx+php+php-fpm is getting very popular as a stack. Expected result: Snappy happy server. Actual result: -- Server get sad, wrinkles, get dementia, finally get a stroke and dies. Takes as long time as it took my mother but in computer-years. -- Edit this bug report at http://bugs.php.net/bug.php?id=54098&edit=1
Req #54098 [Asn]: Overly high defaults in config
Edit report at http://bugs.php.net/bug.php?id=54098&edit=1 ID: 54098 User updated by:marco at mimecom dot net Reported by:marco at mimecom dot net Summary:Overly high defaults in config Status: Assigned Type: Feature/Change Request Package:FPM related Operating System: Linux PHP Version:trunk-SVN-2011-02-25 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: Well, since the configuration is active - not commented out - I'd say it is pretty much a default. A default make install would run with this configuration without modifications. You are right that my statement of there being a lot of 1Gb servers out there is taken out of the air - but I run a few (and two with 512Mb - still snappy), I know they are cheap (and it gets pretty expensive when you try to run larger servers) so it's just my *suspicion* that they are common. In any case, since the settings effectively are a default per above, I'd much rather see the software underperform than bring servers down. One way to fix it would be to comment out that setting and not let php-fpm start unless you go configuring yourself. But do mention in that comment to crosscheck with php's memory setting. It took a giant jump from a default 16M to 128M, which is why I think these settings kill servers. Before, at 16M, 50 was actually great. P.S. I don't really know what prompted that jump above, but it's not my concern... I guess there were reasons for it. Previous Comments: [2011-02-25 08:05:19] f...@php.net It's not a bug it a feature ;) The subject will be discussed with other dev soon. I'll keep you updated. For me, default value, especialy those one should not be called "default value", but "exemple values". Saying that FPM is widely used in VPS with 512Mb of RAM is just a wrong assumption. As saying that FPM is widely used with physical servers with 12Gb of RAM. It depends on the server on which FPM runs but on the code itself. At the end, the sysadm is the only one who can set the right values. So if 50 is too high for some, they will lower it to 6. For others 50 will be too low and they will higher it to 200 or whatever. >From my point of vue, 50 is maybe quite too high, but the proposed value are too low. If you really want to lower the max and still use the dynamic PM, we can set: pm.max_children = 10 ;pm.start_servers = 2 ;pm.min_spare_servers = 1 ;pm.max_spare_servers = 4 [2011-02-25 05:56:06] marco at mimecom dot net Description: The default setting in the pool sets pm.max_children to 50, which with php's upped default memory_limit of 128Mb makes many moderately equipped machines to crash from out-of-memory. The settings combined makes it possible to consume 6GB of memory in a bad scenario. Since I suspect many a server nowadays are 1Gb (or even 512Mb) VPS's running on the different clouds out there, the settings are grossly excessive. I reported a bug against Ubuntu at first, but I think this is really the right place for it. https://bugs.launchpad.net/ubuntu/+source/php5/+bug/723480 pm.max_children should be more like 6 initially, with an explanation to increase the number if memory permits. Ether that or the default memory_limit should be lowered. I have read posts about running VPS where operators have to reboot every so often, and I think it *might* have to do with this problem, since I'm sure nginx+php+php-fpm is getting very popular as a stack. Expected result: Snappy happy server. Actual result: -- Server get sad, wrinkles, get dementia, finally get a stroke and dies. Takes as long time as it took my mother but in computer-years. -- Edit this bug report at http://bugs.php.net/bug.php?id=54098&edit=1
Bug->Req #54098 [Opn->Asn]: Overly high defaults in config
Edit report at http://bugs.php.net/bug.php?id=54098&edit=1 ID: 54098 Updated by: f...@php.net Reported by:marco at mimecom dot net Summary:Overly high defaults in config -Status: Open +Status: Assigned -Type: Bug +Type: Feature/Change Request Package:FPM related Operating System: Linux PHP Version:trunk-SVN-2011-02-25 (SVN) -Assigned To: +Assigned To:fat Block user comment: N Private report: N New Comment: It's not a bug it a feature ;) The subject will be discussed with other dev soon. I'll keep you updated. For me, default value, especialy those one should not be called "default value", but "exemple values". Saying that FPM is widely used in VPS with 512Mb of RAM is just a wrong assumption. As saying that FPM is widely used with physical servers with 12Gb of RAM. It depends on the server on which FPM runs but on the code itself. At the end, the sysadm is the only one who can set the right values. So if 50 is too high for some, they will lower it to 6. For others 50 will be too low and they will higher it to 200 or whatever. >From my point of vue, 50 is maybe quite too high, but the proposed value are too low. If you really want to lower the max and still use the dynamic PM, we can set: pm.max_children = 10 ;pm.start_servers = 2 ;pm.min_spare_servers = 1 ;pm.max_spare_servers = 4 Previous Comments: [2011-02-25 05:56:06] marco at mimecom dot net Description: The default setting in the pool sets pm.max_children to 50, which with php's upped default memory_limit of 128Mb makes many moderately equipped machines to crash from out-of-memory. The settings combined makes it possible to consume 6GB of memory in a bad scenario. Since I suspect many a server nowadays are 1Gb (or even 512Mb) VPS's running on the different clouds out there, the settings are grossly excessive. I reported a bug against Ubuntu at first, but I think this is really the right place for it. https://bugs.launchpad.net/ubuntu/+source/php5/+bug/723480 pm.max_children should be more like 6 initially, with an explanation to increase the number if memory permits. Ether that or the default memory_limit should be lowered. I have read posts about running VPS where operators have to reboot every so often, and I think it *might* have to do with this problem, since I'm sure nginx+php+php-fpm is getting very popular as a stack. Expected result: Snappy happy server. Actual result: -- Server get sad, wrinkles, get dementia, finally get a stroke and dies. Takes as long time as it took my mother but in computer-years. -- Edit this bug report at http://bugs.php.net/bug.php?id=54098&edit=1
[PHP-BUG] Bug #54098 [NEW]: Overly high defaults in config
From: Operating system: Linux PHP version: trunk-SVN-2011-02-25 (SVN) Package: FPM related Bug Type: Bug Bug description:Overly high defaults in config Description: The default setting in the pool sets pm.max_children to 50, which with php's upped default memory_limit of 128Mb makes many moderately equipped machines to crash from out-of-memory. The settings combined makes it possible to consume 6GB of memory in a bad scenario. Since I suspect many a server nowadays are 1Gb (or even 512Mb) VPS's running on the different clouds out there, the settings are grossly excessive. I reported a bug against Ubuntu at first, but I think this is really the right place for it. https://bugs.launchpad.net/ubuntu/+source/php5/+bug/723480 pm.max_children should be more like 6 initially, with an explanation to increase the number if memory permits. Ether that or the default memory_limit should be lowered. I have read posts about running VPS where operators have to reboot every so often, and I think it *might* have to do with this problem, since I'm sure nginx+php+php-fpm is getting very popular as a stack. Expected result: Snappy happy server. Actual result: -- Server get sad, wrinkles, get dementia, finally get a stroke and dies. Takes as long time as it took my mother but in computer-years. -- Edit bug report at http://bugs.php.net/bug.php?id=54098&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54098&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54098&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54098&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54098&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54098&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54098&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54098&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54098&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54098&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54098&r=support Expected behavior: http://bugs.php.net/fix.php?id=54098&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54098&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54098&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54098&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54098&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54098&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54098&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54098&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54098&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54098&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54098&r=mysqlcfg
Bug #54085 [Com]: problem when encode
Edit report at http://bugs.php.net/bug.php?id=54085&edit=1
ID: 54085
Comment by: nong_asc at hotmail dot com
Reported by:nong_asc at hotmail dot com
Summary:problem when encode
Status: Bogus
Type: Bug
Package:MySQL related
Operating System: window xp
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
Thank you
Previous Comments:
[2011-02-24 13:22:16] ahar...@php.net
Please report this to Zend, not to us. We can't support third-party
extensions like Zend Guard.
[2011-02-24 13:22:01] johan...@php.net
Do not file bugs when you have Zend extensions (zend_extension=)
loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache,
APC, Xdebug and ionCube loader. These extensions often modify engine
behavior which is not related to PHP itself.
Please report issues with commercial software to the vendor.
[2011-02-24 04:20:51] nong_asc at hotmail dot com
Description:
When I encode by zend guard(v5.0.0) and after I run this code I have a
message
Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to
allocate
54263789 bytes) in
C:\h\ghx\apache\htdocs\alpha\include\connection.inc.php on
line 1072
but if I run and not encode it's work well.
PHP Version 5.2.16
This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with Zend Extension Manager v1.2.0, Copyright (c) 2003-2007, by Zend
Technologies
with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend
Technologies
Test script:
---
100";
$openselect = 0;
$parole = explode(" ",$string);
$i = 0;
$trovata = 0;
foreach ($parole as $elabora){
if((strpos($elabora,"SELECT")!==false && $trovata==0)){
$openselect++;
}
if((strpos($elabora,"FROM")!==false && $trovata==0)){
$openselect--;
}
if($openselect==0){
$trovata = 1;
$condizione .= " ".$elabora;
echo "linke 1074 ".$condizione."";
array_splice($parole,$i);
}
$i++;
}
?>
--
Edit this bug report at http://bugs.php.net/bug.php?id=54085&edit=1
Bug #54053 [Bgs]: iconv returns strings with excessive memory usage
Edit report at http://bugs.php.net/bug.php?id=54053&edit=1 ID: 54053 User updated by:r3z at pr0j3ctr3z dot com Reported by:r3z at pr0j3ctr3z dot com Summary:iconv returns strings with excessive memory usage Status: Bogus Type: Bug Package:ICONV related Operating System: Windows XP SP3 PHP Version:5.2.17 Block user comment: N Private report: N New Comment: Please re-open this bug report. The issue is as described. Checking memory usage outside the loop shows stabilized memory usage because the buffer which stores the results from iconv is unset, thereby freeing the memory used. Regardless, this is not a memory manager issue. The problem is that the function php_iconv_string, in ext/iconv.c, allocates an output buffer the same size as the input buffer and doesn't reduce the size of the allocated memory block depending on the actual size of the result before returning. This, in certain circumstances, can waste an awful lot of memory. The attached patch for ext/iconv.c taken from the PHP 5.2.17 source code resolves this issue by modifying the function php_iconv_string so that it resizes the output buffer to the actual size of the string it contains before returning. Previous Comments: [2011-02-19 20:39:05] scott...@php.net . [2011-02-19 20:38:24] scott...@php.net Already works like you describe, only the memory required is copied from the iconv buffer. Add a check outside the loop and you'll see its stabilised again back to 4mb. This just the way the memory manager works. [2011-02-19 06:43:23] r3z at pr0j3ctr3z dot com Made minor alteration to the summary [2011-02-19 06:30:51] r3z at pr0j3ctr3z dot com Description: PHP 5.2.17 / libiconv 1.11 / Windows XP SP3 It would appear that, on my machine at least, the result returned by iconv uses the same amount of memory as the input string, even if it doesn't actually need to. This only happens when the result is smaller than the input string. When the result is bigger than the input string, i.e. going from ISO-8859-1 characters above 0x7F, to UTF-8, the resulting memory usage is as expected. To demonstrate, the example code initializes an array of 4 UTF-8 strings, which I have named: n-tilde; multiplication; cyrillic-i; and invalid. Each 1MB string is repeatedly (for dramatic effect) transliterated to ASCII, and the resulting string is stored in a buffer array. The memory usage before and after these repeated transliteration is recorded and displayed. The difference in the memory usage before and after, therefore closely approximates the memory usage of the buffer array. During the transliteration the following occurs: n-tilde: each 2-byte UTF-8 character, U+00F1, is transliterated to the 2-byte ASCII sequence '~n', so each buffer should use 1MB. multiplication: each 2-byte UTF-8 character, U+00D7, is transliterated to the 1-byte ASCII sequence 'x', so each buffer should use 0.5MB. cyrillic-i: each 2-byte UTF-8 character, U+0438, is ignored since there is no transliteration. So iconv returns the empty string. Therefore, each buffer should use 0MB. invalid: 0xFF is invalid in UTF-8 so iconv stops processing the input string at the first character, generates an E_NOTICE (which I mask to make the output more readable) and returns the incomplete result, the empty string. Therefore, each buffer should use 0MB. I am aware that it takes ~68 bytes per entry, plus the size of the data to store the array, however, in this case 16 entries, plus index strings, only amounts to ~1KB, which is insignificant compared to the results. Keeping this in mind though, you would expect additional memory usage caused by the creation of the 16 entry, buffer array to be: ~16MB for n-tilde (16 buffers @ 1MB each); ~8MB for multiplication (16 buffers @ 0.5MB each); ~1KB for cyrillic-i (16 buffers @ 0MB each); ~1KB for invalid (16 buffers @ 0MB each). This ties in very neatly with my expected results, as shown. However, the actual results are significantly different. As you can see, the buffer for each string uses 16MB. Note that this is 16 buffers @ 1MB (the size of the input string). Obviously, this should not be the case. An array of 16 empty strings, in the cases of the cyrillic-i and invalid tests, should not use 16MB of memory. Although I haven't shown it here for brevity, the contents of the buffer after, for example, the invalid test, are indeed 16 empty strings which act like empty strings should. They work just fine. They just use 1MB of memory each. When you strlen them, they report being zero-length as you would expect. But they
Bug #54097 [Opn]: rename() of dirs accross devices produces confusing copy error
Edit report at http://bugs.php.net/bug.php?id=54097&edit=1
ID: 54097
User updated by:clint at ubuntu dot com
Reported by:clint at ubuntu dot com
Summary:rename() of dirs accross devices produces confusing
copy error
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: Linux (Ubuntu)
PHP Version:5.3.6RC1
Block user comment: N
Private report: N
New Comment:
I forgot to mention, this was reported in Ubuntu here:
https://launchpad.net/bugs/723330
Previous Comments:
[2011-02-25 02:10:59] clint at ubuntu dot com
Description:
When a user tries to rename a directory accross filesystems, they are
presented
with this warning:
PHP Warning: rename(): The first argument to copy() function cannot be
a
directory in Command line code on line 1
PHP Warning: rename(t2,/var/run/test/t2): Invalid cross-device link in
Command
line code on line 1
To contrast this, running 'mv t2 /var/run/test/t2' works without any
problems.
Test script:
---
$ sudo mkdir /var/run/test && sudo chown `whoami` /var/run/test
$ mkdir t2
$ touch t2/a.file
$ php -r "rename('t2','/var/run/test/t2');"
Expected result:
I would expect the directory to be copied with its contents in their
entirety to
the new destination, *OR* at the very least, an error message that
specifies that
one cannot rename directories, as its confusing that it mentions copy
during a
rename.
Actual result:
--
PHP Warning: rename(): The first argument to copy() function cannot be
a
directory in Command line code on line 1
PHP Warning: rename(t2,/var/run/test/t2): Invalid cross-device link in
Command
line code on line 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=54097&edit=1
[PHP-BUG] Bug #54097 [NEW]: rename() of dirs accross devices produces confusing copy error
From:
Operating system: Linux (Ubuntu)
PHP version: 5.3.6RC1
Package: Filesystem function related
Bug Type: Bug
Bug description:rename() of dirs accross devices produces confusing copy error
Description:
When a user tries to rename a directory accross filesystems, they are
presented
with this warning:
PHP Warning: rename(): The first argument to copy() function cannot be a
directory in Command line code on line 1
PHP Warning: rename(t2,/var/run/test/t2): Invalid cross-device link in
Command
line code on line 1
To contrast this, running 'mv t2 /var/run/test/t2' works without any
problems.
Test script:
---
$ sudo mkdir /var/run/test && sudo chown `whoami` /var/run/test
$ mkdir t2
$ touch t2/a.file
$ php -r "rename('t2','/var/run/test/t2');"
Expected result:
I would expect the directory to be copied with its contents in their
entirety to
the new destination, *OR* at the very least, an error message that
specifies that
one cannot rename directories, as its confusing that it mentions copy
during a
rename.
Actual result:
--
PHP Warning: rename(): The first argument to copy() function cannot be a
directory in Command line code on line 1
PHP Warning: rename(t2,/var/run/test/t2): Invalid cross-device link in
Command
line code on line 1
--
Edit bug report at http://bugs.php.net/bug.php?id=54097&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54097&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54097&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54097&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54097&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54097&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54097&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54097&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54097&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54097&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54097&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54097&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54097&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54097&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54097&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54097&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54097&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54097&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54097&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54097&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54097&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54097&r=mysqlcfg
Bug #54092 [Fbk]: Segmentation fault when using FTP proxy
Edit report at http://bugs.php.net/bug.php?id=54092&edit=1 ID: 54092 Updated by: cataphr...@php.net Reported by:daniel dot buschke at nextiraone dot de Summary:Segmentation fault when using FTP proxy Status: Feedback Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:5.2.17 Block user comment: N Private report: N New Comment: I can reproduce in 5.3 with Apache working as the proxy. Previous Comments: [2011-02-24 21:52:05] il...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Cannot reproduce the crash in 5.3 [2011-02-24 17:33:16] daniel dot buschke at nextiraone dot de Just for history: php -v PHP 5.3.6RC2-dev (cli) (built: Feb 24 2011 17:17:30) (DEBUG) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies [2011-02-24 17:31:07] daniel dot buschke at nextiraone dot de BackTrace of 5.3-latest: #0 0x08394b84 in _php_stream_write_filtered (stream=0xca0, buf=0x87431c6 "QUIT\r\n", count=6, flags=0) at /usr/src/php5.3-201102241530/main/streams/streams.c:1001 #1 0x08394d24 in _php_stream_write (stream=0xca0, buf=0x87431c6 "QUIT\r\n", count=6) at /usr/src/php5.3-201102241530/main/streams/streams.c:1067 #2 0x0834cdc0 in php_stream_ftp_stream_close (wrapper=0x87768e8, stream=0xd10) at /usr/src/php5.3-201102241530/ext/standard/ftp_fopen_wrapper.c:120 #3 0x083938f3 in _php_stream_free (stream=0xd10, close_options=11) at /usr/src/php5.3-201102241530/main/streams/streams.c:376 #4 0x0839591f in stream_resource_regular_dtor (rsrc=0xe14) at /usr/src/php5.3-201102241530/main/streams/streams.c:1433 #5 0x083f715b in list_entry_destructor (ptr=0xe14) at /usr/src/php5.3-201102241530/Zend/zend_list.c:184 #6 0x083f47fe in zend_hash_del_key_or_index (ht=0x878e42c, arKey=0x0, nKeyLength=0, h=5, flag=1) at /usr/src/php5.3-201102241530/Zend/zend_hash.c:500 #7 0x083f6e49 in _zend_list_delete (id=5) at /usr/src/php5.3-201102241530/Zend/zend_list.c:58 #8 0x08300d78 in zif_fclose (ht=1, return_value=0x4f8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /usr/src/php5.3-201102241530/ext/standard/file.c:957 #9 0x084145de in zend_do_fcall_common_helper_SPEC (execute_data=0x88b5258) at /usr/src/php5.3-201102241530/Zend/zend_vm_execute.h:316 #10 0x08418122 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x88b5258) at /usr/src/php5.3-201102241530/Zend/zend_vm_execute.h:1606 #11 0x08413c7b in execute (op_array=0x8887010) at /usr/src/php5.3-201102241530/Zend/zend_vm_execute.h:107 #12 0x083e6f23 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php5.3-201102241530/Zend/zend.c:1194 #13 0x0837de64 in php_execute_script (primary_file=0xb12c) at /usr/src/php5.3-201102241530/main/main.c:2268 #14 0x084aa2f8 in main (argc=2, argv=0xb2a4) at /usr/src/php5.3-201102241530/sapi/cli/php_cli.c:1193 [2011-02-24 17:14:33] daniel dot buschke at nextiraone dot de Hi, PHP 5.3(!) is compiling with --enable-debug and --enable-ftp. Hope that's enough. Our test machine is not the fastest one ;-) But I am confused about 5.3. I think using 5.2-latest would be a better idea?! regards Daniel [2011-02-24 17:06:18] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-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=54092 -- Edit this bug report at http://bugs.php.net/bug.php?id=54092&edit=1
Bug #54092 [Opn->Fbk]: Segmentation fault when using FTP proxy
Edit report at http://bugs.php.net/bug.php?id=54092&edit=1 ID: 54092 Updated by: il...@php.net Reported by:daniel dot buschke at nextiraone dot de Summary:Segmentation fault when using FTP proxy -Status: Open +Status: Feedback Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:5.2.17 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/ Cannot reproduce the crash in 5.3 Previous Comments: [2011-02-24 17:33:16] daniel dot buschke at nextiraone dot de Just for history: php -v PHP 5.3.6RC2-dev (cli) (built: Feb 24 2011 17:17:30) (DEBUG) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies [2011-02-24 17:31:07] daniel dot buschke at nextiraone dot de BackTrace of 5.3-latest: #0 0x08394b84 in _php_stream_write_filtered (stream=0xca0, buf=0x87431c6 "QUIT\r\n", count=6, flags=0) at /usr/src/php5.3-201102241530/main/streams/streams.c:1001 #1 0x08394d24 in _php_stream_write (stream=0xca0, buf=0x87431c6 "QUIT\r\n", count=6) at /usr/src/php5.3-201102241530/main/streams/streams.c:1067 #2 0x0834cdc0 in php_stream_ftp_stream_close (wrapper=0x87768e8, stream=0xd10) at /usr/src/php5.3-201102241530/ext/standard/ftp_fopen_wrapper.c:120 #3 0x083938f3 in _php_stream_free (stream=0xd10, close_options=11) at /usr/src/php5.3-201102241530/main/streams/streams.c:376 #4 0x0839591f in stream_resource_regular_dtor (rsrc=0xe14) at /usr/src/php5.3-201102241530/main/streams/streams.c:1433 #5 0x083f715b in list_entry_destructor (ptr=0xe14) at /usr/src/php5.3-201102241530/Zend/zend_list.c:184 #6 0x083f47fe in zend_hash_del_key_or_index (ht=0x878e42c, arKey=0x0, nKeyLength=0, h=5, flag=1) at /usr/src/php5.3-201102241530/Zend/zend_hash.c:500 #7 0x083f6e49 in _zend_list_delete (id=5) at /usr/src/php5.3-201102241530/Zend/zend_list.c:58 #8 0x08300d78 in zif_fclose (ht=1, return_value=0x4f8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /usr/src/php5.3-201102241530/ext/standard/file.c:957 #9 0x084145de in zend_do_fcall_common_helper_SPEC (execute_data=0x88b5258) at /usr/src/php5.3-201102241530/Zend/zend_vm_execute.h:316 #10 0x08418122 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x88b5258) at /usr/src/php5.3-201102241530/Zend/zend_vm_execute.h:1606 #11 0x08413c7b in execute (op_array=0x8887010) at /usr/src/php5.3-201102241530/Zend/zend_vm_execute.h:107 #12 0x083e6f23 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php5.3-201102241530/Zend/zend.c:1194 #13 0x0837de64 in php_execute_script (primary_file=0xb12c) at /usr/src/php5.3-201102241530/main/main.c:2268 #14 0x084aa2f8 in main (argc=2, argv=0xb2a4) at /usr/src/php5.3-201102241530/sapi/cli/php_cli.c:1193 [2011-02-24 17:14:33] daniel dot buschke at nextiraone dot de Hi, PHP 5.3(!) is compiling with --enable-debug and --enable-ftp. Hope that's enough. Our test machine is not the fastest one ;-) But I am confused about 5.3. I think using 5.2-latest would be a better idea?! regards Daniel [2011-02-24 17:06:18] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2011-02-24 17:02:16] daniel dot buschke at nextiraone dot de BackTrace (without debug symbols, hope it is usefull): #0 0x082c9780 in ?? () #1 0x08286b4e in ?? () #2 0x082c9c54 in _php_stream_free () #3 0x082c9e1b in ?? () #4 0x08303a2c in list_entry_destructor () #5 0x08301288 in zend_hash_del_key_or_index () #6 0x08303cc0 in _zend_list_delete () #7 0x0824cc6d in zif_fclose () #8 0x08314381 in execute_internal () #9 0xb705e672 in xdebug_execute_internal () from /usr/lib/php5.2/lib/extensions/no-debug-non-zts-20060613/xdebug.so #10 0x0832a071 in ?? () #11 0x08318420 in execute () #12 0xb705e324 in xdebug_execute () from /usr/lib/php5.2/lib/extensions/no-debug-non-zts-20060613/xdebug.so #13 0x082f6d0c in zend_execute_scripts () #14 0x082b5724 in php_execute_script () #15 0x0836f023 in main () 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=54092 -- Edit this bug report at h
Bug #51593 [Com]: imageellipse() draws incorrectly
Edit report at http://bugs.php.net/bug.php?id=51593&edit=1 ID: 51593 Comment by: blyon at blyon dot com Reported by:ellipsebugs at yahoo dot com Summary:imageellipse() draws incorrectly Status: Open Type: Bug Package:GD related Operating System: Windows XP PHP Version:5.3.2 Block user comment: N Private report: N New Comment: I'm having the same problem with large ellipses on FreeBSD, I am trying to do ellipses > 1000 pixels and they look like bumpy squares: PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Oct 21 2008 18:22:59) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies Previous Comments: [2010-04-18 23:17:51] ellipsebugs at yahoo dot com Description: On a system of Window XP, PHP/5.3.0 and GD 2.0.34 the imageellipse() function fails to draw a circle properly when dealing with large dimensions. Calling the function for a circle with radius over 1032 pixels (an ellipse with equal width and height over 2064 pixels) creates a deformed circle with bumps in four directions. Increasing the dimensions makes things worse. On a system of Linux, PHP/5.2.13 and GD 2.0.34 the issue does not appear. Test script: --- Expected result: A relatively smooth circle is drawn. Actual result: -- The resulting circle has irregular bumps in it. -- Edit this bug report at http://bugs.php.net/bug.php?id=51593&edit=1
Bug #52298 [Com]: Apache service won't start with PHP enabled
Edit report at http://bugs.php.net/bug.php?id=52298&edit=1 ID: 52298 Comment by: cyue at datalogics dot com Reported by:murray at math dot umass dot edu Summary:Apache service won't start with PHP enabled Status: Bogus Type: Bug Package:Apache2 related Operating System: Windows XP Pro (SP3) PHP Version:5.3.2 Block user comment: N Private report: N New Comment: I figured it out by reading some other posts. It may be Windows 7 only thing. I had to manually edit the httpd.conf file under Apache to point PHPIniDir to the PHP location. It seems to be working fine on another 2003 server without having to do this manually. PHPIniDir "C:/Program Files/PHP/" Previous Comments: [2011-02-24 18:22:12] cyue at datalogics dot com I am having the same problem. I installed Apache 2.2 and PHP 5.3.5 VC6 threaded version, Windows 7 64-bit system. The Apache service can start without PHP installed, but after the PHP is installed, I am getting the error that the php5apache2_2.dll is not found error. Even though it is inside the PHP folder. Any suggestions? [2010-07-21 22:51:22] m...@php.net 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. [2010-07-09 18:00:52] murray at math dot umass dot edu Source of conflict found: additional copies of php_*.dll files in a separate Marvell MRU subdirectory of C:\Program files (from a monitor of Marvell RAID controller) which uses an embedded apache server. I uninstalled the Marvell MRU program. Now I can start Apache 2.2.15 service with apache loaded, as usual, as a PHP module with PHP 5.3.2. Even after removing my whole PHP tree obtained from the .zip and instead using the VC6 x86 Thread Safe.msi installer. [2010-07-09 09:21:36] paj...@php.net 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. [2010-07-09 03:56:37] murray at math dot umass dot edu Description: Summary: as soon as I add loading PHP 5.3.2 as a module, Apache 2.2.15 service won't start. Without the load, Apache service is OK; and PHP from command line is OK. What I did: (1) Installed Apache 2.2.15 in a localhost config from httpd-2.2.15-win32-x86-no_ssl.msi (also tried the openssl version when the former + PHP didn't work). That worked just fine. (2) Installed PHP 5.3.2 from php-5.3.2-Win32-VC6-x86.msi (thread safe), which php.net says to use, as I read its instructions. (It says NOT to use the VC9 version with apache.org binaries.) Now the apache httpd service will not start. So of course I never got so far as to try a .php script in the browser. Of course I put the correct entries in PATH and PHPRC. My httpd.conf was what the apache installer set up plus my changes in appropriate spots. I retried everything after completely uninstalling both apache http and PHP, again using httpd-2.2.15-win32-x86-no_ssl.msi but this time installing PHP manually from php-5.3.2-Win32-VC6-x86.zip. File httpd.conf is what the Apache installer set up plus my edits in appropriate spots: ServerName localhost:80 DocumentRoot "E:/htdocs" LoadModule php5_module "D:/Server/PHP/php5apache2_2.dll" PHPIniDir "D:/Server/PHP" AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps My edits to php.ini are: PHPIniDir "D:/Server/PHP/" LoadModule php5_module "D:/Server/PHP/php5apache2_2.dll" Apache error.log contains just: [warn] pid file D:/Server/Apache2.2/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? The Windows Event log, System view shows: The Apache2.2 service terminated with service-specific error 1 (0x 1). And Windows Even log, Application view shows: Faulting application httpd.exe, version 2.2.15.0,
Bug #54096 [Com]: wrong behavior FILTER_VALIDATE_INT -0 +0
Edit report at http://bugs.php.net/bug.php?id=54096&edit=1
ID: 54096
Comment by: _coola_ at arcor dot de
Reported by:_coola_ at arcor dot de
Summary:wrong behavior FILTER_VALIDATE_INT -0 +0
Status: Open
Type: Bug
Package:Filter related
Operating System: -
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
It would also be nice if anybody would care about
http://bugs.php.net/bug.php?id=53775
Previous Comments:
[2011-02-24 19:51:27] _coola_ at arcor dot de
Description:
Bug report #47752
error_reporting(-1);
var_dump(filter_var('-0',FILTER_VALIDATE_INT)); // bool(false)
var_dump(-0); // int(0)
In my opinion FILTER_VALIDATE_INT must work like var_dump(-0);
Sooner or later we will get problems if everything works different.
PHP defines -0 as an int. So FILTER_VALIDATE_INT must also accept -0 and
+0.
Thank you
--
Edit this bug report at http://bugs.php.net/bug.php?id=54096&edit=1
[PHP-BUG] Bug #54096 [NEW]: wrong behavior FILTER_VALIDATE_INT -0 +0
From:
Operating system: -
PHP version: Irrelevant
Package: Filter related
Bug Type: Bug
Bug description:wrong behavior FILTER_VALIDATE_INT -0 +0
Description:
Bug report #47752
error_reporting(-1);
var_dump(filter_var('-0',FILTER_VALIDATE_INT)); // bool(false)
var_dump(-0); // int(0)
In my opinion FILTER_VALIDATE_INT must work like var_dump(-0);
Sooner or later we will get problems if everything works different.
PHP defines -0 as an int. So FILTER_VALIDATE_INT must also accept -0 and
+0.
Thank you
--
Edit bug report at http://bugs.php.net/bug.php?id=54096&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54096&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54096&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54096&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54096&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54096&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54096&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54096&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54096&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54096&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54096&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54096&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54096&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54096&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54096&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54096&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54096&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54096&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54096&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54096&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54096&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54096&r=mysqlcfg
Bug #52298 [Com]: Apache service won't start with PHP enabled
Edit report at http://bugs.php.net/bug.php?id=52298&edit=1 ID: 52298 Comment by: cyue at datalogics dot com Reported by:murray at math dot umass dot edu Summary:Apache service won't start with PHP enabled Status: Bogus Type: Bug Package:Apache2 related Operating System: Windows XP Pro (SP3) PHP Version:5.3.2 Block user comment: N Private report: N New Comment: I am having the same problem. I installed Apache 2.2 and PHP 5.3.5 VC6 threaded version, Windows 7 64-bit system. The Apache service can start without PHP installed, but after the PHP is installed, I am getting the error that the php5apache2_2.dll is not found error. Even though it is inside the PHP folder. Any suggestions? Previous Comments: [2010-07-21 22:51:22] m...@php.net 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. [2010-07-09 18:00:52] murray at math dot umass dot edu Source of conflict found: additional copies of php_*.dll files in a separate Marvell MRU subdirectory of C:\Program files (from a monitor of Marvell RAID controller) which uses an embedded apache server. I uninstalled the Marvell MRU program. Now I can start Apache 2.2.15 service with apache loaded, as usual, as a PHP module with PHP 5.3.2. Even after removing my whole PHP tree obtained from the .zip and instead using the VC6 x86 Thread Safe.msi installer. [2010-07-09 09:21:36] paj...@php.net 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. [2010-07-09 03:56:37] murray at math dot umass dot edu Description: Summary: as soon as I add loading PHP 5.3.2 as a module, Apache 2.2.15 service won't start. Without the load, Apache service is OK; and PHP from command line is OK. What I did: (1) Installed Apache 2.2.15 in a localhost config from httpd-2.2.15-win32-x86-no_ssl.msi (also tried the openssl version when the former + PHP didn't work). That worked just fine. (2) Installed PHP 5.3.2 from php-5.3.2-Win32-VC6-x86.msi (thread safe), which php.net says to use, as I read its instructions. (It says NOT to use the VC9 version with apache.org binaries.) Now the apache httpd service will not start. So of course I never got so far as to try a .php script in the browser. Of course I put the correct entries in PATH and PHPRC. My httpd.conf was what the apache installer set up plus my changes in appropriate spots. I retried everything after completely uninstalling both apache http and PHP, again using httpd-2.2.15-win32-x86-no_ssl.msi but this time installing PHP manually from php-5.3.2-Win32-VC6-x86.zip. File httpd.conf is what the Apache installer set up plus my edits in appropriate spots: ServerName localhost:80 DocumentRoot "E:/htdocs" LoadModule php5_module "D:/Server/PHP/php5apache2_2.dll" PHPIniDir "D:/Server/PHP" AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps My edits to php.ini are: PHPIniDir "D:/Server/PHP/" LoadModule php5_module "D:/Server/PHP/php5apache2_2.dll" Apache error.log contains just: [warn] pid file D:/Server/Apache2.2/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run? The Windows Event log, System view shows: The Apache2.2 service terminated with service-specific error 1 (0x 1). And Windows Even log, Application view shows: Faulting application httpd.exe, version 2.2.15.0, faulting module unknown, version 0.0.0.0, fault address 0x0074f1a9. Essentially the same bug has been reported in a number of user forums, and I waited to see if anybody detected some configuration mistake, but to no avail. Test script: --- I don't know how to do a back-trace, since I find no explanation anywhere of what to do with the PHP debug-pack. Expected result: Apache 2.2.15 se
[PHP-BUG] Req #54095 [NEW]: Impossible to access static p/m/const from static context directly
From: Operating system: Win7 PHP version: Irrelevant Package: Class/Object related Bug Type: Feature/Change Request Bug description:Impossible to access static p/m/const from static context directly Description: There is no support for DIRECT access constants, static properties or static methods from static context. It means, that there is only "one-level" ability to access theese things. We have to use workaround to eliminate this problem. But this workaround rises up a code and seems strange. Test script: --- echo config::$languageFile::error404; Expected result: The page was not found Actual result: -- Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM, expecting ',' or ';' --- The workaround is: $languageFile = config::$languageFile; echo $languageFile::error404; The code above works. The direct access would be purer and easier. -- Edit bug report at http://bugs.php.net/bug.php?id=54095&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54095&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54095&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54095&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54095&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54095&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54095&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54095&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54095&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54095&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54095&r=support Expected behavior: http://bugs.php.net/fix.php?id=54095&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54095&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54095&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54095&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54095&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54095&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54095&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54095&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54095&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54095&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54095&r=mysqlcfg
Bug #54094 [Opn->Bgs]: Sprintf change integer with %d
Edit report at http://bugs.php.net/bug.php?id=54094&edit=1
ID: 54094
Updated by: ras...@php.net
Reported by:mallsbill at gmail dot com
Summary:Sprintf change integer with %d
-Status: Open
+Status: Bogus
Type: Bug
Package:Strings related
Operating System: Linux debian 2.6.26-2-686
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
Floating point math is not exact. 4.77 * 100 cannot be accurately
represented so
it ends up being 476. and when you cast that to an
integer the way
you are doing you get 476. You can read more about it here:
http://en.wikipedia.org/wiki/IEEE_754-2008
In your case add a round() to the appropriate precision on your floating
point
operation.
Previous Comments:
[2011-02-24 18:06:37] mallsbill at gmail dot com
Description:
---
>From manual page: http://www.php.net/function.sprintf#Description
---
with some integer obtain after an operation from a float, sprintf('%d',
$val) return a different value
Test script:
---
$var1 = 4.77*100;
echo $var2 = sprintf("%d", $var1);
Expected result:
should return 477
Actual result:
--
return 476
works when cast in string
$var1 = 4.77*100;
echo $var2 = sprintf("%d", (string)$var1);
--
Edit this bug report at http://bugs.php.net/bug.php?id=54094&edit=1
Bug #54093 [Opn->Wfx]: problem error process string
Edit report at http://bugs.php.net/bug.php?id=54093&edit=1
ID: 54093
Updated by: ras...@php.net
Reported by:akbar6393222 at yahoo dot com
Summary:problem error process string
-Status: Open
+Status: Wont fix
Type: Bug
Package:*Regular Expressions
Operating System: WinXp, Linux
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
One of the many reasons we deprecated the ereg library and thus the
ereg_*
functions. Use:
preg_replace("/\n/"," ","\0R\0e\0g\0 \0a\0s\0k\0e\0s\0");
Previous Comments:
[2011-02-24 17:53:49] akbar6393222 at yahoo dot com
Description:
# php -ver
PHP 5.2.17 (cli) (built: Jan 7 2011 11:12:15)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend
Technologies
echo ereg_replace("\n"," ","\0R\0e\0g\0 \0a\0s\0k\0e\0s\0");
produce nothing
Test script:
---
echo ereg_replace("\n"," ","\0R\0e\0g\0 \0a\0s\0k\0e\0s\0");
Expected result:
"\0R\0e\0g\0 \0a\0s\0k\0e\0s\0"
Actual result:
--
null
--
Edit this bug report at http://bugs.php.net/bug.php?id=54093&edit=1
[PHP-BUG] Bug #54094 [NEW]: Sprintf change integer with %d
From:
Operating system: Linux debian 2.6.26-2-686
PHP version: 5.2.17
Package: Strings related
Bug Type: Bug
Bug description:Sprintf change integer with %d
Description:
---
>From manual page: http://www.php.net/function.sprintf#Description
---
with some integer obtain after an operation from a float, sprintf('%d',
$val) return a different value
Test script:
---
$var1 = 4.77*100;
echo $var2 = sprintf("%d", $var1);
Expected result:
should return 477
Actual result:
--
return 476
works when cast in string
$var1 = 4.77*100;
echo $var2 = sprintf("%d", (string)$var1);
--
Edit bug report at http://bugs.php.net/bug.php?id=54094&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54094&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54094&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54094&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54094&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54094&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54094&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54094&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54094&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54094&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54094&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54094&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54094&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54094&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54094&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54094&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54094&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54094&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54094&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54094&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54094&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54094&r=mysqlcfg
[PHP-BUG] Bug #54093 [NEW]: problem error process string
From:
Operating system: WinXp, Linux
PHP version: 5.2.17
Package: *Regular Expressions
Bug Type: Bug
Bug description:problem error process string
Description:
# php -ver
PHP 5.2.17 (cli) (built: Jan 7 2011 11:12:15)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend
Technologies
echo ereg_replace("\n"," ","\0R\0e\0g\0 \0a\0s\0k\0e\0s\0");
produce nothing
Test script:
---
echo ereg_replace("\n"," ","\0R\0e\0g\0 \0a\0s\0k\0e\0s\0");
Expected result:
"\0R\0e\0g\0 \0a\0s\0k\0e\0s\0"
Actual result:
--
null
--
Edit bug report at http://bugs.php.net/bug.php?id=54093&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54093&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54093&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54093&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54093&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54093&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54093&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54093&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54093&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54093&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54093&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54093&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54093&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54093&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54093&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54093&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54093&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54093&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54093&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54093&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54093&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54093&r=mysqlcfg
Bug #54092 [Opn]: Segmentation fault when using FTP proxy
Edit report at http://bugs.php.net/bug.php?id=54092&edit=1 ID: 54092 User updated by:daniel dot buschke at nextiraone dot de Reported by:daniel dot buschke at nextiraone dot de Summary:Segmentation fault when using FTP proxy Status: Open Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:5.2.17 Block user comment: N Private report: N New Comment: Just for history: php -v PHP 5.3.6RC2-dev (cli) (built: Feb 24 2011 17:17:30) (DEBUG) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies Previous Comments: [2011-02-24 17:31:07] daniel dot buschke at nextiraone dot de BackTrace of 5.3-latest: #0 0x08394b84 in _php_stream_write_filtered (stream=0xca0, buf=0x87431c6 "QUIT\r\n", count=6, flags=0) at /usr/src/php5.3-201102241530/main/streams/streams.c:1001 #1 0x08394d24 in _php_stream_write (stream=0xca0, buf=0x87431c6 "QUIT\r\n", count=6) at /usr/src/php5.3-201102241530/main/streams/streams.c:1067 #2 0x0834cdc0 in php_stream_ftp_stream_close (wrapper=0x87768e8, stream=0xd10) at /usr/src/php5.3-201102241530/ext/standard/ftp_fopen_wrapper.c:120 #3 0x083938f3 in _php_stream_free (stream=0xd10, close_options=11) at /usr/src/php5.3-201102241530/main/streams/streams.c:376 #4 0x0839591f in stream_resource_regular_dtor (rsrc=0xe14) at /usr/src/php5.3-201102241530/main/streams/streams.c:1433 #5 0x083f715b in list_entry_destructor (ptr=0xe14) at /usr/src/php5.3-201102241530/Zend/zend_list.c:184 #6 0x083f47fe in zend_hash_del_key_or_index (ht=0x878e42c, arKey=0x0, nKeyLength=0, h=5, flag=1) at /usr/src/php5.3-201102241530/Zend/zend_hash.c:500 #7 0x083f6e49 in _zend_list_delete (id=5) at /usr/src/php5.3-201102241530/Zend/zend_list.c:58 #8 0x08300d78 in zif_fclose (ht=1, return_value=0x4f8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /usr/src/php5.3-201102241530/ext/standard/file.c:957 #9 0x084145de in zend_do_fcall_common_helper_SPEC (execute_data=0x88b5258) at /usr/src/php5.3-201102241530/Zend/zend_vm_execute.h:316 #10 0x08418122 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x88b5258) at /usr/src/php5.3-201102241530/Zend/zend_vm_execute.h:1606 #11 0x08413c7b in execute (op_array=0x8887010) at /usr/src/php5.3-201102241530/Zend/zend_vm_execute.h:107 #12 0x083e6f23 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php5.3-201102241530/Zend/zend.c:1194 #13 0x0837de64 in php_execute_script (primary_file=0xb12c) at /usr/src/php5.3-201102241530/main/main.c:2268 #14 0x084aa2f8 in main (argc=2, argv=0xb2a4) at /usr/src/php5.3-201102241530/sapi/cli/php_cli.c:1193 [2011-02-24 17:14:33] daniel dot buschke at nextiraone dot de Hi, PHP 5.3(!) is compiling with --enable-debug and --enable-ftp. Hope that's enough. Our test machine is not the fastest one ;-) But I am confused about 5.3. I think using 5.2-latest would be a better idea?! regards Daniel [2011-02-24 17:06:18] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2011-02-24 17:02:16] daniel dot buschke at nextiraone dot de BackTrace (without debug symbols, hope it is usefull): #0 0x082c9780 in ?? () #1 0x08286b4e in ?? () #2 0x082c9c54 in _php_stream_free () #3 0x082c9e1b in ?? () #4 0x08303a2c in list_entry_destructor () #5 0x08301288 in zend_hash_del_key_or_index () #6 0x08303cc0 in _zend_list_delete () #7 0x0824cc6d in zif_fclose () #8 0x08314381 in execute_internal () #9 0xb705e672 in xdebug_execute_internal () from /usr/lib/php5.2/lib/extensions/no-debug-non-zts-20060613/xdebug.so #10 0x0832a071 in ?? () #11 0x08318420 in execute () #12 0xb705e324 in xdebug_execute () from /usr/lib/php5.2/lib/extensions/no-debug-non-zts-20060613/xdebug.so #13 0x082f6d0c in zend_execute_scripts () #14 0x082b5724 in php_execute_script () #15 0x0836f023 in main () [2011-02-24 16:47:50] daniel dot buschke at nextiraone dot de Description: Hi, either the Bug (#42420) is still alive or it is re-alive. But I am not allowed to re-open it. So sorry for opening a dup. php -v says: -- PHP 5.2.17-pl0-gentoo (cli) (built: Feb 18 2011 10:01:58) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans -- The PHP
Bug #54092 [Opn]: Segmentation fault when using FTP proxy
Edit report at http://bugs.php.net/bug.php?id=54092&edit=1 ID: 54092 User updated by:daniel dot buschke at nextiraone dot de Reported by:daniel dot buschke at nextiraone dot de Summary:Segmentation fault when using FTP proxy Status: Open Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:5.2.17 Block user comment: N Private report: N New Comment: BackTrace of 5.3-latest: #0 0x08394b84 in _php_stream_write_filtered (stream=0xca0, buf=0x87431c6 "QUIT\r\n", count=6, flags=0) at /usr/src/php5.3-201102241530/main/streams/streams.c:1001 #1 0x08394d24 in _php_stream_write (stream=0xca0, buf=0x87431c6 "QUIT\r\n", count=6) at /usr/src/php5.3-201102241530/main/streams/streams.c:1067 #2 0x0834cdc0 in php_stream_ftp_stream_close (wrapper=0x87768e8, stream=0xd10) at /usr/src/php5.3-201102241530/ext/standard/ftp_fopen_wrapper.c:120 #3 0x083938f3 in _php_stream_free (stream=0xd10, close_options=11) at /usr/src/php5.3-201102241530/main/streams/streams.c:376 #4 0x0839591f in stream_resource_regular_dtor (rsrc=0xe14) at /usr/src/php5.3-201102241530/main/streams/streams.c:1433 #5 0x083f715b in list_entry_destructor (ptr=0xe14) at /usr/src/php5.3-201102241530/Zend/zend_list.c:184 #6 0x083f47fe in zend_hash_del_key_or_index (ht=0x878e42c, arKey=0x0, nKeyLength=0, h=5, flag=1) at /usr/src/php5.3-201102241530/Zend/zend_hash.c:500 #7 0x083f6e49 in _zend_list_delete (id=5) at /usr/src/php5.3-201102241530/Zend/zend_list.c:58 #8 0x08300d78 in zif_fclose (ht=1, return_value=0x4f8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /usr/src/php5.3-201102241530/ext/standard/file.c:957 #9 0x084145de in zend_do_fcall_common_helper_SPEC (execute_data=0x88b5258) at /usr/src/php5.3-201102241530/Zend/zend_vm_execute.h:316 #10 0x08418122 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x88b5258) at /usr/src/php5.3-201102241530/Zend/zend_vm_execute.h:1606 #11 0x08413c7b in execute (op_array=0x8887010) at /usr/src/php5.3-201102241530/Zend/zend_vm_execute.h:107 #12 0x083e6f23 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php5.3-201102241530/Zend/zend.c:1194 #13 0x0837de64 in php_execute_script (primary_file=0xb12c) at /usr/src/php5.3-201102241530/main/main.c:2268 #14 0x084aa2f8 in main (argc=2, argv=0xb2a4) at /usr/src/php5.3-201102241530/sapi/cli/php_cli.c:1193 Previous Comments: [2011-02-24 17:14:33] daniel dot buschke at nextiraone dot de Hi, PHP 5.3(!) is compiling with --enable-debug and --enable-ftp. Hope that's enough. Our test machine is not the fastest one ;-) But I am confused about 5.3. I think using 5.2-latest would be a better idea?! regards Daniel [2011-02-24 17:06:18] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2011-02-24 17:02:16] daniel dot buschke at nextiraone dot de BackTrace (without debug symbols, hope it is usefull): #0 0x082c9780 in ?? () #1 0x08286b4e in ?? () #2 0x082c9c54 in _php_stream_free () #3 0x082c9e1b in ?? () #4 0x08303a2c in list_entry_destructor () #5 0x08301288 in zend_hash_del_key_or_index () #6 0x08303cc0 in _zend_list_delete () #7 0x0824cc6d in zif_fclose () #8 0x08314381 in execute_internal () #9 0xb705e672 in xdebug_execute_internal () from /usr/lib/php5.2/lib/extensions/no-debug-non-zts-20060613/xdebug.so #10 0x0832a071 in ?? () #11 0x08318420 in execute () #12 0xb705e324 in xdebug_execute () from /usr/lib/php5.2/lib/extensions/no-debug-non-zts-20060613/xdebug.so #13 0x082f6d0c in zend_execute_scripts () #14 0x082b5724 in php_execute_script () #15 0x0836f023 in main () [2011-02-24 16:47:50] daniel dot buschke at nextiraone dot de Description: Hi, either the Bug (#42420) is still alive or it is re-alive. But I am not allowed to re-open it. So sorry for opening a dup. php -v says: -- PHP 5.2.17-pl0-gentoo (cli) (built: Feb 18 2011 10:01:58) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans -- The PHP died with SegFault on two different machines with two different Proxies. regards Daniel Test script: --- ftp://pkg-shadow.alioth.debian.org/pub/pkg-shadow/shadow-4.1.4.3.tar.bz2'; $proxy = 'tcp://proxy:8080'; $opts = array( 'ftp' => array( 'proxy' => $proxy )
Bug #54092 [Fbk->Opn]: Segmentation fault when using FTP proxy
Edit report at http://bugs.php.net/bug.php?id=54092&edit=1
ID: 54092
User updated by:daniel dot buschke at nextiraone dot de
Reported by:daniel dot buschke at nextiraone dot de
Summary:Segmentation fault when using FTP proxy
-Status: Feedback
+Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Linux
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
Hi,
PHP 5.3(!) is compiling with --enable-debug and --enable-ftp. Hope
that's enough. Our test machine is not the fastest one ;-)
But I am confused about 5.3. I think using 5.2-latest would be a better
idea?!
regards
Daniel
Previous Comments:
[2011-02-24 17:06:18] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2011-02-24 17:02:16] daniel dot buschke at nextiraone dot de
BackTrace (without debug symbols, hope it is usefull):
#0 0x082c9780 in ?? ()
#1 0x08286b4e in ?? ()
#2 0x082c9c54 in _php_stream_free ()
#3 0x082c9e1b in ?? ()
#4 0x08303a2c in list_entry_destructor ()
#5 0x08301288 in zend_hash_del_key_or_index ()
#6 0x08303cc0 in _zend_list_delete ()
#7 0x0824cc6d in zif_fclose ()
#8 0x08314381 in execute_internal ()
#9 0xb705e672 in xdebug_execute_internal () from
/usr/lib/php5.2/lib/extensions/no-debug-non-zts-20060613/xdebug.so
#10 0x0832a071 in ?? ()
#11 0x08318420 in execute ()
#12 0xb705e324 in xdebug_execute () from
/usr/lib/php5.2/lib/extensions/no-debug-non-zts-20060613/xdebug.so
#13 0x082f6d0c in zend_execute_scripts ()
#14 0x082b5724 in php_execute_script ()
#15 0x0836f023 in main ()
[2011-02-24 16:47:50] daniel dot buschke at nextiraone dot de
Description:
Hi,
either the Bug (#42420) is still alive or it is re-alive. But I am not
allowed to re-open it. So sorry for opening a dup.
php -v says:
--
PHP 5.2.17-pl0-gentoo (cli) (built: Feb 18 2011 10:01:58)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
--
The PHP died with SegFault on two different machines with two different
Proxies.
regards
Daniel
Test script:
---
ftp://pkg-shadow.alioth.debian.org/pub/pkg-shadow/shadow-4.1.4.3.tar.bz2';
$proxy = 'tcp://proxy:8080';
$opts = array(
'ftp' => array(
'proxy' => $proxy
)
);
$context = stream_context_create($opts);
stream_context_set_params($context, array());
$fh = fopen($uri, 'r', false, $context);
while (!feof($fh)) {
echo "foo\n";
fread($fh, 4 * 1024);
}
fclose($fh);
?>
Expected result:
many foos ;-) and no segmentation fault
Actual result:
--
many foos and segementation fault
--
Edit this bug report at http://bugs.php.net/bug.php?id=54092&edit=1
Bug #51051 [Com]: DateTime modify wrong result with DST change
Edit report at http://bugs.php.net/bug.php?id=51051&edit=1
ID: 51051
Comment by: j dot ek at gmx dot net
Reported by:mehdi dot rande at aliasource dot fr
Summary:DateTime modify wrong result with DST change
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.3.1
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
Think I found a related issue, reproduce it with:
setTimestamp(1288483200);
// but returns timestamp of 2010-10-31T02:00:00+0100
echo $dt->getTimestamp(); // outputs 1288486800
?>
WinXP 32, PHP 5.3.2 (cli) (built: Mar 3 2010 20:36:54)
Previous Comments:
[2010-12-25 02:46:45] danielc at analysisandsolutions dot com
DateTime::diff() is similarly afflicted with daylight/standard change
over issues. Naturally, diff/add/sub all need to be in sync so
intervals returned by diff can be passed to add/sub and produce the
original datetime.
[2010-12-25 02:27:22] dani...@php.net
I just attached a test script that covers issues in the spring and fall.
[2010-12-25 02:26:16] dani...@php.net
The following patch has been added/updated:
Patch Name: bug51051test.php.txt
Revision: 1293240376
URL:
http://bugs.php.net/patch-display.php?bug=51051&patch=bug51051test.php.txt&revision=1293240376
[2010-08-24 14:34:22] glennpratt+php at gmail dot com
Correction for the Expected result above.
Expected Result
---
2011-03-13T03:00:00-05:00 America/Chicago
2011-03-13T01:58:00-06:00 America/Chicago
[2010-08-24 00:04:28] glennpratt at gmail dot com
Same issue here on PHP 5.3.2
format('c e'));
$date->modify('-2 minutes');
print($date->format('c e'));
?>
Actual Result
-
2011-03-13T03:00:00-05:00 America/Chicago
2011-03-13T03:58:00-05:00 America/Chicago
Expected Result
---
2011-03-13T03:00:00-05:00 America/Chicago
2011-03-13T01:58:00-05:00 America/Chicago
Comparison: Ruby time library
-
irb(main):015:0> date = Time.parse('2011-03-13T03:00:00 in CST')
=> Sun Mar 13 03:00:00 -0500 2011
irb(main):016:0> date - 120
=> Sun Mar 13 01:58:00 -0600 2011
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=51051
--
Edit this bug report at http://bugs.php.net/bug.php?id=51051&edit=1
Bug #54092 [Opn->Fbk]: Segmentation fault when using FTP proxy
Edit report at http://bugs.php.net/bug.php?id=54092&edit=1
ID: 54092
Updated by: paj...@php.net
Reported by:daniel dot buschke at nextiraone dot de
Summary:Segmentation fault when using FTP proxy
-Status: Open
+Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Linux
PHP Version:5.2.17
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/
Previous Comments:
[2011-02-24 17:02:16] daniel dot buschke at nextiraone dot de
BackTrace (without debug symbols, hope it is usefull):
#0 0x082c9780 in ?? ()
#1 0x08286b4e in ?? ()
#2 0x082c9c54 in _php_stream_free ()
#3 0x082c9e1b in ?? ()
#4 0x08303a2c in list_entry_destructor ()
#5 0x08301288 in zend_hash_del_key_or_index ()
#6 0x08303cc0 in _zend_list_delete ()
#7 0x0824cc6d in zif_fclose ()
#8 0x08314381 in execute_internal ()
#9 0xb705e672 in xdebug_execute_internal () from
/usr/lib/php5.2/lib/extensions/no-debug-non-zts-20060613/xdebug.so
#10 0x0832a071 in ?? ()
#11 0x08318420 in execute ()
#12 0xb705e324 in xdebug_execute () from
/usr/lib/php5.2/lib/extensions/no-debug-non-zts-20060613/xdebug.so
#13 0x082f6d0c in zend_execute_scripts ()
#14 0x082b5724 in php_execute_script ()
#15 0x0836f023 in main ()
[2011-02-24 16:47:50] daniel dot buschke at nextiraone dot de
Description:
Hi,
either the Bug (#42420) is still alive or it is re-alive. But I am not
allowed to re-open it. So sorry for opening a dup.
php -v says:
--
PHP 5.2.17-pl0-gentoo (cli) (built: Feb 18 2011 10:01:58)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
--
The PHP died with SegFault on two different machines with two different
Proxies.
regards
Daniel
Test script:
---
ftp://pkg-shadow.alioth.debian.org/pub/pkg-shadow/shadow-4.1.4.3.tar.bz2';
$proxy = 'tcp://proxy:8080';
$opts = array(
'ftp' => array(
'proxy' => $proxy
)
);
$context = stream_context_create($opts);
stream_context_set_params($context, array());
$fh = fopen($uri, 'r', false, $context);
while (!feof($fh)) {
echo "foo\n";
fread($fh, 4 * 1024);
}
fclose($fh);
?>
Expected result:
many foos ;-) and no segmentation fault
Actual result:
--
many foos and segementation fault
--
Edit this bug report at http://bugs.php.net/bug.php?id=54092&edit=1
Bug #54092 [Opn]: Segmentation fault when using FTP proxy
Edit report at http://bugs.php.net/bug.php?id=54092&edit=1
ID: 54092
User updated by:daniel dot buschke at nextiraone dot de
Reported by:daniel dot buschke at nextiraone dot de
Summary:Segmentation fault when using FTP proxy
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Linux
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
BackTrace (without debug symbols, hope it is usefull):
#0 0x082c9780 in ?? ()
#1 0x08286b4e in ?? ()
#2 0x082c9c54 in _php_stream_free ()
#3 0x082c9e1b in ?? ()
#4 0x08303a2c in list_entry_destructor ()
#5 0x08301288 in zend_hash_del_key_or_index ()
#6 0x08303cc0 in _zend_list_delete ()
#7 0x0824cc6d in zif_fclose ()
#8 0x08314381 in execute_internal ()
#9 0xb705e672 in xdebug_execute_internal () from
/usr/lib/php5.2/lib/extensions/no-debug-non-zts-20060613/xdebug.so
#10 0x0832a071 in ?? ()
#11 0x08318420 in execute ()
#12 0xb705e324 in xdebug_execute () from
/usr/lib/php5.2/lib/extensions/no-debug-non-zts-20060613/xdebug.so
#13 0x082f6d0c in zend_execute_scripts ()
#14 0x082b5724 in php_execute_script ()
#15 0x0836f023 in main ()
Previous Comments:
[2011-02-24 16:47:50] daniel dot buschke at nextiraone dot de
Description:
Hi,
either the Bug (#42420) is still alive or it is re-alive. But I am not
allowed to re-open it. So sorry for opening a dup.
php -v says:
--
PHP 5.2.17-pl0-gentoo (cli) (built: Feb 18 2011 10:01:58)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
--
The PHP died with SegFault on two different machines with two different
Proxies.
regards
Daniel
Test script:
---
ftp://pkg-shadow.alioth.debian.org/pub/pkg-shadow/shadow-4.1.4.3.tar.bz2';
$proxy = 'tcp://proxy:8080';
$opts = array(
'ftp' => array(
'proxy' => $proxy
)
);
$context = stream_context_create($opts);
stream_context_set_params($context, array());
$fh = fopen($uri, 'r', false, $context);
while (!feof($fh)) {
echo "foo\n";
fread($fh, 4 * 1024);
}
fclose($fh);
?>
Expected result:
many foos ;-) and no segmentation fault
Actual result:
--
many foos and segementation fault
--
Edit this bug report at http://bugs.php.net/bug.php?id=54092&edit=1
[PHP-BUG] Bug #54092 [NEW]: Segmentation fault when using FTP proxy
From:
Operating system: Linux
PHP version: 5.2.17
Package: Reproducible crash
Bug Type: Bug
Bug description:Segmentation fault when using FTP proxy
Description:
Hi,
either the Bug (#42420) is still alive or it is re-alive. But I am not
allowed to re-open it. So sorry for opening a dup.
php -v says:
--
PHP 5.2.17-pl0-gentoo (cli) (built: Feb 18 2011 10:01:58)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
--
The PHP died with SegFault on two different machines with two different
Proxies.
regards
Daniel
Test script:
---
ftp://pkg-shadow.alioth.debian.org/pub/pkg-shadow/shadow-4.1.4.3.tar.bz2';
$proxy = 'tcp://proxy:8080';
$opts = array(
'ftp' => array(
'proxy' => $proxy
)
);
$context = stream_context_create($opts);
stream_context_set_params($context, array());
$fh = fopen($uri, 'r', false, $context);
while (!feof($fh)) {
echo "foo\n";
fread($fh, 4 * 1024);
}
fclose($fh);
?>
Expected result:
many foos ;-) and no segmentation fault
Actual result:
--
many foos and segementation fault
--
Edit bug report at http://bugs.php.net/bug.php?id=54092&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54092&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54092&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54092&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54092&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54092&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54092&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54092&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54092&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54092&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54092&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54092&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54092&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54092&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54092&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54092&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54092&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54092&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54092&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54092&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54092&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54092&r=mysqlcfg
Bug #54091 [Com]: class_exists fail with a class name alias
Edit report at http://bugs.php.net/bug.php?id=54091&edit=1
ID: 54091
Comment by: jinmoku at hotmail dot com
Reported by:jinmoku at hotmail dot com
Summary:class_exists fail with a class name alias
Status: Bogus
Type: Bug
Package:Class/Object related
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Sorry, there is nothing about this in the documentation,
how I can make an instance of this class if it's doesn't exists ???
it's not logical
Previous Comments:
[2011-02-24 16:00:04] johan...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
http://php.net/manual/en/language.namespaces.dynamic.php
[2011-02-24 15:39:51] jinmoku at hotmail dot com
Description:
class_exists fail with a class name alias, ReflectionClass too
Test script:
---
use \stdClass as object;
var_dump(new object);
var_dump(class_exists('object'));
Expected result:
object(stdClass)#1 (0) {
}
bool(true)
Actual result:
--
object(stdClass)#1 (0) {
}
bool(false)
--
Edit this bug report at http://bugs.php.net/bug.php?id=54091&edit=1
Bug #50547 [Com]: SoapServer Fatal errror in WSDL mode
Edit report at http://bugs.php.net/bug.php?id=50547&edit=1 ID: 50547 Comment by: mdekrijger at e-sites dot nl Reported by:rsumibcay at reddoor dot biz Summary:SoapServer Fatal errror in WSDL mode Status: Open Type: Bug Package:SOAP related Operating System: Ubuntu Linux PHP Version:5.2.12 Block user comment: N Private report: N New Comment: Xdebug might be the problem. When using xdebug_disable() before calling the handle() method, the server responds with a proper SOAP message which says that something went wrong. Previous Comments: [2011-02-24 09:54:31] mdekrijger at e-sites dot nl Does anyone have an alternative solution for this problem? (while this bug remains open?) We really want to provide some information about the wrong type in the return soap response. So implementing our SOAP services would be a much easier job. [2010-02-01 09:48:05] jitka at darbujanova dot cz I can confirm this. (http://bugs.php.net/bug.php?id=50895) [2009-12-21 20:18:01] rsumibcay at reddoor dot biz Description: SoapServer dies with fatal error in WSDL mode when a soap argument is a ComplexType with a member defined as int in the XSD, but the member value is passed as a non-numeric string. Reproduce code: --- 1. Define a ComplexType with an int data member: http://crkt190.reddoor.biz/fatalerror/complex_types.xsd 2. Define a WSDL that uses the ComplexType as an argument to the soap function: http://crkt190.reddoor.biz/fatalerror/fatalerror.wsdl 3. Create a soap envelope with a non-numeric string as the value for the int data member: http://crkt190.reddoor.biz/fatalerror/fatalerror-soap-envelope.xml 4. Make a soap request using the soap envelope in step 3. Expected result: The SoapServer should not die with a fatal error. The SoapServer should respond with a SoapFault, or let the call pass through so the business logic (mapped handler) can do validation and handle the error appropriately. Actual result: -- 500 HTTP response from server. The HTTP response body contains an error message and stack trace. Fatal error: SOAP-ERROR: Encoding Violation of encoding rules in ... -- Edit this bug report at http://bugs.php.net/bug.php?id=50547&edit=1
Bug #54091 [Opn->Bgs]: class_exists fail with a class name alias
Edit report at http://bugs.php.net/bug.php?id=54091&edit=1
ID: 54091
Updated by: johan...@php.net
Reported by:jinmoku at hotmail dot com
Summary:class_exists fail with a class name alias
-Status: Open
+Status: Bogus
Type: Bug
Package:Class/Object related
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
http://php.net/manual/en/language.namespaces.dynamic.php
Previous Comments:
[2011-02-24 15:39:51] jinmoku at hotmail dot com
Description:
class_exists fail with a class name alias, ReflectionClass too
Test script:
---
use \stdClass as object;
var_dump(new object);
var_dump(class_exists('object'));
Expected result:
object(stdClass)#1 (0) {
}
bool(true)
Actual result:
--
object(stdClass)#1 (0) {
}
bool(false)
--
Edit this bug report at http://bugs.php.net/bug.php?id=54091&edit=1
[PHP-BUG] Bug #54091 [NEW]: class_exists fail with a class name alias
From:
Operating system:
PHP version: 5.3.5
Package: Class/Object related
Bug Type: Bug
Bug description:class_exists fail with a class name alias
Description:
class_exists fail with a class name alias, ReflectionClass too
Test script:
---
use \stdClass as object;
var_dump(new object);
var_dump(class_exists('object'));
Expected result:
object(stdClass)#1 (0) {
}
bool(true)
Actual result:
--
object(stdClass)#1 (0) {
}
bool(false)
--
Edit bug report at http://bugs.php.net/bug.php?id=54091&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54091&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54091&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54091&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54091&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54091&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54091&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54091&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54091&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54091&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54091&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54091&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54091&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54091&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54091&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54091&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54091&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54091&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54091&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54091&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54091&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54091&r=mysqlcfg
Bug #53695 [Com]: Bugs are not outputed when using php-fpm
Edit report at http://bugs.php.net/bug.php?id=53695&edit=1 ID: 53695 Comment by: arnoschn at gmail dot com Reported by:szoftos at freemail dot hu Summary:Bugs are not outputed when using php-fpm Status: Bogus Type: Bug Package:FPM related Operating System: FreeBSD PHP Version:5.3.5 Assigned To:fat Block user comment: N Private report: N New Comment: Hello, I ran into the same problem. Setting this in your php-fpm.conf helps: php_admin_value[error_log] = "/var/log/php-fpm-errors.log" Then I saw the errors still showing up in nginx, so I looked at the user I was using to run nginx. It is "www-data". So I created the file "/var/log/php-fpm-errors.log" and gave permissions to "www-data" to write to it. Solved. Previous Comments: [2011-02-01 15:38:42] szoftos at freemail dot hu Okay, this is still a bug, and not a bogus one. I changed the configuration, right now these are all the config lines for the given virtualhost: [virtualhost] chroot = /usr/local/www/ chdir = /vhosts/virtualhost/htdocs listen = /usr/local/www/var/run/sockets/virtualhost.php.sock listen.owner = www listen.group = www listen.mode = 0660 user = username group = groupname pm = dynamic pm.max_children = 50 pm.start_servers = 1 pm.min_spare_servers = 1 pm.max_spare_servers = 5 pm.max_requests = 200 request_terminate_timeout = 1m request_slowlog_timeout = 30s slowlog = /var/log/php-fpm-slow.log catch_workers_output = yes php_admin_flag[register_globals] = off php_admin_value[variables_order] = GPCES php_admin_value[date.timezone] = Europe/Budapest php_admin_flag[always_populate_raw_post_data] = on php_admin_value[open_basedir] = /vhosts/virtualhost/htdocs php_admin_value[doc_root] = /vhosts/virtualhost/htdocs php_admin_value[upload_tmp_dir] = /vhosts/virtualhost/htdocs/tmp php_admin_flag[zlib.output_compression] = on php_admin_flag[safe_mode] = on php_admin_value[disable_functions] = escapeshellarg,escapeshellcmd,exec,passthru,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,shell_exec,system php_admin_flag[magic_quotes_gpc] = on php_admin_flag[magic_quotes_runtime] = off php_admin_flag[magic_quotes_sybase] = off php_admin_value[session.save_path] = /vhosts/virtualhost/htdocs/admin/tmp php_admin_value[safe_mode_exec_dir] = /vhosts/virtualhost/safe_mode_exec_dir php_admin_value[memory_limit] = 32M php_admin_flag[short_open_tag] = on php_admin_value[default_charset] = UTF-8 php_admin_value[error_reporting] = E_ALL & ~E_NOTICE php_admin_flag[display_errors] = On php_admin_flag[display_startup_errors] = On As you can see, all without quotes now. The mentioned example code runs now with the same results: no output at all, when commenting out the phpinfo() from it. Please reopen the bug, as this is _not_ a bogus report. Cheers, Laszlo [2011-01-29 15:10:14] szoftos at freemail dot hu Ah, thank you, i'll try the configuration without quotes. However, I was thinking that the php_admin_value should be set in the same way as for the mod_php module in apache. In there, one has to use quotes. Maybe this should be a remark for php-fpm's config. [2011-01-29 12:11:42] f...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php You must not use double (or simple) quotes arround E_ALL as constants are interpreted by the php core ini parser (quotes inhibits this conversion) php_admin_value[error_reporting] = "E_ALL" is not well understood. php_admin_value[error_reporting] = E_ALL is correctely converted. [2011-01-10 08:16:48] f...@php.net Are you sure it's related to php fpm ? Here is the content of a test file: Calling from CLI: nothing, white page Calling from FPM: the same Here is the content of another test file: Calling from CLI: Fatal error: Call to undefined function nofunc() in /html/error.php on line 1 Calling from FPM: Fatal error: Call to undefined function nofunc() in /html/error.php on line 1 The behaviour is the same with CLI or FPM. @kalle: can you reproduce the problem ? [2011-01-10 01:41:19] ka...@php.net Hmm, I wonder if php-fpm is actually parsing the error_reporting constants with their numeric bitfields to mask it correctly, could be wrong here. Any thoughts fat? --
Req #54086 [Com]: Add "default character set" option for mysql connection
Edit report at http://bugs.php.net/bug.php?id=54086&edit=1 ID: 54086 Comment by: cavo at ynet dot sk Reported by:cavo at ynet dot sk Summary:Add "default character set" option for mysql connection Status: Duplicate Type: Feature/Change Request Package:MySQLi related Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Aaa, I see. Your response to Request #12213 from 2007-10-09. I don't know about this until now. It's not in any example on web, I recomend to make one. Thank's for that. Previous Comments: [2011-02-24 14:21:37] carsten_sttgt at gmx dot de @cavo > There is actually 2 different solutions for this problem (mysqli [mysql]): With mysqli I would use a 3rd: | @aharvey > Johannes's reasoning in request #44118 seems sound to me. Closing. I guess this info is outdated. If mysql(i) is build against mysqlnd, the charset is automatically set to the server default character set. A build against libmysql is using latin1 as default. Thus people should set the client charset every time in their script (especially if they don't know how PHP is build or the MySQL setup), because you can't disable this automatic. Regards, Carsten [2011-02-24 13:21:24] ahar...@php.net Johannes's reasoning in request #44118 seems sound to me. Closing. [2011-02-24 11:37:40] cavo at ynet dot sk Description: I'm voting for http://bugs.php.net/bug.php?id=44118 Here is my explanation: This is actually not implemented feature of mysql protocol (character set handshake), related to both mysql and mysqli PHP extensions causing buggy behavior. While connecting, several packets exchanges between server and client. After succesful TCP handshake, server sent "Server Greeting" message (packet) where server's default character set is specified (for example "Charset: utf8 COLLATE utf8_general_ci" - 0x21). Then "Login Request" message follows from client's side specifying character set which will be used for connection. Here is problem - PHP's both mysql and mysqli extension send always "Charset: latin1 COLLATE latin1_swedish_ci" - 0x08. But PHP don't look at query responses in way they are encoded in latin1. But mysql database must re-encode data from charset used for table field to latin1. There is actually 2 different solutions for this problem (mysqli [mysql]): 1. solution: executing mysqli::set_charset [mysql_set_charset] right after mysqli::__construct [mysql_ connect]. But this causes redundant query sent to server (for example: SET NAMES "utf8"); 2. solution: configure mysql server with option "character-set-client-handshake = false" which makes MySQL behave like MySQL 4.0 and ignore character set sent by client. I think there should be MySQL/MySQLi Configuration Option like: mysqli.default_character_set = utf8 mysql.default_character_set = utf8 This will support mysql's character set handshake without executing redundant queries. This option is also possible in mysql cli interface as "--default-character-set=utf8" Here is Login Request message caught by wireshark for code: (character set in "[]" brackets) 3a 00 00 01 85 a2 02 00 00 00 00 40[08]00 00 00 :..@ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020 00 00 00 00 72 6f 6f 74 00 14 0c 79 bf 1a bd d0 root...y 0030 36 0a 21 fc 6d e5 f0 42 27 89 9f 32 e5 956.!.m..B'..2.. Here is Login Request message caught by wireshark for code (cli): $ mysql -u root -p -h 127.0.0.1 --default-character-set=utf8 (character set in "[]" brackets) 3a 00 00 01 85 a6 03 00 00 00 00 01[21]00 00 00 :...!... 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020 00 00 00 00 72 6f 6f 74 00 14 97 58 9b 0a 65 b8 root...X..e. 0030 0c 67 dc 8a 82 28 51 a5 1f 1b 08 28 c5 c2.g...(Q(.. Test script: --- cli: mysql -u root -p -h 127.0.0.1 --default-character-set=utf8 -- Edit this bug report at http://bugs.php.net/bug.php?id=54086&edit=1
Req #54086 [Com]: Add "default character set" option for mysql connection
Edit report at http://bugs.php.net/bug.php?id=54086&edit=1 ID: 54086 Comment by: carsten_sttgt at gmx dot de Reported by:cavo at ynet dot sk Summary:Add "default character set" option for mysql connection Status: Duplicate Type: Feature/Change Request Package:MySQLi related Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: @cavo > There is actually 2 different solutions for this problem (mysqli [mysql]): With mysqli I would use a 3rd: | @aharvey > Johannes's reasoning in request #44118 seems sound to me. Closing. I guess this info is outdated. If mysql(i) is build against mysqlnd, the charset is automatically set to the server default character set. A build against libmysql is using latin1 as default. Thus people should set the client charset every time in their script (especially if they don't know how PHP is build or the MySQL setup), because you can't disable this automatic. Regards, Carsten Previous Comments: [2011-02-24 13:21:24] ahar...@php.net Johannes's reasoning in request #44118 seems sound to me. Closing. [2011-02-24 11:37:40] cavo at ynet dot sk Description: I'm voting for http://bugs.php.net/bug.php?id=44118 Here is my explanation: This is actually not implemented feature of mysql protocol (character set handshake), related to both mysql and mysqli PHP extensions causing buggy behavior. While connecting, several packets exchanges between server and client. After succesful TCP handshake, server sent "Server Greeting" message (packet) where server's default character set is specified (for example "Charset: utf8 COLLATE utf8_general_ci" - 0x21). Then "Login Request" message follows from client's side specifying character set which will be used for connection. Here is problem - PHP's both mysql and mysqli extension send always "Charset: latin1 COLLATE latin1_swedish_ci" - 0x08. But PHP don't look at query responses in way they are encoded in latin1. But mysql database must re-encode data from charset used for table field to latin1. There is actually 2 different solutions for this problem (mysqli [mysql]): 1. solution: executing mysqli::set_charset [mysql_set_charset] right after mysqli::__construct [mysql_ connect]. But this causes redundant query sent to server (for example: SET NAMES "utf8"); 2. solution: configure mysql server with option "character-set-client-handshake = false" which makes MySQL behave like MySQL 4.0 and ignore character set sent by client. I think there should be MySQL/MySQLi Configuration Option like: mysqli.default_character_set = utf8 mysql.default_character_set = utf8 This will support mysql's character set handshake without executing redundant queries. This option is also possible in mysql cli interface as "--default-character-set=utf8" Here is Login Request message caught by wireshark for code: (character set in "[]" brackets) 3a 00 00 01 85 a2 02 00 00 00 00 40[08]00 00 00 :..@ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020 00 00 00 00 72 6f 6f 74 00 14 0c 79 bf 1a bd d0 root...y 0030 36 0a 21 fc 6d e5 f0 42 27 89 9f 32 e5 956.!.m..B'..2.. Here is Login Request message caught by wireshark for code (cli): $ mysql -u root -p -h 127.0.0.1 --default-character-set=utf8 (character set in "[]" brackets) 3a 00 00 01 85 a6 03 00 00 00 00 01[21]00 00 00 :...!... 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020 00 00 00 00 72 6f 6f 74 00 14 97 58 9b 0a 65 b8 root...X..e. 0030 0c 67 dc 8a 82 28 51 a5 1f 1b 08 28 c5 c2.g...(Q(.. Test script: --- cli: mysql -u root -p -h 127.0.0.1 --default-character-set=utf8 -- Edit this bug report at http://bugs.php.net/bug.php?id=54086&edit=1
Req #44118 [Com]: [PATCH] MySQL: Set connection charset via php.ini option
Edit report at http://bugs.php.net/bug.php?id=44118&edit=1
ID: 44118
Comment by: cavo at ynet dot sk
Reported by:slava_reg at nsys dot by
Summary:[PATCH] MySQL: Set connection charset via php.ini
option
Status: Wont fix
Type: Feature/Change Request
Package:MySQL related
Operating System: any
PHP Version:5.2.5
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
This is not about making application utf8 compatible. You can do this by
"set names" query. But it may be redundant. For example: All my database
is in utf8 encoding. All my pages have content-type utf8. All form posts
from clients are in utf8. All strings I process in application are utf8.
But what do I need to do right after I connect to database? - "set names
utf8;" Why? Because if I don't, db will re-encode all strings to latin1.
And PHP don't care. If I have 100 new connections to db per second, I
need to 100 times run that query. Why if client and server could
negotiate encoding in those 2 obliged packets? (
http://bugs.php.net/bug.php?id=54086 ). It's ok to set latin1 as default
character set used by client to not affect existing applications (I
believe mostly for those, who actualy don't know, what are they
doing..). But I think it's very useful to have option to set encoding
manualy via configuration option or in connect functions like:
mysql_connect('localhost', 'user', 'pwd', true,
MYSQL_CLIENT_ENCODING_UTF8);
Or am I somwhere wrong?
http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol#Client_Authentication_Packet
http://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_default-character-set
http://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_character-set-client-handshake
http://bugs.php.net/bug.php?id=54086
Previous Comments:
[2011-01-31 11:52:36] johan...@php.net
The application has to know the encoding being used, else some strange
things might happen. We have seen the trouble in having this globally
configurable when Gentoo decided to use Utf-8 for their MySQL
installations by default instead of MySQL's default. I doubt you can
make an application Utf-8 comaptible by just setting such a low-level
switch (it won't affect the HTTP Content-type header or HTML forms, thus
receiving data in a wrong encoding from the user, not re-encode it etc.)
[2011-01-06 16:19:52] u...@php.net
Not sure if this is really needed. It can be done in user land. Its a
bit of a convenience feature. Not many votes for it... Andrey,
Johannes...?
[2008-02-14 13:00:54] slava_reg at nsys dot by
Description:
Hi,
As I'm tired of patching various user-installed php-engines to work
correctly with newer MySQL versions (4.1.x +) that require connection
character set to be specified, I decided to solve the problem at the php
level.
So, I patched both mysql and mysqli extensions (based on an idea found
somewhere in internet).
Result is available at:
http://bubble.nsys.by/projects/patches/php/php-5.2.5-mysql-client-charset.patch
The patch introduces two more php.ini directives:
mysql.client_charset and
mysqli.client_charset
As those directives are optional, the patch shouldn't break any existing
functionality, but it could *really* help users who's native language is
not latin and who want to use some php-scripted engine with mysql
'out-of-the-box'.
Best,
Vladislav Bogdanov
--
Edit this bug report at http://bugs.php.net/bug.php?id=44118&edit=1
[PHP-BUG] Bug #54090 [NEW]: ReflectionClass::getStartLine reports wrong value for autoloaded classes.
From: Operating system: GNU/Linux (Fedora 14) PHP version: 5.3.5 Package: Reflection related Bug Type: Bug Bug description:ReflectionClass::getStartLine reports wrong value for autoloaded classes. Description: When a require_once call causes other files to be loaded, the ReflectionClass object of any of those classes loaded from an extra file via the __autoload method returns the classes' start line and end line incorrectly from the ReflectionClass::getStartLine() and ReflectionClass::getEndLine() methods. I think the start line and the end line values come from the class that caused the extra files to load. Expected result: The correct start line and end line values should be returned. -- Edit bug report at http://bugs.php.net/bug.php?id=54090&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54090&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54090&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54090&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54090&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54090&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54090&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54090&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54090&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54090&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54090&r=support Expected behavior: http://bugs.php.net/fix.php?id=54090&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54090&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54090&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54090&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54090&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54090&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54090&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54090&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54090&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54090&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54090&r=mysqlcfg
Bug #50902 [Com]: Segfault if date.timezone is not set and error_log is defined
Edit report at http://bugs.php.net/bug.php?id=50902&edit=1
ID: 50902
Comment by: indey...@php.net
Reported by:william at therileys dot freetcp dot com
Summary:Segfault if date.timezone is not set and error_log
is defined
Status: Assigned
Type: Bug
Package:SOAP related
Operating System: *
PHP Version:5.*, 6
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
(copypaste from #54087, which is marked as duplicate of this bug)
Description:
In case there is some problem with extension loaded from php.ini (shared
dependency not available), php segfaults while trying to show error.
it happens in debug+zts mode at least.
Debugger output:
(lldb) run
Process 23067 launched: '/opt/php53/bin/php' (x86_64)
(lldb) Process 23067 stopped
* thread #1: tid = 0x2d03, 0x000197f0 php`guess_timezone + 48 at
php_date.c:843, stop reason = EXC_BAD_ACCESS (code=13, address=0x0)
840char *env;
841
842/* Checking configure timezone */
843 -> if (DATEG(timezone) && (strlen(DATEG(timezone)) > 0)) {
844return DATEG(timezone);
845}
846/* Check environment variable */
(lldb) frame s 3
frame #3: 0x00010053edb1 php`php_log_err + 369 at main.c:585
582char *error_time_str;
583
584time(&error_time);
585 -> error_time_str = php_format_date("d-M-Y H:i:s",
11, error_time, 1 TSRMLS_CC);
586len = spprintf(&tmp, 0, "[%s] %s%s",
error_time_str, log_message, PHP_EOL);
587#ifdef PHP_WIN32
588php_flock(fd, 2);
(lldb) print log_message
(char *) log_message = 0x000101807a50 "PHP Warning: PHP Startup:
Unable to
load dynamic library '/opt/php53/lib/php/extensions/debug-zts-
20090626/gobject.so' - dlopen(/opt/php53/lib/php/extensions/debug-zts-
20090626/gobject.so, 9): Library not loaded:
/opt/homebrew/Cellar/gobject-
introspection/0.10.2/lib/libgirepository-1.0.1.dylib\n Referenced from:
/opt/php53/lib/php/extensions/debug-zts-20090626/gobject.so\n Reason:
image not
found in Unknown on line 0"
(lldb) bt
thread #1: tid = 0x2d03, stop reason = EXC_BAD_ACCESS (code=13,
address=0x0)
frame #0: 0x000197f0 php`guess_timezone + 48 at
php_date.c:843
frame #1: 0x00019c69 php`get_timezone_info + 89 at
php_date.c:940
frame #2: 0x0001a05b php`php_format_date + 59 at
php_date.c:1190
frame #3: 0x00010053edb1 php`php_log_err + 369 at main.c:585
frame #4: 0x000100543b76 php`php_error_cb + 2342 at main.c:1003
frame #5: 0x0001005f6da3 php`zend_error + 1139 at zend.c:1020
frame #6: 0x00010053fdb5 php`php_verror + 3301 at main.c:807
frame #7: 0x00010053ff9c php`php_error_docref0 + 364 at
main.c:819
frame #8: 0x00010040d031 php`php_load_extension + 561 at dl.c:158
frame #9: 0x000100554d32 php`php_load_php_extension_cb + 50 at
php_ini.c:351
frame #10: 0x0001005e8661 php`zend_llist_apply + 65 at
zend_llist.c:193
frame #11: 0x000100554cb7 php`php_ini_register_extensions + 87 at
php_ini.c:751
frame #12: 0x000100542f89 php`php_module_startup + 3529 at
main.c:2029
frame #13: 0x00010071b944 php`php_cli_startup + 36 at
php_cli.c:402
frame #14: 0x00010071895f php`main + 2575 at php_cli.c:776
frame #15: 0x00010c64 php`start + 52
(lldb)
Expected result:
Error is displayed
Actual result:
--
Segfaul
Previous Comments:
[2010-02-03 23:19:29] j...@php.net
This is bug in SOAP extension which has a funky error handler defined.
[2010-02-03 22:33:07] j...@php.net
The shortest way to reproduce:
# php -n -dlog_errors=on -derror_log=./foo \
-r 'new SoapClient("http://localhost/wsdl";);
[2010-02-03 22:23:22] william at therileys dot freetcp dot com
I did another back trace just to verify the correct php version was
being used and with the source code in place on the system on which I
ran gdb.
Please note that the back trace will say 5.2.12 (even though this is the
snapshot) because I used that directory name so I did not have to
rewrite the spec file to build an RPM.
http://pastebin.com/f19f1446a
$ /usr/local/bin/php --version
PHP 5.2.13RC1-dev (cli) (built: Feb 2 2010 10:17:42)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
[2010-02-03 22:00:57] j...@php.net
That was not the back
Bug #54083 [Ver]: Lazy match doesn't match more than 99997 characters
Edit report at http://bugs.php.net/bug.php?id=54083&edit=1
ID: 54083
Updated by: ahar...@php.net
Reported by:zequez at gmail dot com
Summary:Lazy match doesn't match more than 7 characters
Status: Verified
Type: Bug
-Package:Regexps related
+Package:PCRE related
Operating System: Windows 7
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Verified on Linux.
Previous Comments:
[2011-02-24 13:24:06] ahar...@php.net
Verified on Linux.
[2011-02-24 04:38:33] zequez at gmail dot com
Sorry the misspell, it's lazy, not greedy.
[2011-02-24 01:26:45] zequez at gmail dot com
Didn't tested in other operative systems...
[2011-02-24 01:24:01] zequez at gmail dot com
Description:
Greedy match doesn't match more than 7 characters. If you try to
greedy match
more than 7 characters it matches nothing.
Test script:
---
// 7 string length
$contents = '';
for ($i = 0; $i < 7; ++$i) {
$contents .= "a";
}
preg_match('/^a*?$/', $contents, $match);
var_dump($match);
// 8 string length
$contents = '';
for ($i = 0; $i < 8; ++$i) {
$contents .= "a";
}
preg_match('/^a*?$/', $contents, $match);
var_dump($match);
Expected result:
To match the whole $contents content in both cases.
Actual result:
--
The first case match the whole $contents content, but in the second one
it match
nothing.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54083&edit=1
Bug #54083 [Opn->Ver]: Lazy match doesn't match more than 99997 characters
Edit report at http://bugs.php.net/bug.php?id=54083&edit=1
ID: 54083
Updated by: ahar...@php.net
Reported by:zequez at gmail dot com
Summary:Lazy match doesn't match more than 7 characters
-Status: Open
+Status: Verified
Type: Bug
Package:Regexps related
Operating System: Windows 7
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Verified on Linux.
Previous Comments:
[2011-02-24 04:38:33] zequez at gmail dot com
Sorry the misspell, it's lazy, not greedy.
[2011-02-24 01:26:45] zequez at gmail dot com
Didn't tested in other operative systems...
[2011-02-24 01:24:01] zequez at gmail dot com
Description:
Greedy match doesn't match more than 7 characters. If you try to
greedy match
more than 7 characters it matches nothing.
Test script:
---
// 7 string length
$contents = '';
for ($i = 0; $i < 7; ++$i) {
$contents .= "a";
}
preg_match('/^a*?$/', $contents, $match);
var_dump($match);
// 8 string length
$contents = '';
for ($i = 0; $i < 8; ++$i) {
$contents .= "a";
}
preg_match('/^a*?$/', $contents, $match);
var_dump($match);
Expected result:
To match the whole $contents content in both cases.
Actual result:
--
The first case match the whole $contents content, but in the second one
it match
nothing.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54083&edit=1
Bug #54085 [Bgs]: problem when encode
Edit report at http://bugs.php.net/bug.php?id=54085&edit=1
ID: 54085
Updated by: ahar...@php.net
Reported by:nong_asc at hotmail dot com
Summary:problem when encode
Status: Bogus
Type: Bug
Package:MySQL related
Operating System: window xp
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
Please report this to Zend, not to us. We can't support third-party
extensions like Zend Guard.
Previous Comments:
[2011-02-24 13:22:01] johan...@php.net
Do not file bugs when you have Zend extensions (zend_extension=)
loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache,
APC, Xdebug and ionCube loader. These extensions often modify engine
behavior which is not related to PHP itself.
Please report issues with commercial software to the vendor.
[2011-02-24 04:20:51] nong_asc at hotmail dot com
Description:
When I encode by zend guard(v5.0.0) and after I run this code I have a
message
Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to
allocate
54263789 bytes) in
C:\h\ghx\apache\htdocs\alpha\include\connection.inc.php on
line 1072
but if I run and not encode it's work well.
PHP Version 5.2.16
This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with Zend Extension Manager v1.2.0, Copyright (c) 2003-2007, by Zend
Technologies
with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend
Technologies
Test script:
---
100";
$openselect = 0;
$parole = explode(" ",$string);
$i = 0;
$trovata = 0;
foreach ($parole as $elabora){
if((strpos($elabora,"SELECT")!==false && $trovata==0)){
$openselect++;
}
if((strpos($elabora,"FROM")!==false && $trovata==0)){
$openselect--;
}
if($openselect==0){
$trovata = 1;
$condizione .= " ".$elabora;
echo "linke 1074 ".$condizione."";
array_splice($parole,$i);
}
$i++;
}
?>
--
Edit this bug report at http://bugs.php.net/bug.php?id=54085&edit=1
Bug #54085 [Opn->Bgs]: problem when encode
Edit report at http://bugs.php.net/bug.php?id=54085&edit=1
ID: 54085
Updated by: johan...@php.net
Reported by:nong_asc at hotmail dot com
Summary:problem when encode
-Status: Open
+Status: Bogus
Type: Bug
Package:MySQL related
Operating System: window xp
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
Do not file bugs when you have Zend extensions (zend_extension=)
loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache,
APC, Xdebug and ionCube loader. These extensions often modify engine
behavior which is not related to PHP itself.
Please report issues with commercial software to the vendor.
Previous Comments:
[2011-02-24 04:20:51] nong_asc at hotmail dot com
Description:
When I encode by zend guard(v5.0.0) and after I run this code I have a
message
Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to
allocate
54263789 bytes) in
C:\h\ghx\apache\htdocs\alpha\include\connection.inc.php on
line 1072
but if I run and not encode it's work well.
PHP Version 5.2.16
This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with Zend Extension Manager v1.2.0, Copyright (c) 2003-2007, by Zend
Technologies
with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend
Technologies
Test script:
---
100";
$openselect = 0;
$parole = explode(" ",$string);
$i = 0;
$trovata = 0;
foreach ($parole as $elabora){
if((strpos($elabora,"SELECT")!==false && $trovata==0)){
$openselect++;
}
if((strpos($elabora,"FROM")!==false && $trovata==0)){
$openselect--;
}
if($openselect==0){
$trovata = 1;
$condizione .= " ".$elabora;
echo "linke 1074 ".$condizione."";
array_splice($parole,$i);
}
$i++;
}
?>
--
Edit this bug report at http://bugs.php.net/bug.php?id=54085&edit=1
Req #54086 [Opn->Dup]: Add "default character set" option for mysql connection
Edit report at http://bugs.php.net/bug.php?id=54086&edit=1 ID: 54086 Updated by: ahar...@php.net Reported by:cavo at ynet dot sk Summary:Add "default character set" option for mysql connection -Status: Open +Status: Duplicate Type: Feature/Change Request Package:MySQLi related Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Johannes's reasoning in request #44118 seems sound to me. Closing. Previous Comments: [2011-02-24 11:37:40] cavo at ynet dot sk Description: I'm voting for http://bugs.php.net/bug.php?id=44118 Here is my explanation: This is actually not implemented feature of mysql protocol (character set handshake), related to both mysql and mysqli PHP extensions causing buggy behavior. While connecting, several packets exchanges between server and client. After succesful TCP handshake, server sent "Server Greeting" message (packet) where server's default character set is specified (for example "Charset: utf8 COLLATE utf8_general_ci" - 0x21). Then "Login Request" message follows from client's side specifying character set which will be used for connection. Here is problem - PHP's both mysql and mysqli extension send always "Charset: latin1 COLLATE latin1_swedish_ci" - 0x08. But PHP don't look at query responses in way they are encoded in latin1. But mysql database must re-encode data from charset used for table field to latin1. There is actually 2 different solutions for this problem (mysqli [mysql]): 1. solution: executing mysqli::set_charset [mysql_set_charset] right after mysqli::__construct [mysql_ connect]. But this causes redundant query sent to server (for example: SET NAMES "utf8"); 2. solution: configure mysql server with option "character-set-client-handshake = false" which makes MySQL behave like MySQL 4.0 and ignore character set sent by client. I think there should be MySQL/MySQLi Configuration Option like: mysqli.default_character_set = utf8 mysql.default_character_set = utf8 This will support mysql's character set handshake without executing redundant queries. This option is also possible in mysql cli interface as "--default-character-set=utf8" Here is Login Request message caught by wireshark for code: (character set in "[]" brackets) 3a 00 00 01 85 a2 02 00 00 00 00 40[08]00 00 00 :..@ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020 00 00 00 00 72 6f 6f 74 00 14 0c 79 bf 1a bd d0 root...y 0030 36 0a 21 fc 6d e5 f0 42 27 89 9f 32 e5 956.!.m..B'..2.. Here is Login Request message caught by wireshark for code (cli): $ mysql -u root -p -h 127.0.0.1 --default-character-set=utf8 (character set in "[]" brackets) 3a 00 00 01 85 a6 03 00 00 00 00 01[21]00 00 00 :...!... 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020 00 00 00 00 72 6f 6f 74 00 14 97 58 9b 0a 65 b8 root...X..e. 0030 0c 67 dc 8a 82 28 51 a5 1f 1b 08 28 c5 c2.g...(Q(.. Test script: --- cli: mysql -u root -p -h 127.0.0.1 --default-character-set=utf8 -- Edit this bug report at http://bugs.php.net/bug.php?id=54086&edit=1
Bug #54087 [Opn->Dup]: Segfault on startup, DATEG(timezone) not initialized
Edit report at http://bugs.php.net/bug.php?id=54087&edit=1
ID: 54087
Updated by: ahar...@php.net
Reported by:indey...@php.net
Summary:Segfault on startup, DATEG(timezone) not initialized
-Status: Open
+Status: Duplicate
Type: Bug
Package:Date/time related
Operating System: Mac OS X
PHP Version:5.3SVN-2011-02-24 (SVN)
Block user comment: N
Private report: N
New Comment:
Duplicate of bug #50902.
Previous Comments:
[2011-02-24 12:21:15] indey...@php.net
Description:
In case there is some problem with extension loaded from php.ini (shared
dependency not available), php segfaults while trying to show error.
it happens in debug+zts mode at least.
Debugger output:
(lldb) run
Process 23067 launched: '/opt/php53/bin/php' (x86_64)
(lldb) Process 23067 stopped
* thread #1: tid = 0x2d03, 0x000197f0 php`guess_timezone + 48 at
php_date.c:843, stop reason = EXC_BAD_ACCESS (code=13, address=0x0)
840char *env;
841
842/* Checking configure timezone */
843 -> if (DATEG(timezone) && (strlen(DATEG(timezone)) > 0)) {
844return DATEG(timezone);
845}
846/* Check environment variable */
(lldb) frame s 3
frame #3: 0x00010053edb1 php`php_log_err + 369 at main.c:585
582char *error_time_str;
583
584time(&error_time);
585 -> error_time_str = php_format_date("d-M-Y H:i:s",
11, error_time, 1 TSRMLS_CC);
586len = spprintf(&tmp, 0, "[%s] %s%s",
error_time_str, log_message, PHP_EOL);
587#ifdef PHP_WIN32
588php_flock(fd, 2);
(lldb) print log_message
(char *) log_message = 0x000101807a50 "PHP Warning: PHP Startup:
Unable to
load dynamic library '/opt/php53/lib/php/extensions/debug-zts-
20090626/gobject.so' - dlopen(/opt/php53/lib/php/extensions/debug-zts-
20090626/gobject.so, 9): Library not loaded:
/opt/homebrew/Cellar/gobject-
introspection/0.10.2/lib/libgirepository-1.0.1.dylib\n Referenced from:
/opt/php53/lib/php/extensions/debug-zts-20090626/gobject.so\n Reason:
image not
found in Unknown on line 0"
(lldb) bt
thread #1: tid = 0x2d03, stop reason = EXC_BAD_ACCESS (code=13,
address=0x0)
frame #0: 0x000197f0 php`guess_timezone + 48 at
php_date.c:843
frame #1: 0x00019c69 php`get_timezone_info + 89 at
php_date.c:940
frame #2: 0x0001a05b php`php_format_date + 59 at
php_date.c:1190
frame #3: 0x00010053edb1 php`php_log_err + 369 at main.c:585
frame #4: 0x000100543b76 php`php_error_cb + 2342 at main.c:1003
frame #5: 0x0001005f6da3 php`zend_error + 1139 at zend.c:1020
frame #6: 0x00010053fdb5 php`php_verror + 3301 at main.c:807
frame #7: 0x00010053ff9c php`php_error_docref0 + 364 at
main.c:819
frame #8: 0x00010040d031 php`php_load_extension + 561 at dl.c:158
frame #9: 0x000100554d32 php`php_load_php_extension_cb + 50 at
php_ini.c:351
frame #10: 0x0001005e8661 php`zend_llist_apply + 65 at
zend_llist.c:193
frame #11: 0x000100554cb7 php`php_ini_register_extensions + 87 at
php_ini.c:751
frame #12: 0x000100542f89 php`php_module_startup + 3529 at
main.c:2029
frame #13: 0x00010071b944 php`php_cli_startup + 36 at
php_cli.c:402
frame #14: 0x00010071895f php`main + 2575 at php_cli.c:776
frame #15: 0x00010c64 php`start + 52
(lldb)
Expected result:
Error is displayed
Actual result:
--
Segfault
--
Edit this bug report at http://bugs.php.net/bug.php?id=54087&edit=1
[PHP-BUG] Bug #54089 [NEW]: token_get_all with regards to __halt_compiler is not binary safe
From:
Operating system: Any
PHP version: 5.3.5
Package: Unknown/Other Function
Bug Type: Bug
Bug description:token_get_all with regards to __halt_compiler is not binary safe
Description:
A. token_get_all() eats some characters which are not allowed in plain PHP
code and trigger a "Unexpected character in input" warning.
B. after a T_HALT_COMPILER, the tokens are still identified as if they were
not after this T_HALT_COMPILER, when in reality they are just random data.
So, when using token_get_all on code which contains a T_HALT_COMPILER, the
data after that is corrupted because of A.
Test script:
---
\x02";
$tokens = token_get_all($code);
$reconstructed_code = '';
foreach ($tokens as $t)
{
$reconstructed_code .= isset($t[1]) ? $t[1] : $t;
}
var_dump($code);
var_dump($reconstructed_code);
Expected result:
string(28) ""
string(28) ""
Actual result:
--
PHP Warning: Unexpected character in input: '' (ASCII=1) state=0 on line
5
string(28) ""
string(27) ""
--
Edit bug report at http://bugs.php.net/bug.php?id=54089&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54089&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54089&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54089&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54089&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54089&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54089&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54089&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54089&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54089&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54089&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54089&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54089&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54089&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54089&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54089&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54089&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54089&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54089&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54089&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54089&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54089&r=mysqlcfg
[PHP-BUG] Bug #54087 [NEW]: Segfault on startup, DATEG(timezone) not initialized
From: indeyets
Operating system: Mac OS X
PHP version: 5.3SVN-2011-02-24 (SVN)
Package: Date/time related
Bug Type: Bug
Bug description:Segfault on startup, DATEG(timezone) not initialized
Description:
In case there is some problem with extension loaded from php.ini (shared
dependency not available), php segfaults while trying to show error.
it happens in debug+zts mode at least.
Debugger output:
(lldb) run
Process 23067 launched: '/opt/php53/bin/php' (x86_64)
(lldb) Process 23067 stopped
* thread #1: tid = 0x2d03, 0x000197f0 php`guess_timezone + 48 at
php_date.c:843, stop reason = EXC_BAD_ACCESS (code=13, address=0x0)
840char *env;
841
842/* Checking configure timezone */
843 -> if (DATEG(timezone) && (strlen(DATEG(timezone)) > 0)) {
844return DATEG(timezone);
845}
846/* Check environment variable */
(lldb) frame s 3
frame #3: 0x00010053edb1 php`php_log_err + 369 at main.c:585
582char *error_time_str;
583
584time(&error_time);
585 -> error_time_str = php_format_date("d-M-Y H:i:s",
11, error_time, 1 TSRMLS_CC);
586len = spprintf(&tmp, 0, "[%s] %s%s",
error_time_str, log_message, PHP_EOL);
587#ifdef PHP_WIN32
588php_flock(fd, 2);
(lldb) print log_message
(char *) log_message = 0x000101807a50 "PHP Warning: PHP Startup:
Unable to
load dynamic library '/opt/php53/lib/php/extensions/debug-zts-
20090626/gobject.so' - dlopen(/opt/php53/lib/php/extensions/debug-zts-
20090626/gobject.so, 9): Library not loaded: /opt/homebrew/Cellar/gobject-
introspection/0.10.2/lib/libgirepository-1.0.1.dylib\n Referenced from:
/opt/php53/lib/php/extensions/debug-zts-20090626/gobject.so\n Reason:
image not
found in Unknown on line 0"
(lldb) bt
thread #1: tid = 0x2d03, stop reason = EXC_BAD_ACCESS (code=13,
address=0x0)
frame #0: 0x000197f0 php`guess_timezone + 48 at php_date.c:843
frame #1: 0x00019c69 php`get_timezone_info + 89 at
php_date.c:940
frame #2: 0x0001a05b php`php_format_date + 59 at php_date.c:1190
frame #3: 0x00010053edb1 php`php_log_err + 369 at main.c:585
frame #4: 0x000100543b76 php`php_error_cb + 2342 at main.c:1003
frame #5: 0x0001005f6da3 php`zend_error + 1139 at zend.c:1020
frame #6: 0x00010053fdb5 php`php_verror + 3301 at main.c:807
frame #7: 0x00010053ff9c php`php_error_docref0 + 364 at main.c:819
frame #8: 0x00010040d031 php`php_load_extension + 561 at dl.c:158
frame #9: 0x000100554d32 php`php_load_php_extension_cb + 50 at
php_ini.c:351
frame #10: 0x0001005e8661 php`zend_llist_apply + 65 at
zend_llist.c:193
frame #11: 0x000100554cb7 php`php_ini_register_extensions + 87 at
php_ini.c:751
frame #12: 0x000100542f89 php`php_module_startup + 3529 at
main.c:2029
frame #13: 0x00010071b944 php`php_cli_startup + 36 at php_cli.c:402
frame #14: 0x00010071895f php`main + 2575 at php_cli.c:776
frame #15: 0x00010c64 php`start + 52
(lldb)
Expected result:
Error is displayed
Actual result:
--
Segfault
--
Edit bug report at http://bugs.php.net/bug.php?id=54087&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54087&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54087&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54087&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54087&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54087&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54087&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54087&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54087&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54087&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54087&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54087&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54087&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54087&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54087&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54087&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54087&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54087&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54087&r=gnused
Floatin
[PHP-BUG] Req #54086 [NEW]: Add "default character set" option for mysql connection
From: Operating system: Linux PHP version: Irrelevant Package: MySQLi related Bug Type: Feature/Change Request Bug description:Add "default character set" option for mysql connection Description: I'm voting for http://bugs.php.net/bug.php?id=44118 Here is my explanation: This is actually not implemented feature of mysql protocol (character set handshake), related to both mysql and mysqli PHP extensions causing buggy behavior. While connecting, several packets exchanges between server and client. After succesful TCP handshake, server sent "Server Greeting" message (packet) where server's default character set is specified (for example "Charset: utf8 COLLATE utf8_general_ci" - 0x21). Then "Login Request" message follows from client's side specifying character set which will be used for connection. Here is problem - PHP's both mysql and mysqli extension send always "Charset: latin1 COLLATE latin1_swedish_ci" - 0x08. But PHP don't look at query responses in way they are encoded in latin1. But mysql database must re-encode data from charset used for table field to latin1. There is actually 2 different solutions for this problem (mysqli [mysql]): 1. solution: executing mysqli::set_charset [mysql_set_charset] right after mysqli::__construct [mysql_ connect]. But this causes redundant query sent to server (for example: SET NAMES "utf8"); 2. solution: configure mysql server with option "character-set-client-handshake = false" which makes MySQL behave like MySQL 4.0 and ignore character set sent by client. I think there should be MySQL/MySQLi Configuration Option like: mysqli.default_character_set = utf8 mysql.default_character_set = utf8 This will support mysql's character set handshake without executing redundant queries. This option is also possible in mysql cli interface as "--default-character-set=utf8" Here is Login Request message caught by wireshark for code: (character set in "[]" brackets) 3a 00 00 01 85 a2 02 00 00 00 00 40[08]00 00 00 :..@ 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020 00 00 00 00 72 6f 6f 74 00 14 0c 79 bf 1a bd d0 root...y 0030 36 0a 21 fc 6d e5 f0 42 27 89 9f 32 e5 956.!.m..B'..2.. Here is Login Request message caught by wireshark for code (cli): $ mysql -u root -p -h 127.0.0.1 --default-character-set=utf8 (character set in "[]" brackets) 3a 00 00 01 85 a6 03 00 00 00 00 01[21]00 00 00 :...!... 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020 00 00 00 00 72 6f 6f 74 00 14 97 58 9b 0a 65 b8 root...X..e. 0030 0c 67 dc 8a 82 28 51 a5 1f 1b 08 28 c5 c2.g...(Q(.. Test script: --- cli: mysql -u root -p -h 127.0.0.1 --default-character-set=utf8 -- Edit bug report at http://bugs.php.net/bug.php?id=54086&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54086&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54086&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54086&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54086&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54086&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54086&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54086&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54086&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54086&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54086&r=support Expected behavior: http://bugs.php.net/fix.php?id=54086&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54086&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54086&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54086&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54086&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54086&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54086&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54086&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54086&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54086&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54086&r=mysqlcfg
Bug #50547 [Com]: SoapServer Fatal errror in WSDL mode
Edit report at http://bugs.php.net/bug.php?id=50547&edit=1 ID: 50547 Comment by: mdekrijger at e-sites dot nl Reported by:rsumibcay at reddoor dot biz Summary:SoapServer Fatal errror in WSDL mode Status: Open Type: Bug Package:SOAP related Operating System: Ubuntu Linux PHP Version:5.2.12 Block user comment: N Private report: N New Comment: Does anyone have an alternative solution for this problem? (while this bug remains open?) We really want to provide some information about the wrong type in the return soap response. So implementing our SOAP services would be a much easier job. Previous Comments: [2010-02-01 09:48:05] jitka at darbujanova dot cz I can confirm this. (http://bugs.php.net/bug.php?id=50895) [2009-12-21 20:18:01] rsumibcay at reddoor dot biz Description: SoapServer dies with fatal error in WSDL mode when a soap argument is a ComplexType with a member defined as int in the XSD, but the member value is passed as a non-numeric string. Reproduce code: --- 1. Define a ComplexType with an int data member: http://crkt190.reddoor.biz/fatalerror/complex_types.xsd 2. Define a WSDL that uses the ComplexType as an argument to the soap function: http://crkt190.reddoor.biz/fatalerror/fatalerror.wsdl 3. Create a soap envelope with a non-numeric string as the value for the int data member: http://crkt190.reddoor.biz/fatalerror/fatalerror-soap-envelope.xml 4. Make a soap request using the soap envelope in step 3. Expected result: The SoapServer should not die with a fatal error. The SoapServer should respond with a SoapFault, or let the call pass through so the business logic (mapped handler) can do validation and handle the error appropriately. Actual result: -- 500 HTTP response from server. The HTTP response body contains an error message and stack trace. Fatal error: SOAP-ERROR: Encoding Violation of encoding rules in ... -- Edit this bug report at http://bugs.php.net/bug.php?id=50547&edit=1
