Bug #65796 [Com]: mkdir creates folders with wrong permissions
Edit report at https://bugs.php.net/bug.php?id=65796edit=1
ID: 65796
Comment by: cmfcmf dot flach at gmail dot com
Reported by:cmfcmf dot flach at gmail dot com
Summary:mkdir creates folders with wrong permissions
Status: Not a bug
Type: Bug
Package:Directory function related
Operating System: Linux/Ubuntu 13.4
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I suspect your umask is 022. The manual states that the mode is modified by
your current umask. Try a umask(0) and see if it is still an issue.
It works. Thank you.
Previous Comments:
[2013-10-02 08:06:29] leight+bugs dot php at gmail dot com
I suspect your umask is 022. The manual states that the mode is modified by
your current umask. Try a umask(0) and see if it is still an issue.
[2013-10-01 09:53:40] m...@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
Check your umask.
[2013-10-01 09:48:19] d...@php.net
I get the same on PHP 5.5.3. chmod('test', 0777) then transforms the directory
to
the right chmod.
[2013-10-01 09:44:10] cmfcmf dot flach at gmail dot com
Description:
Creating a directory using mkdir() does not respect the permissions given.
Test script:
---
?php
// Create a folder with 0777 permissions.
mkdir('test', 0777);
// Should be 0777, but is 0755.
echo substr(sprintf('%o', fileperms('test')), -4);
Expected result:
I expect the folder to be created with 0777 permission.
Actual result:
--
The folder is created with 0755 permission.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65796edit=1
[PHP-BUG] Bug #65837 [NEW]: imageTTFText text shifted right
From: c dot madmax at gmail dot com
Operating system: Ubuntu 12.04
PHP version: Irrelevant
Package: GD related
Bug Type: Bug
Bug description:imageTTFText text shifted right
Description:
Hello PHP Developers,
I want to inform you about a imageTTFText() bug that exists since four
years. The problem is that imageTTFText text is shifted right. The bug
is only visible when using a large fontsize. The bigger the font the
larger the shift.
The bug was introduced with PHP 5.2.10 and reported here:
http://bugs.php.net/bug.php?id=49600 As you can see in the history of
bug 49600, a fix was made in revision 293268 and the bug was closed. But
then the fix was reverted in revision 296693 and obviously no one has
noticed that.
I strongly urge you to fix this problem. I am using PHP 5.4.0 on Ubuntu
12.04. I am sure the bug still exists in all php versions =5.2.10 until
this day (except revision 293268-296693).
I have made a test script and uploaded a sample image on two image
hosters to illustrate how massive the shift is:
http://img407.imageshack.us/img407/1888/mbxe.png (best quality)
http://img223.imagevenue.com/img.php?image=61219_imagettftext_shifted_122_1017lo.jpg
As you can see on the image, the character 'C' is NOT left aligned as it
should because the x position is zero. The character is shifted
approximately 20 pixels instead and overlap the polygon (which is
properly left-aligned). Some characters like 'A' or 'V' are only a
little bit shifted, but also overlap the polygon. It does not matter
what font you use, all are right shifted.
Note:
The array that is returned from imagettfbbox produces values that differ
1 pixel from the values returned from imageTTFText (when using x=0; y=0)
which is also a bug.
Please use my test script and verify the problem. If a php developper
whould use this test script each time he made a change in imageTTFText,
then such bugs would not occour. It seems the developer do not have
enough carefulness. That's a point you should think about.
Test script:
---
?php
$im = imagecreatetruecolor(500, 500);
$bgcolor = imagecolortransparent($im, imagecolorallocate($im, 255, 255,
255));
$fgcolor = imagecolorallocatealpha($im, 0, 0, 255, 64);
imagefill($im, 0, 0, $bgcolor);
$polygon = imagettftext(
$im,
480,// size
0, // angle
0, // x
480,// y
$fgcolor,
'/usr/share/fonts/truetype/msttcorefonts/verdana.ttf',
'C' // text
);
imagesetthickness($im, 2);
imagepolygon(
$im,
$polygon,
sizeof($polygon) / 2,
imagecolorallocatealpha($im, 255, 0, 0, 64)
);
header('Content-Type: image/png');
imagepng($im);
exit;
?
Expected result:
The polygon should enclose the character 'C' without overlapping the
character.
Actual result:
--
The polygon overlap the character 'C' because every character is shifted
right.
--
Edit bug report at https://bugs.php.net/bug.php?id=65837edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65837r=trysnapshot54
Try a snapshot (PHP 5.5):
https://bugs.php.net/fix.php?id=65837r=trysnapshot55
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65837r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65837r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65837r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65837r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65837r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65837r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65837r=support
Expected behavior: https://bugs.php.net/fix.php?id=65837r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65837r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65837r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65837r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65837r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65837r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65837r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65837r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65837r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65837r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65837r=mysqlcfg
Bug #65818 [Ver-Csd]: Segfault with built-in webserver and chunked transfer encoding
Edit report at https://bugs.php.net/bug.php?id=65818edit=1 ID: 65818 Updated by: fel...@php.net Reported by:ysangkok at gmail dot com Summary:Segfault with built-in webserver and chunked transfer encoding -Status: Verified +Status: Closed Type: Bug Package:Built-in web server Operating System: Linux PHP Version:5.5.4 Block user comment: N Private report: N New Comment: Automatic comment on behalf of felipe...@gmail.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=3aaee86ee33af276d2e879f5a645cc6dc850de22 Log: - Fixed bug #65818 (Segfault with built-in webserver and chunked transfer encoding) Previous Comments: [2013-10-02 19:16:12] ahar...@php.net Verified on current 5.4, 5.5 and master builds. [2013-10-02 18:56:47] ysangkok at gmail dot com The second line of the test script needs an ampersand at the end! [2013-10-02 18:54:49] ysangkok at gmail dot com Description: Chunked transfer encoding crashes the built-in webserver. Test script: --- #!/bin/bash php -S 127.0.0.1:8801 sleep 2 echo -ne POST /c.php HTTP/1.0\r Transfer-Encoding: chunked\r \r 3b\r aaa\r 49\r b\r 0 | nc 127.0.0.1 8801 Expected result: No segfault Actual result: -- (gdb) run -S 127.0.0.1:8801 Starting program: /usr/bin/php5 -S 127.0.0.1:8801 [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/i386-linux-gnu/libthread_db.so.1. PHP 5.5.4-1+debphp.org~raring+1 Development Server started at Wed Oct 2 20:52:35 2013 Listening on http://127.0.0.1:8801 Document root is /var/www Press Ctrl-C to quit. [Wed Oct 2 20:52:37 2013] 127.0.0.1:42191 Invalid request (Unexpected EOF) *** Error in `/usr/bin/php5': free(): invalid next size (fast): 0x089f8658 *** Program received signal SIGSEGV, Segmentation fault. 0xb783c8a0 in malloc_consolidate (av=av@entry=0xb7975440 main_arena) at malloc.c:4081 4081malloc.c: No such file or directory. (gdb) bt #0 0xb783c8a0 in malloc_consolidate (av=av@entry=0xb7975440 main_arena) at malloc.c:4081 #1 0xb783db73 in _int_malloc (av=av@entry=0xb7975440 main_arena, bytes=bytes@entry=630) at malloc.c:3358 #2 0xb7840682 in __libc_calloc (n=630, elem_size=1) at malloc.c:3169 #3 0xb7fe8931 in _dl_new_object (realname=realname@entry=0x89f85f0 /lib/i386-linux-gnu/libgcc_s.so.1, libname=libname@entry=0xb792e605 libgcc_s.so.1, type=type@entry=2, loader=loader@entry=0x0, mode=mode@entry=-1879048191, nsid=nsid@entry=0) at dl-object.c:76 #4 0xb7fe4520 in _dl_map_object_from_fd (name=name@entry=0xb792e605 libgcc_s.so.1, fd=10, fbp=fbp@entry=0xbfffd0ec, realname=0x89f85f0 /lib/i386-linux-gnu/libgcc_s.so.1, loader=loader@entry=0x0, l_type=l_type@entry=2, mode=mode@entry=-1879048191, stack_endp=stack_endp@entry=0xbfffd0e8, nsid=nsid@entry=0) at dl-load.c:1053 #5 0xb7fe6449 in _dl_map_object (loader=0x0, loader@entry=0xb7979000, name=name@entry=0xb792e605 libgcc_s.so.1, type=type@entry=2, trace_mode=trace_mode@entry=0, mode=mode@entry=-1879048191, nsid=0) at dl-load.c:2606 #6 0xb7ff1075 in dl_open_worker (a=a@entry=0xbfffd48c) at dl-open.c:228 #7 0xb7fed05e in _dl_catch_error (objname=objname@entry=0xbfffd484, errstring=errstring@entry=0xbfffd488, mallocedp=mallocedp@entry=0xbfffd483, operate=operate@entry=0xb7ff0f40 dl_open_worker, args=args@entry=0xbfffd48c) at dl-error.c:177 #8 0xb7ff0af4 in _dl_open (file=0xb792e605 libgcc_s.so.1, mode=-2147483647, caller_dlopen=0xb78ccc38 init+40, nsid=-2, argc=3, argv=0xb2e4, env=0x8897008) at dl-open.c:656 #9 0xb78f0711 in do_dlopen (ptr=ptr@entry=0xbfffd630) at dl-libc.c:87 #10 0xb7fed05e in _dl_catch_error (objname=0xbfffd608, errstring=0xbfffd60c, mallocedp=0xbfffd607, operate=0xb78f06b0 do_dlopen, args=0xbfffd630) at dl-error.c:177 #11 0xb78f0807 in dlerror_run (operate=operate@entry=0xb78f06b0 do_dlopen, args=args@entry=0xbfffd630) at dl-libc.c:46 #12 0xb78f0897 in __GI___libc_dlopen_mode (name=name@entry=0xb792e605 libgcc_s.so.1, mode=mode@entry=-2147483647) at dl-libc.c:163 #13 0xb78ccc38 in init () at ../sysdeps/i386/backtrace.c:43 #14 0xb77b6dae in pthread_once () at ../nptl/sysdeps/unix/sysv/linux/i386/pthread_once.S:120 #15 0xb78ccea5 in __GI___backtrace (array=array@entry=0xbfffd880, size=size@entry=64) at ../sysdeps/i386/backtrace.c:120 #16 0xb7831ad1 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0xb7934530 *** Error in `%s': %s: 0x%s ***\n) at ../sysdeps/unix/sysv/linux/libc_fatal.c:178 #17 0xb783c7e2 in
Bug #65724 [Nab]: unserialize doesn't always restore referenced objects
Edit report at https://bugs.php.net/bug.php?id=65724edit=1
ID: 65724
User updated by:niko dot sams at gmail dot com
Reported by:niko dot sams at gmail dot com
Summary:unserialize doesn't always restore referenced
objects
Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: Linux
PHP Version:5.5.4
Block user comment: N
Private report: N
New Comment:
Ok, if this is not a bug which workaround do you suggest?
In my use case the unserialize method tiggers access to a config object which
is cached and lazily loaded. So it can happen that loading the config is
triggered inside unserialize.
Previous Comments:
[2013-10-04 14:09:50] m...@php.net
We have a recursive context for Serializable, thus if you unserialize unrelated
strings in the unserialize callback, you literally throw bricks into the stream.
[2013-09-20 15:16:01] bixuehujin at gmail dot com
Had a test on commit
@8f146c2(https://github.com/php/php-src/commit/8f146c2bb0dcba3307f08a839554be056e660f34),
segfault occurred.
[2013-09-20 12:34:47] niko dot sams at gmail dot com
Description:
when doing another unserialize that creates objects in an
Serializable::unserialize implementation things break, the 'parent' isn't
unserialized correctly.
ok: PHP 5.3.3-7+squeeze14
ok: PHP 5.3.10-1ubuntu3.6
fail: PHP 5.4.4-14+deb7u2
fail: PHP 5.5.3
See phpt test script:
http://paste.kde.org/p83ce39d0/
Test script:
---
class Bar {}
class Foo implements Serializable {
public $test;
public function __construct($test) { $this-test = $test; }
public function serialize()
{
return $this-test;
}
public function unserialize($serialized)
{
//the following line causes problems
unserialize('O:3:Bar:1:{s:4:bar1;O:3:Bar:0:{}}');
$this-test = $serialized;
}
}
$foo1 = new Foo('foo1');
$foo2 = new Foo('foo2');
$foo3 = new Foo('foo3');
$ar = array(
array(
'instance' = $foo1,
),
array(
'instance' = $foo2,
),
array(
'instance' = $foo3,
'parent' = $foo2
)
);
$ar = serialize($ar);
$ar = unserialize($ar);
print_r($ar);
Expected result:
[parent] = Foo Object ( [test] = foo2 ) )
Actual result:
--
[parent] = foo2
--
Edit this bug report at https://bugs.php.net/bug.php?id=65724edit=1
[PHP-BUG] Bug #65839 [NEW]: $a = 10; $a = $a++; echo $a; //10 But other language like C, will be output: 11
From: mehedi6060 at gmail dot com Operating system: Windows 7 PHP version: 5.4.20 Package: *Compile Issues Bug Type: Bug Bug description:$a = 10; $a = $a++; echo $a; //10 But other language like C, will be output: 11 Description: $a = 10; $a = $a++; echo $a; what will be output you thinking? output : 11 ? Sorry, Output is : 10 Because this is a bug on PHP! But other language(c,c++) this will be : 11 Thanks. Mehedi Hasan mehedi6...@gmail.com Test script: --- $a = 10; $a = $a++; echo $a; //10 //But the correct output will be : 11 Expected result: $a = 10; $a = $a++; echo $a; //10 //But the correct output will be : 11 -- Edit bug report at https://bugs.php.net/bug.php?id=65839edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65839r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=65839r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65839r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65839r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65839r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65839r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65839r=needscript Try newer version: https://bugs.php.net/fix.php?id=65839r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65839r=support Expected behavior: https://bugs.php.net/fix.php?id=65839r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65839r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65839r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65839r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65839r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65839r=dst IIS Stability: https://bugs.php.net/fix.php?id=65839r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65839r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65839r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65839r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65839r=mysqlcfg
Bug #65837 [Opn-Asn]: imageTTFText text shifted right
Edit report at https://bugs.php.net/bug.php?id=65837edit=1
ID: 65837
Updated by: fel...@php.net
Reported by:c dot madmax at gmail dot com
Summary:imageTTFText text shifted right
-Status: Open
+Status: Assigned
Type: Bug
Package:GD related
Operating System: Ubuntu 12.04
PHP Version:Irrelevant
-Assigned To:
+Assigned To:tabe
Block user comment: N
Private report: N
Previous Comments:
[2013-10-05 10:39:42] c dot madmax at gmail dot com
Description:
Hello PHP Developers,
I want to inform you about a imageTTFText() bug that exists since four years.
The problem is that imageTTFText text is shifted right. The bug is only visible
when using a large fontsize. The bigger the font the larger the shift.
The bug was introduced with PHP 5.2.10 and reported here:
http://bugs.php.net/bug.php?id=49600 As you can see in the history of bug
49600, a fix was made in revision 293268 and the bug was closed. But then the
fix was reverted in revision 296693 and obviously no one has noticed that.
I strongly urge you to fix this problem. I am using PHP 5.4.0 on Ubuntu 12.04.
I am sure the bug still exists in all php versions =5.2.10 until this day
(except revision 293268-296693).
I have made a test script and uploaded a sample image on two image hosters to
illustrate how massive the shift is:
http://img407.imageshack.us/img407/1888/mbxe.png (best quality)
http://img223.imagevenue.com/img.php?image=61219_imagettftext_shifted_122_1017lo.jpg
As you can see on the image, the character 'C' is NOT left aligned as it should
because the x position is zero. The character is shifted approximately 20
pixels instead and overlap the polygon (which is properly left-aligned). Some
characters like 'A' or 'V' are only a little bit shifted, but also overlap the
polygon. It does not matter what font you use, all are right shifted.
Note:
The array that is returned from imagettfbbox produces values that differ 1
pixel from the values returned from imageTTFText (when using x=0; y=0) which is
also a bug.
Please use my test script and verify the problem. If a php developper whould
use this test script each time he made a change in imageTTFText, then such bugs
would not occour. It seems the developer do not have enough carefulness. That's
a point you should think about.
Test script:
---
?php
$im = imagecreatetruecolor(500, 500);
$bgcolor = imagecolortransparent($im, imagecolorallocate($im, 255, 255, 255));
$fgcolor = imagecolorallocatealpha($im, 0, 0, 255, 64);
imagefill($im, 0, 0, $bgcolor);
$polygon = imagettftext(
$im,
480,// size
0, // angle
0, // x
480,// y
$fgcolor,
'/usr/share/fonts/truetype/msttcorefonts/verdana.ttf',
'C' // text
);
imagesetthickness($im, 2);
imagepolygon(
$im,
$polygon,
sizeof($polygon) / 2,
imagecolorallocatealpha($im, 255, 0, 0, 64)
);
header('Content-Type: image/png');
imagepng($im);
exit;
?
Expected result:
The polygon should enclose the character 'C' without overlapping the character.
Actual result:
--
The polygon overlap the character 'C' because every character is shifted right.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65837edit=1
Bug #65839 [Opn-Nab]: $a = 10; $a = $a++; echo $a; //10 But other language like C, will be output: 11
Edit report at https://bugs.php.net/bug.php?id=65839edit=1 ID: 65839 Updated by: ni...@php.net Reported by:mehedi6060 at gmail dot com Summary:$a = 10; $a = $a++; echo $a; //10 But other language like C, will be output: 11 -Status: Open +Status: Not a bug Type: Bug Package:*Compile Issues Operating System: Windows 7 PHP Version:5.4.20 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Please see http://php.net/manual/en/language.operators.precedence.php, which explicitly states that evaluation order is unspecified. The behavior is also undefined in C++, please see §1.9/15 of the C++11 standard. Previous Comments: [2013-10-05 16:12:29] mehedi6060 at gmail dot com Description: $a = 10; $a = $a++; echo $a; what will be output you thinking? output : 11 ? Sorry, Output is : 10 Because this is a bug on PHP! But other language(c,c++) this will be : 11 Thanks. Mehedi Hasan mehedi6...@gmail.com Test script: --- $a = 10; $a = $a++; echo $a; //10 //But the correct output will be : 11 Expected result: $a = 10; $a = $a++; echo $a; //10 //But the correct output will be : 11 -- Edit this bug report at https://bugs.php.net/bug.php?id=65839edit=1
Bug #65774 [Opn-Asn]: no max file descriptor check for events.mechanism = /dev/poll
Edit report at https://bugs.php.net/bug.php?id=65774edit=1
ID: 65774
Updated by: fel...@php.net
Reported by:aglarond at gmail dot com
Summary:no max file descriptor check for events.mechanism =
/dev/poll
-Status: Open
+Status: Assigned
Type: Bug
Package:FPM related
Operating System: SmartOS, possibly others
PHP Version:Irrelevant
-Assigned To:
+Assigned To:fat
Block user comment: N
Private report: N
Previous Comments:
[2013-09-27 16:00:13] aglarond at gmail dot com
Description:
When using PHP-FPM with 'events.mechanism = /dev/poll' and 'pm = dynamic', we
noticed that the log would fill with lines like the following:
WARNING: pid 61603, fpm_event_devpoll_wait(), line 166: /dev/poll: ioctl()
returns 22
The line referenced refers to sapi/fpm/fpm/events/devpoll.c:
159 /* wait for inconming event or timeout */
160 ret = ioctl(dpfd, DP_POLL, dopoll);
161
162 if (ret 0) {
163
164 /* trigger error unless signal interrupt */
165 if (errno != EINTR) {
166 zlog(ZLOG_WARNING, /dev/poll: ioctl() returns
%d, errno);
167 return -1;
168 }
169 }
Unfortunately, these log entries didn't help us to solve the problem. They
only served to fill the disk, as they were written as quickly as the I/O
subsystem allowed.
What did help narrow down the problem was seeing the following entry:
DEBUG: pid 61603, fpm_event_init_main(), line 333: event module is /dev/poll
and 1061 fds have been reserved
It seemed we had reached a watermark, as the default maximum number of file
descriptors on this system is 1024:
NAMEPRIVILEGE VALUEFLAG ACTION RECIPIENT
process.max-file-descriptor
basic 1.02K - deny 57203
privileged 65.5K - deny -
system 2.15G max deny -
Increasing the number of file descriptors makes the log entries go away:
NAMEPRIVILEGE VALUEFLAG ACTION RECIPIENT
process.max-file-descriptor
basic 65.5K - deny 70867
privileged 65.5K - deny -
system 2.15G max deny -
I propose prefacing the errno check (line 165) with one for EBADF. I don't
have time to write and test a patch right now, to verify that errno is indeed
EBADF in this case (error number 22 is EINVAL, but I suspect this is getting
passed from the device driver). The patch should make this check and then
probably end the main process.
An alternative is to change fpm_event_init_main in sapi/fpm/fpm/fpm_events.c to
end the main process at file descriptor reservation time:
323 /* count the max number of necessary fds for polling */
324 max = 1; /* only one FD is necessary at startup for the master
process signal pipe */
325 for (wp = fpm_worker_all_pools; wp; wp = wp-next) {
326 if (!wp-config) continue;
327 if (wp-config-catch_workers_output
wp-config-pm_max_children 0) {
328 max += (wp-config-pm_max_children * 2);
329 }
330 }
331
332 if (module-init(max) 0) {
333 zlog(ZLOG_ERROR, Unable to initialize the event module
%s, module-name);
334 return -1;
335 }
336
337 zlog(ZLOG_DEBUG, event module is %s and %d fds have been
reserved, module-name, max);
338
Briefly looking at devpool's init function shows checks for allocating enough
memory, but doesn't seem to check if the max file descriptors can actually be
allocated. Ideally, a check should be made at this point to see if an OS limit
will be hit before even initializing the module. I don't know if there are any
module-specific semantics that would need to be taken into account and preclude
a general check in fpm_event_init_main.
The relevant code paths are unchanged for 5.3.27, 5.4.20, 5.5.4, so marking
this as version Irrelevant.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65774edit=1
Req #38508 [Com]: Addition of Magic __toArray() function
Edit report at https://bugs.php.net/bug.php?id=38508edit=1 ID: 38508 Comment by: lukas at lu-x dot me Reported by:doublecompile at gmail dot com Summary:Addition of Magic __toArray() function Status: Closed Type: Feature/Change Request Package:Feature/Change Request PHP Version:* Block user comment: N Private report: N New Comment: I can only +1 the opinion from the last comment. Magic methods make PHP so powerful. So why limit it to string casting? The creator of the class should decide what values to return in which case - the user could just use the object in different ways without thinking about what methods would return what. It would all work automatically - using an array function would ask the object to return an array, using a string function would ask to return a string etc. So please implement magic methods for all data types in PHP - or, if that adds more complexity, add interfaces for that - the possibility to define custom conversion rules just has to exist! Previous Comments: [2013-05-24 03:39:23] rich dot remer at gmail dot com I think the main benefit it offers is the ability to control what happens during a cast operation. Right now, casting simple scalar values or NULL to an array works as expected. While it's possible to cast an object to an array, the semantics of what should happen in this situation are not nearly as clear. This really should be controlled by the class. [2013-03-07 12:19:14] ante at caan dot si Hi guys. I'm dragging this out from the History. I think this is a great suggestion as I use a lot of object that implement ArrayAccess so doing this $someArray = (array) $obj; that calls $obj-__toArray() would be a GREAT addition to PHP logic. [2012-03-14 18:55:00] erck0006 at gmail dot com // MY APPLICATION'S INTERIM SOLUTION (**UPDATE**) $customers = new Customers(); $customers = $customers-__toArray(); // THIS LINE IS THE **UPDATED** LINE NEEDED IN ORDER TO AVOID TRIGGERING THE FOLLOWING ERROR ON THE FOLLOWING LINE: Only variables should be passed by reference $lastCustomer = array_pop($customers); // SUCCESS echo $lastCustomer-getName(); // prints the last customer's name since the previous line did not fail since I explicitly called a custom method named __toArray() first [2012-03-14 18:37:23] erck0006 at gmail dot com ?php // AS-IS $customers = new Customers(); $lastCustomer = array_pop($customers); // FAIL: array_pop() expects parameter 1 to be array, object given echo $lastCustomer-getName(); // execution never reaches this line // MY APPLICATION'S INTERIM SOLUTION $customers = new Customers(); $lastCustomer = array_pop($customers-__toArray()); // SUCCESS echo $lastCustomer-getName(); // prints the last customer's name since the previous line did not fail since I explicitly called a custom method named __toArray() first // TO-BE $customers = new Customers(); $lastCustomer = array_pop($customers); // SUCCESS echo $lastCustomer-getName(); // prints the last customer's name since array_pop() calls __toArray() internally before failing [2012-02-27 21:27:32] john at john dot com this magic function would be great to have The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=38508 -- Edit this bug report at https://bugs.php.net/bug.php?id=38508edit=1
Req #65829 [Com]: Update to ICU 52.1 / Lao Word Boundary Support
Edit report at https://bugs.php.net/bug.php?id=65829edit=1 ID: 65829 Comment by: robert dot rcampbell at gmail dot com Reported by:robert dot rcampbell at gmail dot com Summary:Update to ICU 52.1 / Lao Word Boundary Support Status: Assigned Type: Feature/Change Request Package:*Languages/Translation Operating System: All PHP Version:Irrelevant Assigned To:ab Block user comment: N Private report: N New Comment: Good to know on other OSes. Will test it and check that it vorks... Previous Comments: [2013-10-04 13:45:36] paj...@php.net I suppose you mean on windows right? As for any other OSes, you can install whatever the distribution provides, or manually compile the version you wish. @a can you look to update to 5.1 for 5.5+? For what I see we have 5.0. [2013-10-04 10:33:33] robert dot rcampbell at gmail dot com Description: Request update to ICU 52.1 after October 9th, 2013, so that the Lao language can use the boundary analysis available to PHP - need it for word-wrapping in Lao. Thanks! -- Edit this bug report at https://bugs.php.net/bug.php?id=65829edit=1
Bug #64870 [Com]: mysqlnd: can't connect to updated MySQL server with old_password Off
Edit report at https://bugs.php.net/bug.php?id=64870edit=1
ID: 64870
Comment by: marceloinxs at gmail dot com
Reported by:marceloinxs at gmail dot com
Summary:mysqlnd: can't connect to updated MySQL server with
old_password Off
Status: Feedback
Type: Bug
Package:MySQLi related
Operating System: Windows 7 64bit
PHP Version:5.4.15
Block user comment: N
Private report: N
New Comment:
Hi, here it is the Wireshark report. Sorry for the (really extended) delay. I
now tested with 5.4.20 with same result.
(Host, User and Passwords are dummy text)
No. Time SourceDestination Protocol
Length Info
4 0.022147000xxx.xxx.xxx.xx192.168.0.10 MySQL110
Server Greeting proto=10 version=5.0.95
Frame 4: 110 bytes on wire (880 bits), 110 bytes captured (880 bits) on
interface 0
Ethernet II, Src: CiscoSpv_1a:5d:2d (00:25:2e:1a:5d:2d), Dst: HonHaiPr_25:9f:db
(c0:cb:38:25:9f:db)
Internet Protocol Version 4, Src: xxx.xxx.xxx.xx (xxx.xxx.xxx.xx), Dst:
192.168.0.10 (192.168.0.10)
Transmission Control Protocol, Src Port: mysql (3306), Dst Port: 54901 (54901),
Seq: 1, Ack: 1, Len: 56
MySQL Protocol
Packet Length: 52
Packet Number: 0
Server Greeting
Protocol: 10
Version: 5.0.95
Thread ID: 15618491
Salt: Jq}?aL7k
Server Capabilities: 0xa22c
...0 = Long Password: Not set
..0. = Found Rows: Not set
.1.. = Long Column Flags: Set
1... = Connect With Database: Set
...0 = Don't Allow database.table.column: Not set
..1. = Can use compression protocol: Set
.0.. = ODBC Client: Not set
0... = Can Use LOAD DATA LOCAL: Not set
...0 = Ignore Spaces before '(': Not set
..1. = Speaks 4.1 protocol (new flag): Set
.0.. = Interactive Client: Not set
0... = Switch to SSL after handshake: Not set
...0 = Ignore sigpipes: Not set
..1. = Knows about transactions: Set
.0.. = Speaks 4.1 protocol (old flag): Not set
1... = Can do 4.1 authentication: Set
Server Language: latin1 COLLATE latin1_swedish_ci (8)
Server Status: 0x0002
...0 = In transaction: Not set
..1. = AUTO_COMMIT: Set
.0.. = More results: Not set
0... = Multi query - more resultsets: Not set
...0 = Bad index used: Not set
..0. = No index used: Not set
.0.. = Cursor exists: Not set
0... = Last row sebd: Not set
...0 = database dropped: Not set
..0. = No backslash escapes: Not set
Unused:
Salt: :|'FlkXSz,fC
No. Time SourceDestination Protocol
Length Info
5 0.023225000192.168.0.10 xxx.xxx.xxx.xxMySQL166
Login Request user=abcd db=abcd_ef
Frame 5: 166 bytes on wire (1328 bits), 166 bytes captured (1328 bits) on
interface 0
Ethernet II, Src: HonHaiPr_25:9f:db (c0:cb:38:25:9f:db), Dst: CiscoSpv_1a:5d:2d
(00:25:2e:1a:5d:2d)
Internet Protocol Version 4, Src: 192.168.0.10 (192.168.0.10), Dst:
xxx.xxx.xxx.xx (xxx.xxx.xxx.xx)
Transmission Control Protocol, Src Port: 54901 (54901), Dst Port: mysql (3306),
Seq: 1, Ack: 57, Len: 112
MySQL Protocol
Packet Length: 108
Packet Number: 1
Login Request
Client Capabilities: 0xa28d
...1 = Long Password: Set
..0. = Found Rows: Not set
.1.. = Long Column Flags: Set
1... = Connect With Database: Set
...0 = Don't Allow database.table.column: Not set
..0. = Can use compression protocol: Not set
.0.. = ODBC Client: Not set
1... = Can Use LOAD DATA LOCAL: Set
...0 = Ignore Spaces before '(': Not set
..1. = Speaks 4.1 protocol (new flag): Set
.0.. = Interactive Client: Not set
0... = Switch to SSL after handshake: Not set
...0 = Ignore sigpipes: Not set
..1. = Knows about transactions: Set
.0.. = Speaks 4.1 protocol (old flag): Not set
1... = Can do 4.1 authentication:
Bug #65340 [Com]: Memory leak when using magic __set ?
Edit report at https://bugs.php.net/bug.php?id=65340edit=1
ID: 65340
Comment by: vitalif at mail dot ru
Reported by:vitalif at mail dot ru
Summary:Memory leak when using magic __set ?
Status: Open
Type: Bug
Package:Class/Object related
Operating System: Linux
PHP Version:5.5.1
Block user comment: N
Private report: N
New Comment:
Anyone? I've rechecked it on 5.5.4 - the bug is still there.
Previous Comments:
[2013-07-27 21:32:43] vitalif at mail dot ru
I don't think bug #48197 is related to this issue... There are no memory leaks.
I.e. extra alloc done by __call in that bug is freed without problem (if you
remove $b[$i] = and just throw away the value after each call).
And here I describe that an identical object takes twice more memory if you
write in its array property using __set.
[2013-07-26 01:51:01] fel...@php.net
See bug #48197
[2013-07-25 21:38:37] vitalif at mail dot ru
Description:
Hello!
I've discovered that when setting properties via __set() the object takes much
more memory than it should. It's reproducible at least on PHP 5.5 and 5.4. Is
it a memory leak?
Test script:
---
?php
// Memory leak somewhere around __set?
class A
{
var $data = array();
function __get($k)
{
return $this-data[$k];
}
function __set($k, $v)
{
return $this-data[$k] = $v;
}
}
$b = new A();
for ($i = 0; $i 50; $i++)
$b-{a$i} = 'abc';
var_dump(memory_get_usage()); // int(78318488) - why so big?
$c = clone $b;
unset($b);
var_dump(memory_get_usage()); // int(42220972) - OK
unset($c);
$b = new A();
for ($i = 0; $i 50; $i++)
$b-__set(a$i, 'abc');
var_dump(memory_get_usage()); // int(42221492) - OK
Expected result:
I expect roughly the same memory usage at all three points. Like:
int(42220972)
int(42220972)
int(42221492)
Actual result:
--
The first value is much bigger:
int(78318488)
int(42220972)
int(42221492)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65340edit=1
