Bug #65774 [Opn->Asn]: no max file descriptor check for events.mechanism = /dev/poll

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65774&edit=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=65774&edit=1

Bug #65837 [Opn->Asn]: imageTTFText text shifted right

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65837&edit=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:
---


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=65837&edit=1

Bug #65818 [Ver->Csd]: Segfault with built-in webserver and chunked transfer encoding

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65818&edit=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 ) at 
malloc.c:4081
4081malloc.c: No such file or directory.
(gdb) bt
#0  0xb783c8a0 in malloc_consolidate (av=av@entry=0xb7975440 ) at 
malloc.c:4081
#1  0xb783db73 in _int_malloc (av=av@entry=0xb7975440 , 
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 , 
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 , 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 , args=0xbfffd630)
at dl-error.c:177
#11 0xb78f0807 in dlerror_run (operate=operate@entry=0xb78f06b0 , 
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")
a

Bug #65805 [Opn->Fbk]: PDO/dblib not working anymore ("use dbName" not sent)

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65805&edit=1

 ID: 65805
 Updated by: fel...@php.net
 Reported by:ltakjhfnjh at hotmail dot com
 Summary:PDO/dblib not working anymore ("use dbName" not
 sent)
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:PDO related
 Operating System:   FreeBSD
 PHP Version:5.4.20
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

  http://snaps.php.net/php5.4-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




Previous Comments:

[2013-10-02 01:06:37] ltakjhfnjh at hotmail dot com

Description:

fully repeated Bug #65219

PDO/dblib not working anymore ("use dbName" not sent)







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65805&edit=1

Bug #65784 [Opn->Fbk]: Segfault with finally

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65784&edit=1

 ID: 65784
 Updated by: fel...@php.net
 Reported by:r dot wilczek at web-appz dot de
 Summary:Segfault with finally
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:*General Issues
 Operating System:   Linux
 PHP Version:5.5.4
 Block user comment: N
 Private report: N



Previous Comments:

[2013-10-01 22:58:15] ni...@php.net

Could you please post the code as it is actually used (just the part containing 
the finally)? Your backtrace indicates that the segfault happens during an 
argument send, but your code samples do not include any function calls with 
arguments.


[2013-09-29 12:26:34] r dot wilczek at web-appz dot de

(The second core-dump is created without xdebug, to keep things simple)


[2013-09-29 12:25:34] r dot wilczek at web-appz dot de

#0  0x00a41895 in zval_delref_p (pz=0x0) at 
/root/php-5.5.4/php-5.5.4/Zend/zend.h:409
#1  0x00a4330c in zend_pzval_unlock_func (z=0x0, 
should_free=0x7fffa8aa9e90, unref=1) at 
/root/php-5.5.4/php-5.5.4/Zend/zend_execute.c:72
#2  0x00a4341b in _get_zval_ptr_var (var=4294967232, 
execute_data=0x7f1fceaa5098, should_free=0x7fffa8aa9e90) at 
/root/php-5.5.4/php-5.5.4/Zend/zend_execute.c:186
#3  0x00a63e15 in ZEND_SEND_VAR_NO_REF_SPEC_VAR_HANDLER 
(execute_data=0x7f1fceaa5098) at 
/root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:13081
#4  0x00a480cf in execute_ex (execute_data=0x7f1fceaa5098) at 
/root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:363
#5  0x00a48157 in zend_execute (op_array=0x2e129f0) at 
/root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:388
#6  0x009f6785 in zend_call_function (fci=0x7fffa8aaa100, 
fci_cache=0x7fffa8aaa0d0) at 
/root/php-5.5.4/php-5.5.4/Zend/zend_execute_API.c:939
#7  0x0076285c in zim_reflection_method_invokeArgs (ht=2, 
return_value=0x2e3b2d0, return_value_ptr=0x0, this_ptr=0x2e3b450, 
return_value_used=1)
at /root/php-5.5.4/php-5.5.4/ext/reflection/php_reflection.c:3018
#8  0x00a489de in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7f1fceaa49e8) at 
/root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:550
#9  0x00a491b0 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(execute_data=0x7f1fceaa49e8) at 
/root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:685
#10 0x00a480cf in execute_ex (execute_data=0x7f1fceaa49e8) at 
/root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:363
#11 0x00a48157 in zend_execute (op_array=0x7f1fcead9b60) at 
/root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:388
#12 0x00a0a27f in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /root/php-5.5.4/php-5.5.4/Zend/zend.c:1318
#13 0x00976e9e in php_execute_script (primary_file=0x7fffa8aad7a0) at 
/root/php-5.5.4/php-5.5.4/main/main.c:2489
#14 0x00ab7ac7 in do_cli (argc=5, argv=0x263beb0) at 
/root/php-5.5.4/php-5.5.4/sapi/cli/php_cli.c:994
#15 0x00ab8bff in main (argc=5, argv=0x263beb0) at 
/root/php-5.5.4/php-5.5.4/sapi/cli/php_cli.c:1378


[2013-09-29 12:18:45] r dot wilczek at web-appz dot de

Description:

The structures
try {
   return foo();
} finally {
   bar();
}

or 

try {
return foo();
} catch (Exception $e) {
throw $e;
} finally {
bar();
}

under some circumstances segfault, whereas the equivalent structure
try {
$result = foo();
bar();
return $result;
} catch (Exception $e) {
bar();
throw $e;
}
works as expected.

Test script:
---
It's hard to reproduce the failure, because it occured within a "PHPUnit Mock 
Monster", and I failed to reproduce it with a simple script.

All I can show is the core-dump below, which is produced by a 
try {
   return foo();
} finally {
   bar();
}


Expected result:

No Segmentation fault

Actual result:
--
Segmentation fault

#0  0x00a41895 in zval_delref_p (pz=0x0) at 
/root/php-5.5.4/php-5.5.4/Zend/zend.h:409
#1  0x00a4330c in zend_pzval_unlock_func (z=0x0, 
should_free=0x7fff17175fe0, unref=1)
at /root/php-5.5.4/php-5.5.4/Zend/zend_execute.c:72
#2  0x00a4341b in _get_zval_ptr_var (var=4294967232, 
execute_data=0x7fea01fe0098, should_free=0x7fff17175fe0)
at /root/php-5.5.4/php-5.5.4/Zend/zend_execute.c:186
#3  0x00a63e15 in ZEND_SEND_VAR_NO_REF_SPEC_VAR_HANDLER 
(execute_data=0x7fea01fe0098)
at /root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:13081
#4  0x00a4a772 in ZEND_USER_OPCODE_SPEC_HANDLER 
(execute_data=0x7fea01fe0098)
at /root/php-5.5.4/php-5.5.4/Zend/zend_vm_execute.h:1119
#5  0x00a480cf 

Bug #65802 [Opn->Fbk]: Segmentation fault on creating new SoapClient

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65802&edit=1

 ID: 65802
 Updated by: fel...@php.net
 Reported by:karen dot thompkins at americanlanternpress dot com
 Summary:Segmentation fault on creating new SoapClient
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:SOAP related
 Operating System:   Linux version 2.6.32-279.5.2.el6
 PHP Version:5.4.20
 Block user comment: N
 Private report: N



Previous Comments:

[2013-10-02 01:04:19] fel...@php.net

I can't reproduce it, are you able to reproduce it without local_cert' and 
'passphrase' data?


[2013-10-01 16:25:49] karen dot thompkins at americanlanternpress dot com

Description:

Script ran fine until early this morning when cPanel ran its nightly update. I 
am unable to track down what might be causing the issue.

Configure: Command  './configure' '--enable-bcmath' '--enable-calendar' 
'--enable-ftp' '--enable-libxml' '--enable-mbstring' '--enable-pdo=shared' 
'--enable-soap' '--enable-sockets' '--enable-zip' '--prefix=/usr/local' 
'--with-apxs2=/usr/local/apache/bin/apxs' '--with-curl=/opt/curlssl/' 
'--with-gd' '--with-imap=/opt/php_with_imap_client/' '--with-imap-ssl=/usr' 
'--with-jpeg-dir=/usr' '--with-kerberos' '--with-libdir=lib64' 
'--with-libxml-dir=/opt/xml2' '--with-libxml-dir=/opt/xml2/' 
'--with-mcrypt=/opt/libmcrypt/' '--with-mysql=/usr' 
'--with-mysql-sock=/var/lib/mysql/mysql.sock' '--with-openssl=/usr' 
'--with-openssl-dir=/usr' '--with-pcre-regex=/opt/pcre' 
'--with-pdo-mysql=shared' '--with-pdo-sqlite=shared' '--with-pic' 
'--with-png-dir=/usr' '--with-xpm-dir=/usr' '--with-zlib' 
'--with-zlib-dir=/usr' 

cURL supportenabled
cURL Information7.24.0
Age 3
Features
AsynchDNS   No
Debug   No
GSS-Negotiate   No
IDN Yes
IPv6Yes
Largefile   Yes
NTLMYes
SPNEGO  No
SSL Yes
SSPINo
krb4No
libzYes
CharConvNo
Protocols   dict, file, ftp, ftps, gopher, http, https, imap, imaps, pop3, 
pop3s, rtsp, smtp, smtps, telnet, tftp
Hostx86_64-unknown-linux-gnu
SSL Version OpenSSL/1.0.0
ZLib Version1.2.3 

libxml
libXML support  active
libXML Compiled Version 2.9.0
libXML Loaded Version   20900
libXML streams  enabled 

soap
Soap Client enabled
Soap Server enabled

Directive   Local Value Master Value
soap.wsdl_cache 1   1
soap.wsdl_cache_dir /tmp/tmp
soap.wsdl_cache_enabled 1   1
soap.wsdl_cache_limit   5   5
soap.wsdl_cache_ttl 86400   86400

Test script:
---
$wsdl = "https://api.verticalresponse.com/wsdl/1.0/VRAPI.wsdl";; //location of 
the wsdl
$vr = new SoapClient($wsdl,
 array (
// 'local_cert' => $cert,
// 'passphrase' => $cert_pass
)
);

Expected result:

Soap client assigned to variable

Actual result:
--
Segmentation fault

# gdb php
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-56.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/local/bin/php...done.
(gdb) run vr.php
Starting program: /usr/local/bin/php vr.php
warning: the debug information found in 
"/usr/lib/debug//usr/lib64/libfreebl3.so.debug" does not match 
"/usr/lib64/libfreebl3.so" (CRC mismatch).

warning: the debug information found in 
"/usr/lib/debug/usr/lib64/libfreebl3.so.debug" does not match 
"/usr/lib64/libfreebl3.so" (CRC mismatch).

Missing separate debuginfo for /usr/lib64/libfreebl3.so
Try: yum --disablerepo='*' --enablerepo='*-debug*' install 
/usr/lib/debug/.build-id/68/195872ecfb188389d29aaf01031a976fd18168.debug
[Thread debugging using libthread_db enabled]


Program received signal SIGSEGV, Segmentation fault.
memcpy () at ../sysdeps/x86_64/memcpy.S:422
422 movq16(%rsi), %r9
Missing separate debuginfos, use: debuginfo-install libXau-1.0.5-1.el6.x86_64 
libidn-1.18-2.el6.x86_64 libtool-ltdl-2.2.6-15.5.el6.x86_64 
libxcb-1.5-1.el6.x86_64
(gdb) bt
#0  memcpy () at ../sysdeps/x86_64/memcpy.S:422
#1  0x0063f58f in sdl_deserialize_string (in=0x7fffa210) at 
/home/cpeasyapache/src/php-5.4.20/ext/soap/php_sdl.c:1208
#2  0x00644274 in sdl_deserialize_type (type=0x70640488, 
types=0x7062bc68, encoders=0x7063add8, in=0x7fffa210)
at /home/cpeasyapache/src/php-5.4.20/ext/soap/php_sdl.c:1329
#3  0x006443ac in sdl_deserialize_type (type=0x7063aa18, 
types=0x7

Bug #65802 [Opn]: Segmentation fault on creating new SoapClient

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65802&edit=1

 ID: 65802
 Updated by: fel...@php.net
 Reported by:karen dot thompkins at americanlanternpress dot com
 Summary:Segmentation fault on creating new SoapClient
 Status: Open
 Type:   Bug
 Package:SOAP related
 Operating System:   Linux version 2.6.32-279.5.2.el6
 PHP Version:5.4.20
 Block user comment: N
 Private report: N

 New Comment:

I can't reproduce it, are you able to reproduce it without local_cert' and 
'passphrase' data?


Previous Comments:

[2013-10-01 16:25:49] karen dot thompkins at americanlanternpress dot com

Description:

Script ran fine until early this morning when cPanel ran its nightly update. I 
am unable to track down what might be causing the issue.

Configure: Command  './configure' '--enable-bcmath' '--enable-calendar' 
'--enable-ftp' '--enable-libxml' '--enable-mbstring' '--enable-pdo=shared' 
'--enable-soap' '--enable-sockets' '--enable-zip' '--prefix=/usr/local' 
'--with-apxs2=/usr/local/apache/bin/apxs' '--with-curl=/opt/curlssl/' 
'--with-gd' '--with-imap=/opt/php_with_imap_client/' '--with-imap-ssl=/usr' 
'--with-jpeg-dir=/usr' '--with-kerberos' '--with-libdir=lib64' 
'--with-libxml-dir=/opt/xml2' '--with-libxml-dir=/opt/xml2/' 
'--with-mcrypt=/opt/libmcrypt/' '--with-mysql=/usr' 
'--with-mysql-sock=/var/lib/mysql/mysql.sock' '--with-openssl=/usr' 
'--with-openssl-dir=/usr' '--with-pcre-regex=/opt/pcre' 
'--with-pdo-mysql=shared' '--with-pdo-sqlite=shared' '--with-pic' 
'--with-png-dir=/usr' '--with-xpm-dir=/usr' '--with-zlib' 
'--with-zlib-dir=/usr' 

cURL supportenabled
cURL Information7.24.0
Age 3
Features
AsynchDNS   No
Debug   No
GSS-Negotiate   No
IDN Yes
IPv6Yes
Largefile   Yes
NTLMYes
SPNEGO  No
SSL Yes
SSPINo
krb4No
libzYes
CharConvNo
Protocols   dict, file, ftp, ftps, gopher, http, https, imap, imaps, pop3, 
pop3s, rtsp, smtp, smtps, telnet, tftp
Hostx86_64-unknown-linux-gnu
SSL Version OpenSSL/1.0.0
ZLib Version1.2.3 

libxml
libXML support  active
libXML Compiled Version 2.9.0
libXML Loaded Version   20900
libXML streams  enabled 

soap
Soap Client enabled
Soap Server enabled

Directive   Local Value Master Value
soap.wsdl_cache 1   1
soap.wsdl_cache_dir /tmp/tmp
soap.wsdl_cache_enabled 1   1
soap.wsdl_cache_limit   5   5
soap.wsdl_cache_ttl 86400   86400

Test script:
---
$wsdl = "https://api.verticalresponse.com/wsdl/1.0/VRAPI.wsdl";; //location of 
the wsdl
$vr = new SoapClient($wsdl,
 array (
// 'local_cert' => $cert,
// 'passphrase' => $cert_pass
)
);

Expected result:

Soap client assigned to variable

Actual result:
--
Segmentation fault

# gdb php
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-56.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/local/bin/php...done.
(gdb) run vr.php
Starting program: /usr/local/bin/php vr.php
warning: the debug information found in 
"/usr/lib/debug//usr/lib64/libfreebl3.so.debug" does not match 
"/usr/lib64/libfreebl3.so" (CRC mismatch).

warning: the debug information found in 
"/usr/lib/debug/usr/lib64/libfreebl3.so.debug" does not match 
"/usr/lib64/libfreebl3.so" (CRC mismatch).

Missing separate debuginfo for /usr/lib64/libfreebl3.so
Try: yum --disablerepo='*' --enablerepo='*-debug*' install 
/usr/lib/debug/.build-id/68/195872ecfb188389d29aaf01031a976fd18168.debug
[Thread debugging using libthread_db enabled]


Program received signal SIGSEGV, Segmentation fault.
memcpy () at ../sysdeps/x86_64/memcpy.S:422
422 movq16(%rsi), %r9
Missing separate debuginfos, use: debuginfo-install libXau-1.0.5-1.el6.x86_64 
libidn-1.18-2.el6.x86_64 libtool-ltdl-2.2.6-15.5.el6.x86_64 
libxcb-1.5-1.el6.x86_64
(gdb) bt
#0  memcpy () at ../sysdeps/x86_64/memcpy.S:422
#1  0x0063f58f in sdl_deserialize_string (in=0x7fffa210) at 
/home/cpeasyapache/src/php-5.4.20/ext/soap/php_sdl.c:1208
#2  0x00644274 in sdl_deserialize_type (type=0x70640488, 
types=0x7062bc68, encoders=0x7063add8, in=0x7fffa210)
at /home/cpeasyapache/src/php-5.4.20/ext/soap/php_sdl.c:1329
#3  0x006443ac in sdl_deserialize_type (type=0x7063aa18, 
types=0x7062bc68, encoders=0x7063add8, in=0x7fffa210)
at /home/cpeasyapache/src/php-5.4.20/ext/soap/php_sdl.c:1378
#4  0

Bug #65689 [Opn->Fbk]: PDO_Firebird memory leaks when using exec()

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65689&edit=1

 ID: 65689
 Updated by: fel...@php.net
 Reported by:slavb18 at gmail dot com
 Summary:PDO_Firebird memory leaks when using exec()
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:PDO related
 Operating System:   any
 PHP Version:5.4.19
 Block user comment: N
 Private report: N

 New Comment:

Can you include a valgrind log of memory leak for futher analysis?


Previous Comments:

[2013-09-17 11:23:04] slavb18 at gmail dot com

Description:

function firebird_handle_doer calls firebird_alloc_prepare_stmt 
and should call isc_dsql_free_statement







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65689&edit=1

Bug #65641 [Opn->Asn]: PHP-FPM incorrectly defines the SCRIPT_NAME variable when using Apache

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65641&edit=1

 ID: 65641
 Updated by: fel...@php.net
 Reported by:ryotakatsuki at gmail dot com
 Summary:PHP-FPM incorrectly defines the SCRIPT_NAME variable
 when using Apache
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:FPM related
 PHP Version:5.5.3
-Assigned To:
+Assigned To:fat
 Block user comment: N
 Private report: N



Previous Comments:

[2013-09-09 09:12:30] ryotakatsuki at gmail dot com

Description:

When using Apache + PHP_FPM, the SCRIPT_NAME variable is incorrectly set. For 
example, accessing "http://127.0.0.1/sample/test.php/a/b/c";, results in:

ORIG_SCRIPT_NAME: 
SCRIPT_NAME: /sample/test.php/a/b/c
ORIG_SCRIPT_FILENAME: //tmp/sample/test.php/a/b/c
SCRIPT_FILENAME: //tmp/sample/test.php
PATH_INFO: /a/b/c
ORIG_PATH_INFO: 

While when using mod_php, the values are:

SCRIPT_NAME: /sample/test.php
SCRIPT_FILENAME: /tmp/sample/test.php
PATH_INFO: /a/b/c

It is also working fine when using NGINX

Test script:
---
A sameple script to reproduce the issue:

');

echo("SCRIPT_NAME: " . $_SERVER['SCRIPT_NAME']);
echo('');
echo("ORIG_SCRIPT_FILENAME: " . $_SERVER['ORIG_SCRIPT_FILENAME']);
echo('');

echo("SCRIPT_FILENAME: " . $_SERVER['SCRIPT_FILENAME']);
echo('');

echo("PATH_INFO: " . $_SERVER['PATH_INFO']);
echo('');

echo("ORIG_PATH_INFO: " . $_SERVER['ORIG_PATH_INFO']);
echo('');

?>

And a very simple apache conf:

Alias /sample /tmp/sample
ProxyPassMatch .*/sample/(test.php.*) fcgi://127.0.0.1:9000//tmp/sample/$1

Require  all granted



Expected result:

ORIG_SCRIPT_NAME: 
SCRIPT_NAME: /sample/test.php
ORIG_SCRIPT_FILENAME: //tmp/sample/test.php/a/b/c
SCRIPT_FILENAME: //tmp/sample/test.php
PATH_INFO: /a/b/c
ORIG_PATH_INFO: 







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65641&edit=1

Bug #65687 [Opn->Fbk]: oci_connect() fails with "segmentation fault" signal

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65687&edit=1

 ID: 65687
 Updated by: fel...@php.net
 Reported by:grig-siren at rambler dot ru
 Summary:oci_connect() fails with "segmentation fault" signal
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Oracle related
 Operating System:   Linux
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.




Previous Comments:

[2013-09-17 10:15:34] grig-siren at rambler dot ru

Description:

I have tried to connect to Oracle database after user's password has expired. 
And result was: failure of PHP with message "child pid ... exit signal 
Segmentation fault(11)" in '/var/log/httpd/error_log' file.
Then I asked Oracle DBA to modify user's profile and set password life time to 
"unlimited" - and after that all my scripts again work correctly.

As I understand, the reason of such situation is warning message about password 
expiration issued by database during connection process. I think, this message 
is a big surprise for function oci_connect().







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65687&edit=1

Bug #65667 [Opn->Fbk]: ftp_nb_continue produces segfault

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65667&edit=1

 ID: 65667
 Updated by: fel...@php.net
 Reported by:imprec at gmail dot com
 Summary:ftp_nb_continue produces segfault
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:FTP related
 Operating System:   OSX
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

Hi, when seeing the backtrace on gdb, please run the following commands (and 
post the results):
p ftp
p data
p rcvd

Thanks.


Previous Comments:

[2013-09-13 16:11:48] imprec at gmail dot com

Description:

Running the following code on my OSX produces a segfault, see backtrace 

(gdb) (gdb) Starting program: /usr/local/bin/php /Users/romain/ftp-script.php
Reading symbols for shared libraries 
+... done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries ... done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x
0x000100387a75 in _php_stream_write ()
(gdb) #0  0x000100387a75 in _php_stream_write ()
No symbol table info available.
#1  0x00010013ab6f in ftp_nb_continue_read ()
No symbol table info available.
#2  0x000100137c2c in zif_ftp_nb_continue ()
No symbol table info available.
#3  0x0001003bf524 in dtrace_execute_internal ()
No symbol table info available.
#4  0x0001004430c2 in zend_do_fcall_common_helper_SPEC ()
No symbol table info available.
#5  0x0001003f310a in execute_ex ()
No symbol table info available.
#6  0x0001003bf458 in dtrace_execute_ex ()
No symbol table info available.
#7  0x0001003ce7ac in zend_execute_scripts ()
No symbol table info available.
#8  0x000100374602 in php_execute_script ()
No symbol table info available.
#9  0x000100467075 in do_cli ()
No symbol table info available.
#10 0x000100465e3d in main ()
No symbol table info available.
(gdb) %  

Test script:
---
$connection = ftp_connect('hostname', 21);
ftp_login($connection, 'login', 'password');

$localfile = __DIR__ . '/ftpfile';
$start = file_exists($localfile) ? FTP_AUTORESUME : 0;

$result = ftp_nb_get($connection, $localfile, '/remotedir/remotefile', 
FTP_BINARY, $start);

while ($result == FTP_MOREDATA) {
$result = ftp_nb_continue($connection);
}

ftp_close($connection);


Expected result:

No seg fault

Actual result:
--
A seg fault






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65667&edit=1

Bug #46064 [Opn->Csd]: Exception when creating ReflectionProperty object on dynamicly created property

[felipe]

Edit report at https://bugs.php.net/bug.php?id=46064&edit=1

 ID: 46064
 Updated by: fel...@php.net
 Reported by:zemi dot inet at gmail dot com
 Summary:Exception when creating ReflectionProperty object on
 dynamicly created property
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Reflection related
 Operating System:   Linux amoeba 2.6.22-14-server
 PHP Version:5.2.6
-Assigned To:
+Assigned To:felipe
 Block user comment: N
 Private report: N



Previous Comments:

[2008-10-29 15:06:29] fel...@php.net

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

We need add some examples for this case. The tests added with the patch can 
help.
http://news.php.net/php.cvs/53766


[2008-09-12 11:16:08] zemi dot inet at gmail dot com

Description:

Always getting exception when creating ReflectionProperty object on dynamicly 
created property.
Discovered when I tried to use ReflectionProperty::isDefault().
I presume it returns true when property is created on compile-time and false 
when dynamicly created on run-time?

Reproduce code:
---
class x {
 public $x = 1;
 public $y = 1;
}

$o = new x;
$o->z = 1;

$reflector = new ReflectionProperty($o, 'z');

$d = $reflector->isDefault();

Expected result:

$d == false

Actual result:
--
Fatal error: Uncaught exception 'ReflectionException' with message 'Property 
x::$z does not exist' on line: $reflector = new ReflectionProperty($o, 'z');






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=46064&edit=1

Bug #65601 [Ver->Asn]: SplFileObject->valid() should not return false when it reached EOF

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65601&edit=1

 ID: 65601
 Updated by: fel...@php.net
 Reported by:kentaro at ranvis dot com
 Summary:SplFileObject->valid() should not return false when
 it reached EOF
-Status: Verified
+Status: Assigned
 Type:   Bug
 Package:SPL related
 Operating System:   *
 PHP Version:5.5.3
-Assigned To:
+Assigned To:colder
 Block user comment: N
 Private report: N



Previous Comments:

[2013-09-01 11:49:58] requi...@php.net

Related to bug #65600.

The first eof() assertion should be === true as rewind() would have rewound the 
stream and, to maintain normal iteration behavior, read the first line.

Using the READ_AHEAD flag will enable the behavior you're expecting. I don't 
know 
if that requirement is intentional or necessary.


[2013-09-01 10:15:20] kentaro at ranvis dot com

Description:

PHP document says that SplFileObject->valid() checks if a file pointer is not 
at EOF, just like SplFileObject->eof().
But since SplFileObject implements Iterator, valid() should not return false 
while the current element is valid.

Test script:
---
$f = new SplFileObject('php://memory', 'r+');
assert('$f instanceof Iterator');
$f->fwrite("line 1");
$f->rewind();
assert('$f->valid() === true');
assert('$f->eof() === false');
assert('$f->current() === "line 1"');
assert('$f->valid() === true'); // fails
assert('$f->eof() === true');








-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65601&edit=1

Bug #65392 [Opn->Fbk]: Warning for a success message with ftp_chdir

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65392&edit=1

 ID: 65392
 Updated by: fel...@php.net
 Reported by:Laurent dot Lyaudet at gmail dot com
 Summary:Warning for a success message with ftp_chdir
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:FTP related
 Operating System:   Debian Linux
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

Do you know what ftp server are you trying connect to?


Previous Comments:

[2013-08-05 09:45:47] Laurent dot Lyaudet at gmail dot com

Description:

Hi,

I found the following trace in an error log of a php script I launch as 
background task.

//---
root@wheezyDEVLaurent:~# more /home/web/teliedi/log/logErreur.txt
2013-08-05 : 11:05:11 :  02 | runPersistant.php
   | ftp_chdir(): Requested file action okay, co
mpleted.
2013-08-05 : 11:05:11 : CALLSTACK - DESC (Nb ignores : 1, Nb limite : 0)

--

Appel : ErreurCli(2,"ftp_chdir(): Requested file action okay, completed.","/home
/web/teliedi/appli/includes/classes/CRecipientFtp.php",341,array(true,CServeurFt
p))

Fichier : /home/web/teliedi/appli/includes/classes/CRecipientFtp.php
Ligne : 341
Appel : ftp_chdir(RESOURCE,"TOUR_XML")

//

It is surprising to obtain a warning but the message is "Requested file action 
okay, completed."

The version is latest debian package for wheezy but more ancient than 5.4.17
root@wheezyDEVLaurent:~# php --version
PHP 5.4.4-14+deb7u3 (cli) (built: Jul 17 2013 14:54:08)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans

I have no idea how to reproduce this bug and I don't know if it has been 
already corrected. I think a code analysis of ftp_chdir is needed to find in 
which case one can throw a warning with this message.

Let me know if I can help further.

Best regards,
   Laurent Lyaudet











-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65392&edit=1

Bug #65621 [Opn->Nab]: preg_split cause segmentation fault

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65621&edit=1

 ID: 65621
 Updated by: fel...@php.net
 Reported by:andrey dot bukatov at gmail dot com
 Summary:preg_split cause segmentation fault
-Status: Open
+Status: Not a bug
 Type:   Bug
-Package:Regexps related
+Package:PCRE related
 Operating System:   Ubuntu
 PHP Version:5.4.19
 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.

This is known issue on lib PCRE, not a PHP bug.


Previous Comments:

[2013-09-05 10:52:07] andrey dot bukatov at gmail dot com

Description:

This code cause segmentation fault in PHP Version 5.4.19

Test script:
---
https://bugs.php.net/bug.php?id=65621&edit=1

Bug #65542 [Fbk]: zend_parse_parameters return string length == 0

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65542&edit=1

 ID: 65542
 Updated by: fel...@php.net
 Reported by:Azq2 at ya dot ru
 Summary:zend_parse_parameters return string length == 0
 Status: Feedback
 Type:   Bug
 Package:Unknown/Other Function
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

I mean what data type have you used for addr_length and user_length in your C 
code.


Previous Comments:

[2013-08-24 21:02:17] azq2 at ya dot ru

String. 

$db -> connect("127.0.0.2", "root", "qwerty", "test", 1);


[2013-08-24 20:59:51] fel...@php.net

What data type have you used for store the string length?


[2013-08-24 20:56:55] Azq2 at ya dot ru

Description:

I have this code in my extension: 

if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "l|bl", &addr, 
&addr_length, &user, &user_length, &password, &password_length, &db, 
&db_length, 
&port, &persistent, &flags) != SUCCESS)
WRONG_PARAM_COUNT; 

and i call from php: 
$db -> connect("127.0.0.2", "root", "qwerty", "test", 1); 


But... addr_length and user_length equals as zero O_O But addr and user not 
empty 
and contains my values... o_O







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65542&edit=1

Bug #65542 [Opn->Fbk]: zend_parse_parameters return string length == 0

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65542&edit=1

 ID: 65542
 Updated by: fel...@php.net
 Reported by:Azq2 at ya dot ru
 Summary:zend_parse_parameters return string length == 0
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Unknown/Other Function
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

What data type have you used for store the string length?


Previous Comments:

[2013-08-24 20:56:55] Azq2 at ya dot ru

Description:

I have this code in my extension: 

if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "l|bl", &addr, 
&addr_length, &user, &user_length, &password, &password_length, &db, 
&db_length, 
&port, &persistent, &flags) != SUCCESS)
WRONG_PARAM_COUNT; 

and i call from php: 
$db -> connect("127.0.0.2", "root", "qwerty", "test", 1); 


But... addr_length and user_length equals as zero O_O But addr and user not 
empty 
and contains my values... o_O







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65542&edit=1

Bug #65433 [Opn]: Static analyzer errors

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65433&edit=1

 ID: 65433
 Updated by: fel...@php.net
 Reported by:devzone dot my at gmail dot com
 Summary:Static analyzer errors
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   all
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

I just see a lot of false positive ones there.


Previous Comments:

[2013-08-10 00:05:53] devzone dot my at gmail dot com

Description:

Version: 5.5.1 (Release)

**sapi**
[sapi/cgi/fastcgi.c:887]: (error) Uninitialized variable: hdr
[sapi/cli/php_cli.c:1289]: (error) Common realloc mistake: 'ini_entries' nulled 
but not freed upon failure
[sapi/cli/php_cli.c:1299]: (error) Common realloc mistake: 'ini_entries' nulled 
but not freed upon failure
[sapi/cli/php_cli.c:1305]: (error) Common realloc mistake: 'ini_entries' nulled 
but not freed upon failure
[sapi/cli/php_cli.c:1345]: (error) Common realloc mistake: 'ini_entries' nulled 
but not freed upon failure
[sapi/cgi/cgi_main.c:1547]: (error) Possible null pointer dereference: str
[sapi/fpm/fpm/fastcgi.c:513]: (error) Uninitialized variable: hdr
[sapi/fpm/fpm/fpm_sockets.c:80]: (error) Common realloc mistake: 'env_value' 
nulled but not freed upon failure
[sapi/isapi/stresstest/stresstest.cpp:589]: (error) Memory leak: environment
[sapi/tux/php_tux.c:143]: (error) Common realloc mistake: 'vec' nulled but not 
freed upon failure
 
**main**
[main/php_ini.c:675]: (error) Common realloc mistake: 'php_ini_scanned_files' 
nulled but not freed upon failure

**win32**
[win32/readdir.c:48]: (error) Memory leak: filespec

**TSRM**
[TSRM/TSRM.c:229]: (error) Common realloc mistake: 'resource_types_table' 
nulled 
but not freed upon failure
[TSRM/TSRM.c:617]: (error) Uninitialized variable: mutexp

**ext**
[ereg/regex/regcomp.c:205]: (error) Uninitialized variable: c
[gd/libgd/gd_topal.c:1464]: (error) Uninitialized variable: shift_temp
[intl/calendar/calendar_methods.cpp:566]: (error) Uninitialized variable: 
variant
[intl/resourcebundle/resourcebundle_class.c:177]: (error) Uninitialized 
variable: rb
[intl/resourcebundle/resourcebundle_class.c:181]: (error) Uninitialized 
variable: rb
[mbstring/libmbfl/tests/conv_encoding.tests/gen_exp.c:257]: (error) Buffer is 
accessed out of bounds.
[mbstring/libmbfl/tests/conv_encoding.tests/gen_exp.c:493]: (error) Resource 
leak: fp
[mbstring/libmbfl/mbfl/mbfilter.c:1180]: (error) Uninitialized variable: 
needle_u8
[mbstring/oniguruma/enc/euc_jp.c:204]: (error) Uninitialized variable: r
[mbstring/oniguruma/enc/sjis.c:238]: (error) Uninitialized variable: r
[mbstring/oniguruma/regenc.c:852]: (error) Common realloc mistake: 'list' 
nulled 
but not freed upon failure
[mbstring/ucgendat/ucgendat.c:484]: (error) Common realloc mistake: 'pdecomps' 
nulled but not freed upon failure
[mbstring/ucgendat/ucgendat.c:546]: (error) Common realloc mistake: 'title' 
nulled but not freed upon failure
[mbstring/ucgendat/ucgendat.c:593]: (error) Common realloc mistake: 'upper' 
nulled but not freed upon failure
[mbstring/ucgendat/ucgendat.c:640]: (error) Common realloc mistake: 'lower' 
nulled but not freed upon failure
[mbstring/ucgendat/ucgendat.c:675]: (error) Common realloc mistake: 'ccl' 
nulled 
but not freed upon failure
[mbstring/ucgendat/ucgendat.c:756]: (error) Common realloc mistake: 'nums' 
nulled but not freed upon failure
[mbstring/ucgendat/ucgendat.c:794]: (error) Common realloc mistake: 'ncodes' 
nulled but not freed upon failure
[mbstring/oniguruma/regexec.c:2230]: (error) Uninitialized variable: len
[mbstring/oniguruma/regexec.c:2269]: (error) Uninitialized variable: len
[opcache/zend_accelerator_blacklist.c:133]: (error) Memory leak: regexp
[oci8/oci8.c:2817]: (error) Memory leak: session_pool
[opcache/zend_accelerator_blacklist.c:243]: (error) Resource leak: fp
[opcache/zend_accelerator_util_funcs.c:479]: (error) Uninitialized variable: 
new_ce
[opcache/zend_accelerator_util_funcs.c:488]: (error) Uninitialized variable: 
new_prototype
[opcache/zend_accelerator_util_funcs.c:590]: (error) Uninitialized variable: 
new_ce
[odbc/php_odbc.c:2458]: (error) Uninitialized variable: rc
[snmp/snmp.c:1510]: (error) Uninitialized variable: a3
[snmp/snmp.c:1510]: (error) Uninitialized variable: a4
[snmp/snmp.c:1510]: (error) Uninitialized variable: a5
[snmp/snmp.c:1510]: (error) Uninitialized variable: a6
[snmp/snmp.c:1510]: (error) Uninitialized variable: a7
[standard/crypt_sha256.c:401]: (error) Possible null pointer dereference: 
copied_salt
[standard/crypt_sha512.c:435]: (error) Possible null pointer dereference: 
copied_salt
[sybase_ct/php_sybase_ct.c:792]: (error) Dereferencing 'sybase_ptr' after it is 
deallocated / released
[sybase_ct/php_sybase_ct.c:796]: (error) Memory pointed to by 'sybase_ptr' is 
freed twice.

 

Test scrip

Bug #65340 [Opn]: Memory leak when using magic __set ?

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65340&edit=1

 ID: 65340
 Updated by: fel...@php.net
 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:

See bug #48197


Previous Comments:

[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:
---
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=65340&edit=1

Bug #65339 [Opn->Nab]: 08 and 8 are not the same and 09 and 9 are also not the same

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65339&edit=1

 ID: 65339
 Updated by: fel...@php.net
 Reported by:dondanielsgh at yahoo dot com
 Summary:08 and 8 are not the same and 09 and 9 are also not
 the same
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:PHP options/info functions
 Operating System:   windows
 PHP Version:5.5.1
 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




Previous Comments:

[2013-07-26 00:03:38] cmbecker69 at gmx dot de

| the results should be correct.

Actually the results are correct.  07, 08 and 09 are treated as 
octal integers, and the documentation on integers
() states:

| If an invalid digit is given in an octal integer (i.e. 8 or 9),
| the rest of the number is ignored.


[2013-07-25 20:42:49] dondanielsgh at yahoo dot com

Description:

$x = 07;
if($x == 7){
echo 'correct';
}else{
echo 'they are not the same';
}

$x = 08;
if($x == 8){
echo 'correct';
}else{
echo 'they are not the same';
}

$x = 09;
if($x == 9){
echo 'correct';
}else{
echo 'they are not the same';
}

Test script:
---
$x = 07;
if($x == 7){
echo 'correct';
}else{
echo 'they are not the same';
}

$x = 08;
if($x == 8){
echo 'correct';
}else{
echo 'they are not the same';
}

$x = 09;
if($x == 9){
echo 'correct';
}else{
echo 'they are not the same';
}

Expected result:

$x = 08;
if($x == 8){
echo 'correct';
}else{
echo 'they are not the same';
}

$x = 09;
if($x == 9){
echo 'correct';
}else{
echo 'they are not the same';
}

the results should be correct.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65339&edit=1

Bug #65163 [Opn->Asn]: Collator::__construct inconsistency between doc and implementation

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65163&edit=1

 ID: 65163
 Updated by: fel...@php.net
 Reported by:poinsot dot julien at gmail dot co
 Summary:Collator::__construct inconsistency between doc and
 implementation
-Status: Open
+Status: Assigned
 Type:   Bug
-Package:intl
+Package:I18N and L10N related
 PHP Version:Irrelevant
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N



Previous Comments:

[2013-06-28 21:13:04] poinsot dot julien at gmail dot co

Description:

There is an inconsistency between current PHP implemention and the 
documentation about Collator::__construct, Collator::create and collator_create.

It says:

Special values for locales can be passed in - if null is passed for the locale, 
the default locale collation rules will be used. If empty string ("") or "root" 
are passed, UCA rules will be used.

But actual implementation of collator_ctor in 
ext/intl/collator/collator_create.c does not check type of its parameter:

if( zend_parse_parameters( ZEND_NUM_ARGS() TSRMLS_CC, "s", &locale, &locale_len 
) == FAILURE )
/* ... */
if(locale_len == 0) {
locale = intl_locale_get_default(TSRMLS_C);
}

So, for PHP, a NULL value as an empty string imply the default locale.

Test script:
---
ini_set('intl.default_locale', fr_CA);

$coll = new Collator('');
var_dump(
$coll->getLocale(Locale::VALID_LOCALE)
);

Expected result:

string(4) "root"

Actual result:
--
string(5) "fr_FR"






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65163&edit=1

Bug #65228 [Opn->Csd]: FTPs memory leak

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65228&edit=1

 ID: 65228
 Updated by: fel...@php.net
 Reported by:marco dot beierer at mbsecurity dot ch
 Summary:FTPs memory leak
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Streams related
 Operating System:   Gentoo Linux
 PHP Version:5.5.0
-Assigned To:
+Assigned To:felipe
 Block user comment: N
 Private report: N

 New Comment:

The patch has been applied to 5.4+ branches.

http://git.php.net/?p=php-src.git;a=commitdiff;h=0863a0d6a0f740874b4ef8dc732a4ec94949470c

Thanks for the patch.


Previous Comments:

[2013-07-09 20:56:03] marco dot beierer at mbsecurity dot ch

I forgot to close the FTPs connection in the test script, but that does not 
affect the result...


[2013-07-09 20:49:00] marco dot beierer at mbsecurity dot ch

Description:

There is a memory leak in the functions ftp_login, ftp_get and ftp_fget, if FTP 
is used over SSL.

The leak is caused in the file ext/ftp/ftp.c, because just SSL_shutdown(), but 
not SSL_free(), is called when the connection gets closed.

I have tested the PHP versions 5.3.23, 5.4.13 and 5.5.0 and all are affected by 
this issue.

The memory leak could be reproduced by connecting to a FTP server via FTPs (see 
test script).

Please find attached a patch for this issue, but I am not a C expert and thus 
the patch maybe not perfect. Especially the part for freeing SSL_CTX. However 
the patch works fine and fixes the problem.

Test script:
---


Expected result:

No memory leak.

Actual result:
--
==16800== 59,938 (808 direct, 59,130 indirect) bytes in 1 blocks are definitely 
lost in loss record 211 of 227
==16800==at 0x4C2B4CB: malloc (vg_replace_malloc.c:270)
==16800==by 0x701E0AD: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.0)
==16800==by 0x72EA56F: SSL_new (in /usr/lib64/libssl.so.1.0.0)
==16800==by 0x5069B4: data_accept (in /usr/lib64/php5.4/bin/php)
==16800==by 0x508A25: ftp_get (in /usr/lib64/php5.4/bin/php)
==16800==by 0x5054A5: zif_ftp_get (in /usr/lib64/php5.4/bin/php)
==16800==by 0xBF64DC4: ???
==16800==by 0x7D99D1: zend_do_fcall_common_helper_SPEC (in 
/usr/lib64/php5.4/bin/php)
==16800==by 0x78D903: execute (in /usr/lib64/php5.4/bin/php)
==16800==by 0xBF66501: ???
==16800==by 0x72696A: zend_execute_scripts (in /usr/lib64/php5.4/bin/php)
==16800==by 0x6B9E77: php_execute_script (in /usr/lib64/php5.4/bin/php)


==16800== 616,834 (808 direct, 616,026 indirect) bytes in 1 blocks are 
definitely lost in loss record 227 of 227
==16800==at 0x4C2B4CB: malloc (vg_replace_malloc.c:270)
==16800==by 0x701E0AD: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.0)
==16800==by 0x72EA56F: SSL_new (in /usr/lib64/libssl.so.1.0.0)
==16800==by 0x50766C: ftp_login (in /usr/lib64/php5.4/bin/php)
==16800==by 0x506479: zif_ftp_login (in /usr/lib64/php5.4/bin/php)
==16800==by 0xBF64DC4: ???
==16800==by 0x7D99D1: zend_do_fcall_common_helper_SPEC (in 
/usr/lib64/php5.4/bin/php)
==16800==by 0x78D903: execute (in /usr/lib64/php5.4/bin/php)
==16800==by 0xBF66501: ???
==16800==by 0x72696A: zend_execute_scripts (in /usr/lib64/php5.4/bin/php)
==16800==by 0x6B9E77: php_execute_script (in /usr/lib64/php5.4/bin/php)
==16800==by 0x7DC7CD: do_cli (in /usr/lib64/php5.4/bin/php)


==16800== LEAK SUMMARY:
==16800==definitely lost: 1,622 bytes in 3 blocks
==16800==indirectly lost: 675,156 bytes in 1,054 blocks
==16800==  possibly lost: 687,752 bytes in 15 blocks
==16800==still reachable: 3,636 bytes in 8 blocks
==16800== suppressed: 0 bytes in 0 blocks


==16800== ERROR SUMMARY: 1227 errors from 1017 contexts (suppressed: 2 from 2)







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65228&edit=1

Bug #65219 [Opn->Asn]: PDO/dblib not working anymore ("use dbName" not sent)

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65219&edit=1

 ID: 65219
 Updated by: fel...@php.net
 Reported by:f dot marquis at of2m dot fr
 Summary:PDO/dblib not working anymore ("use dbName" not
 sent)
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:PDO related
 Operating System:   CentOS 6.4
 PHP Version:5.4.17
-Assigned To:
+Assigned To:ssufficool
 Block user comment: N
 Private report: N



Previous Comments:

[2013-07-08 13:37:43] f dot marquis at of2m dot fr

Description:

All queries to our MSSQL 2008 database (PDO_dblib with freeTDS) are failing 
since PHP 5.4.17 (same code)

setting freeTDS into debug mode seems to indicate that the SQL queries are not 
sent to the correct database, but to 'master' database, so 
queried object are not found.

FreeTDS log with PHP 5.4.17 :
...
(dblib.c:239):dblib_add_connection(0x7f001af738e0, 0x7f002be94540)
(dblib.c:4317):dbsetopt(0x7f002be93a00, 7, 2147483647, -1)
(dblib.c:4432):UNIMPLEMENTED dbsetopt(option = 7)
(dblib.c:4317):dbsetopt(0x7f002be93a00, 17, 2147483647, -1)
(dblib.c:4432):UNIMPLEMENTED dbsetopt(option = 17)
(dblib.c:4317):dbsetopt(0x7f002be93a00, 35, 1, -1)
(dblib.c:761):dbsetlname(0x7f002be93850, Emploi, 14)
(dblib.c:5762):dbsetuserdata(0x7f002be93a00, 0x7f002a851fa0)
(dblib.c:3196):dbcancel(0x7f002be93a00)
(query.c:2155):tds_send_cancel: not in_cancel and idle
(dblib.c:1312):dbcmd(0x7f002be93a00, SELECT col FROM table WHERE id = 1 )
...

FreeTDS log with PHP 5.4.11 (working) :
...
(dblib.c:239):dblib_add_connection(0x7fbc5d3d68e0, 0x7fbc6ec007f0)
(dblib.c:4317):dbsetopt(0x7fbc6ebffe30, 7, 2147483647, -1)
(dblib.c:4432):UNIMPLEMENTED dbsetopt(option = 7)
(dblib.c:4317):dbsetopt(0x7fbc6ebffe30, 17, 2147483647, -1)
(dblib.c:4432):UNIMPLEMENTED dbsetopt(option = 17)
(dblib.c:4317):dbsetopt(0x7fbc6ebffe30, 35, (null), -1)
(dblib.c:7929):dbperror(0x7fbc6ebffe30, 20176, 0)
(dblib.c:7981):20176: "Called dbsetopt with parameter 3 NULL"
(dblib.c:5780):dbgetuserdata(0x7fbc6ebffe30)
(dblib.c:8002):"Called dbsetopt with parameter 3 NULL", client returns 2 
(INT_CANCEL)
(dblib.c:1398):dbuse(0x7fbc6ebffe30, Emploi)
(dblib.c:1312):dbcmd(0x7fbc6ebffe30, use [Emploi])
(dblib.c:1319):dbcmd() bufsz = 0
(dblib.c:1369):dbsqlexec(0x7fbc6ebffe30)
(dblib.c:6862):dbsqlsend(0x7fbc6ebffe30)
(mem.c:615):tds_free_all_results()
(util.c:156):Changed query state from IDLE to QUERYING
(write.c:140):tds_put_string converting 12 bytes of "use [Emploi]"
(write.c:168):tds_put_string wrote 24 bytes
(util.c:156):Changed query state from QUERYING to PENDING
(net.c:741):Sending packet
...

You can see that the "use [dbName]" is not sent with the same way. The query is 
executed in "master" context, and that's why it's failing.
regression from https://bugs.php.net/bug.php?id=64338 "pdo_dblib can't connect 
to Azure SQL"


Test script:
---
$pdo = new \PDO('dblib:host=hostname;dbname=dbname', 'username', 'password');
$stmt = $pdo->query('SELECT col FROM table WHERE id = 1');
var_dump($stmt);

Expected result:

PDOStatement with the matching line from existing table

Actual result:
--
false, with this error : General SQL Server error: Check messages from the SQL 
Server [208] (severity 16) => Invalid object name








-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65219&edit=1

Bug #65227 [Opn->Csd]: Memory leak in gmp_cmp second parameter

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65227&edit=1

 ID: 65227
 Updated by: fel...@php.net
 Reported by:frozenf...@php.net
 Summary:Memory leak in gmp_cmp second parameter
-Status: Open
+Status: Closed
 Type:   Bug
 Package:GNU MP related
 Operating System:   Irrelevant
 PHP Version:unknown
 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=281936b29535ae095350abb274acef0ae548a431
Log: - Fixed bug #65227 (Memory leak in gmp_cmp second parameter)


Previous Comments:

[2013-07-09 16:25:27] frozenf...@php.net

I noticed shortly after filing the bug that this issue *may* be resolved as of 
https://github.com/php/php-
src/commit/7713b8c2ac2d8fbacaf897ff0c0a202a7b7abf49#ext/gmp/gmp.c

The issue may have resulted from the lack of a free of temp_b after 
https://github.com/php/php-
src/blob/a666285bc2488b7f7362368c388e41428610ad1d/ext/gmp/gmp.c#L1337, which 
would apply to all versions except 5.next


[2013-07-09 16:17:47] frozenf...@php.net

Description:

Reporting this bug for a third party 
(http://www.reddit.com/r/PHP/comments/1hx7qz/what_is_going_on_here_how_do_i_fix_t
his_memory/), and related to a user note 
(http://www.php.net/manual/en/function.gmp-cmp.php#99120).

The gmp_cmp function leaks memory when a string is used as the value of the 
second parameter.

My guess is that it relates to the way that the type is juggled in the gmp_cmp 
function (https://github.com/php/php-src/blob/master/ext/gmp/gmp.c#L848), where 
it checks the type of the second parameter to see if it's a long. It doesn't 
however check if the second parameter is a string, or really any other type.



Test script:
---
Third party's example code can be found at 
http://www.reddit.com/r/PHP/comments/1hx7qz/what_is_going_on_here_how_do_i_fix_this_memory/







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65227&edit=1

Bug #65139 [->Nab]: http 500

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65139&edit=1

 ID: 65139
 Updated by: fel...@php.net
 Reported by:chromegame at 163 dot com
 Summary:http 500
-Status: 打开
+Status: Not a bug
 Type:   Bug
 Package:opcache
 Operating System:   windows2008r2
 PHP Version:5.5.0
 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.

.


Previous Comments:

[2013-07-05 01:41:44] chromegame at 163 dot com

I have solved this problem, through the investigation step by step, it is my 
mistake, because before has been using the old php.ini, after changing into 
5.5.0, 
forget to change this place, caused opcache to open php.exe cannot run, /*** 
session.save_path = "C:\Windows\Temp" */ please forgive this problem submitted 
by 
me, is my own mistakes.


[2013-07-03 22:05:17] fel...@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.




[2013-06-27 02:05:48] chromegame at 163 dot com

Description:

I downloaded the php-5.5.0-nts-Win32-VC11-x64.zip, when I was normal in the 
local 
test in windows2012, a server windows2008r2 is normal, but in another server 
windows2008r2, it appears that the HTTP 500 internal server error, also did not 
appear any other tips, when I will opcache.enable=0 or directly delete 
ext\php_opcache.dll, normal, summarizes the reasons, as long as the open OPC, 
PHP 
cannot run, HTML can open, is this why?
My configuration is as follows:


Test script:
---
[opcache]
zend_extension=php_opcache.dll
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=6000
opcache.max_wasted_percentage=60
opcache.use_cwd=1
opcache.validate_timestamps=1
opcache.revalidate_freq=2
opcache.revalidate_path=0
opcache.save_comments=0
opcache.load_comments=1
opcache.fast_shutdown=1
opcache.enable_file_override=0
opcache.optimization_level=0x
opcache.dups_fix=0
opcache.blacklist_filename=
opcache.max_file_size=0
opcache.consistency_checks=0
opcache.force_restart_timeout=180
opcache.error_log=
opcache.log_verbosity_level=1
opcache.preferred_memory_model=
opcache.protect_memory=0
opcache.mmap_base=NULL








-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65139&edit=1

Bug #65139 [Opn->Fbk]: http 500

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65139&edit=1

 ID: 65139
 Updated by: fel...@php.net
 Reported by:chromegame at 163 dot com
 Summary:http 500
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:opcache
 Operating System:   windows2008r2
 PHP Version:5.5.0
 Block user comment: N
 Private report: N

 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.




Previous Comments:

[2013-06-27 02:05:48] chromegame at 163 dot com

Description:

I downloaded the php-5.5.0-nts-Win32-VC11-x64.zip, when I was normal in the 
local 
test in windows2012, a server windows2008r2 is normal, but in another server 
windows2008r2, it appears that the HTTP 500 internal server error, also did not 
appear any other tips, when I will opcache.enable=0 or directly delete 
ext\php_opcache.dll, normal, summarizes the reasons, as long as the open OPC, 
PHP 
cannot run, HTML can open, is this why?
My configuration is as follows:


Test script:
---
[opcache]
zend_extension=php_opcache.dll
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=6000
opcache.max_wasted_percentage=60
opcache.use_cwd=1
opcache.validate_timestamps=1
opcache.revalidate_freq=2
opcache.revalidate_path=0
opcache.save_comments=0
opcache.load_comments=1
opcache.fast_shutdown=1
opcache.enable_file_override=0
opcache.optimization_level=0x
opcache.dups_fix=0
opcache.blacklist_filename=
opcache.max_file_size=0
opcache.consistency_checks=0
opcache.force_restart_timeout=180
opcache.error_log=
opcache.log_verbosity_level=1
opcache.preferred_memory_model=
opcache.protect_memory=0
opcache.mmap_base=NULL








-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65139&edit=1

Bug #65120 [Opn->Fbk]: fpm build fails on ppc: #error Unsupported processor

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65120&edit=1

 ID: 65120
 Updated by: fel...@php.net
 Reported by:php-bugs-2013 at ryandesign dot com
 Summary:fpm build fails on ppc: #error Unsupported processor
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Compile Failure
 Operating System:   Mac OS X 10.5.8
 PHP Version:5.5.0
 Block user comment: N
 Private report: N

 New Comment:

Can you try the patch attached on bug #51772?


Previous Comments:

[2013-06-25 21:50:56] php-bugs-2013 at ryandesign dot com

I am not a C programmer and I'm not familiar with your code, so I'm probably 
not 
the best candidate to fix this.


[2013-06-25 15:56:54] fel...@php.net

Can you provide a patch that works on such architecture?


[2013-06-25 08:55:27] php-bugs-2013 at ryandesign dot com

Description:

Building the fpm sapi fails on a PowerBook G4 with Mac OS X 10.5.8 compiling 
with Apple's gcc 4.0.1 which comes with Xcode, with the following error:



:info:build /bin/sh 
/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_
lang_php/php55-fpm/work/php-5.5.0/libtool --silent --preserve-dup-deps --
mode=compile /usr/bin/gcc-4.0 -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0/sapi/fpm -Isapi/fpm/ -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/ -DPHP_ATOM_INC -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0/include -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0/main -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0 -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0/ext/date/lib -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0/ext/ereg/regex -
I/Volumes/Data/macports/leopard/include/libxml2 -
I/Volumes/Data/macports/leopard/include -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0/TSRM -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0/Zend  -
I/Volumes/Data/macports/leopard/include -no-cpp-precomp  -pipe -O2 -arch ppc -
fvisibility=hidden  -c 
/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_
lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm.c -o sapi/fpm/fpm/fpm.lo 
:info:build In file included from 
/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_
lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm_scoreboard.h:15,
:info:build  from 
/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_
lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm.c:21:
:info:build 
/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_
lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm_atomic.h:142:2: error: 
#error 
Unsupported processor. Please open a bug report (bugs.php.net).


Previous bug reports about fpm sapi build failure on PowerPC or POWER 
processors 
include #51214 (closed as not a bug because fpm wasn't part of php at that 
time); #51772 (closed as no feedback; there was a patch attached but someone 
said it was unstable); #54273 (closed as won't fix because the person handling 
the bug had no access to PowerPC equipment).







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65120&edit=1

Bug #65154 [Opn]: setup_verify implicitly adds default CA paths

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65154&edit=1

 ID: 65154
 Updated by: fel...@php.net
 Reported by:bholbrook at bomgar dot com
 Summary:setup_verify implicitly adds default CA paths
 Status: Open
 Type:   Bug
 Package:OpenSSL related
 Operating System:   all
 PHP Version:5.5.0
 Block user comment: N
 Private report: N

 New Comment:

Feel free to attach your patch to the report.

Thanks.


Previous Comments:

[2013-06-27 22:20:05] bholbrook at bomgar dot com

Description:

In openssl.c, the static setup_verify() function is designed to take a ZVAL 
array of directory and file paths, and return an X509_STORE* that contains the 
paths provided as trusted CA stores.

However, setup_verify() has a strange quirk, in that it requires there to 
always be at least one regular file and at least one directory in X509_STORE.

If the caller only specifies one or more directories and no regular files, 
setup_verify() will implicitly add OpenSSL's default CA file.

Conversely, if the caller only specifies one or more regular files and no 
directories, setup_verify() will implicitly add OpenSSL's default CA hash dir.

Why?  This behavior is both unnecessary and undesirable, but difficult to 
workaround.

I am calling setup_verify() with an array that contains a single directory of 
"trusted" CA certs for verification, but PHP is always implicitly including the 
default list of CA certs to the X509_STORE.  In order to prevent this from 
happening, I also need to specify a dummy regular file to setup_verify().  BUT, 
that's not all!  The dummy file cannot simply be /dev/null or some other empty 
file, it must actually parse as a valid PEM certificate in order for 
setup_verify() to consider the "file" requirement satisfied.

My expectation is that if I pass a single file or single hash_dir to this 
function, that is the *only* source that will be built into X509_STORE.  If 
_any_ valid input is provided to this function, there should be _no_ implicit 
behavior.

Please, rather than maintaining separate nfiles and ndirs counters, use a 
single "ntargets" counter that increments for both directory and valid file 
arguments. Then, if after parsing all array member arguments, if ntargets is 
still 0, feel free to add BOTH OpenSSL's default CA file and CA hash_dir, or 
whatever you feel is the most appropriate implicit behavior of this function.  
I have patched my PHP this way and am running in production.  I can provide the 
simple patch if necessary.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65154&edit=1

Bug #65138 [Opn->Nab]: Parse url don't recognize SMB protocol users

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65138&edit=1

 ID: 65138
 Updated by: fel...@php.net
 Reported by:roberto at spadim dot com dot br
 Summary:Parse url don't recognize SMB protocol users
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   any
 PHP Version:5.5.0
 Block user comment: N
 Private report: N

 New Comment:

parse_url() is not intended to parse smb uris.

Try something like 
https://github.com/owncloud/3rdparty/blob/master/smb4php/smb.php does.


Previous Comments:

[2013-06-26 20:35:46] roberto at spadim dot com dot br

Description:

i have a url using smb protocol (or cifs) it don't return the right 
user/password:
url:

smb://domain/user@password:host/folder

another problem with smb is the password... some passwords have @ and : 
characters...


any idea how to solve this?

Test script:
---
print_r(parse_url("smb://domain/user@password:host/folder"));

Expected result:

array (
  'scheme' => 'smb',
  'user' => 'domain/user',
  'password' => 'password',
  'host' => 'host',
  'path' => 'folder'
)

Actual result:
--
array (
  'scheme' => 'smb',
  'host' => 'domain',
  'path' => '/user@password:host/folder'
)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65138&edit=1

Bug #65193 [Opn->Nab]: openssl_private_encrypt OAEP only works AFTER PKCS1

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65193&edit=1

 ID: 65193
 Updated by: fel...@php.net
 Reported by:ly...@php.net
 Summary:openssl_private_encrypt OAEP only works AFTER PKCS1
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:OpenSSL related
 Operating System:   CentOS 2.6.18
 PHP Version:5.4.11
 Block user comment: N
 Private report: N

 New Comment:

Just read the code again, the problem is that the 3th try fails, but the 
extension does not clean $encrypted_message string. Causing a false positive 
for you. Just clean the variable before calling the function again.


Previous Comments:

[2013-07-03 17:03:05] fel...@php.net

It looks an issue on openssl library.
According to 
http://openssl.6102.n7.nabble.com/Proplem-with-RSA-private-encrypt-and-OAEP-td45517.html
 RSA_PKCS1_OAEP_PADDING is not intended to be used with RSA_private_encrypt() 
function. Probably the lib is ignoring the padding passed after you set a right 
one.


[2013-07-03 15:09:37] ly...@php.net

The PHP Version popup in report form was in a time warp... Corrected here.

OpenSSL version: 0.9.8b

Actual output:

PKCS1_OAEP fails:
string(0) ""

PKCS1 works:
string(172) 
"gVJcDQJnKJG7PX3+axZMyjph5xi3TFMLWXY2OLD4d62YYhlAmCUnr+WQP/F6//ykx3L/rXS7zfjXFPoyzn5v7dwysM107fS0tXwzngZ1fRjH5iU+1Dv4TJf4dXRZXzYKClDSSiQ0ZrmoGhVo5wx3PY61mEkBLNbS5IvZ75rCLSo="

PKCS1_OAEP works only AFTER PKCS1:
string(172) 
"gVJcDQJnKJG7PX3+axZMyjph5xi3TFMLWXY2OLD4d62YYhlAmCUnr+WQP/F6//ykx3L/rXS7zfjXFPoyzn5v7dwysM107fS0tXwzngZ1fRjH5iU+1Dv4TJf4dXRZXzYKClDSSiQ0ZrmoGhVo5wx3PY61mEkBLNbS5IvZ75rCLSo="


[2013-07-03 15:04:47] ly...@php.net

Description:

A call to openssl_private_encrypt(..., OPENSSL_PKCS1_OAEP_PADDING) fails
unless you call it AFTER openssl_private_encrypt(..., OPENSSL_PKCS1_PADDING)


Test script:
---
$private_key_text = file_get_contents('private.pem');

openssl_private_encrypt($decrypted_message, $encrypted_message, 
$private_key_text, OPENSSL_PKCS1_OAEP_PADDING);
echo "PKCS1_OAEP fails:\n";
var_dump(base64_encode($encrypted_message));
echo "\n";


openssl_private_encrypt($decrypted_message, $encrypted_message, 
$private_key_text, OPENSSL_PKCS1_PADDING);
echo "PKCS1 works:\n";
var_dump(base64_encode($encrypted_message));
echo "\n";


openssl_private_encrypt($decrypted_message, $encrypted_message, 
$private_key_text, OPENSSL_PKCS1_OAEP_PADDING);
echo "PKCS1_OAEP works only AFTER PKCS1:\n";
var_dump(base64_encode($encrypted_message));
echo "\n";



Expected result:

All three outputs the same.

Actual result:
--
First output is blank string.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65193&edit=1

Bug #65193 [Opn]: openssl_private_encrypt OAEP only works AFTER PKCS1

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65193&edit=1

 ID: 65193
 Updated by: fel...@php.net
 Reported by:ly...@php.net
 Summary:openssl_private_encrypt OAEP only works AFTER PKCS1
 Status: Open
 Type:   Bug
 Package:OpenSSL related
 Operating System:   CentOS 2.6.18
 PHP Version:5.4.11
 Block user comment: N
 Private report: N

 New Comment:

It looks an issue on openssl library.
According to 
http://openssl.6102.n7.nabble.com/Proplem-with-RSA-private-encrypt-and-OAEP-td45517.html
 RSA_PKCS1_OAEP_PADDING is not intended to be used with RSA_private_encrypt() 
function. Probably the lib is ignoring the padding passed after you set a right 
one.


Previous Comments:

[2013-07-03 15:09:37] ly...@php.net

The PHP Version popup in report form was in a time warp... Corrected here.

OpenSSL version: 0.9.8b

Actual output:

PKCS1_OAEP fails:
string(0) ""

PKCS1 works:
string(172) 
"gVJcDQJnKJG7PX3+axZMyjph5xi3TFMLWXY2OLD4d62YYhlAmCUnr+WQP/F6//ykx3L/rXS7zfjXFPoyzn5v7dwysM107fS0tXwzngZ1fRjH5iU+1Dv4TJf4dXRZXzYKClDSSiQ0ZrmoGhVo5wx3PY61mEkBLNbS5IvZ75rCLSo="

PKCS1_OAEP works only AFTER PKCS1:
string(172) 
"gVJcDQJnKJG7PX3+axZMyjph5xi3TFMLWXY2OLD4d62YYhlAmCUnr+WQP/F6//ykx3L/rXS7zfjXFPoyzn5v7dwysM107fS0tXwzngZ1fRjH5iU+1Dv4TJf4dXRZXzYKClDSSiQ0ZrmoGhVo5wx3PY61mEkBLNbS5IvZ75rCLSo="


[2013-07-03 15:04:47] ly...@php.net

Description:

A call to openssl_private_encrypt(..., OPENSSL_PKCS1_OAEP_PADDING) fails
unless you call it AFTER openssl_private_encrypt(..., OPENSSL_PKCS1_PADDING)


Test script:
---
$private_key_text = file_get_contents('private.pem');

openssl_private_encrypt($decrypted_message, $encrypted_message, 
$private_key_text, OPENSSL_PKCS1_OAEP_PADDING);
echo "PKCS1_OAEP fails:\n";
var_dump(base64_encode($encrypted_message));
echo "\n";


openssl_private_encrypt($decrypted_message, $encrypted_message, 
$private_key_text, OPENSSL_PKCS1_PADDING);
echo "PKCS1 works:\n";
var_dump(base64_encode($encrypted_message));
echo "\n";


openssl_private_encrypt($decrypted_message, $encrypted_message, 
$private_key_text, OPENSSL_PKCS1_OAEP_PADDING);
echo "PKCS1_OAEP works only AFTER PKCS1:\n";
var_dump(base64_encode($encrypted_message));
echo "\n";



Expected result:

All three outputs the same.

Actual result:
--
First output is blank string.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65193&edit=1

Bug #61257 [Opn->Fbk]: '--enable-fpm' makes gmake fail building in FreeBSD on a Sheevaplug

[felipe]

Edit report at https://bugs.php.net/bug.php?id=61257&edit=1

 ID: 61257
 Updated by: fel...@php.net
 Reported by:jensrasmus at gmail dot com
 Summary:'--enable-fpm' makes gmake fail building in FreeBSD
 on a Sheevaplug
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Compile Failure
 Operating System:   FreeBSD 8.2-STABLE armeb
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

  http://snaps.php.net/php5.4-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




Previous Comments:

[2012-03-13 21:28:19] jensrasmus at gmail dot com

Hej! Thank you schnorte! By editing sapi/fpm/fpm/fpm_atomic.h manually the make 
compilation process completed successfully. I hope this change will be added to 
the next minor version of php 5.3 (i.e. 5.3.11) and 5.4. 

Though I do not think the patch works normally by using `patch -p0 < patchfile' 
or `patch -C < patchfile'; but thats probably just me not being used to 
patching files ...


[2012-03-12 18:52:36] schnorte at gmail dot com

hej jensrasmus,

i figured out a working patch with help of some really nice guys in a 
freebsd/arm chatroom. see if it works for you!


[2012-03-12 00:14:06] schnorte at gmail dot com

i can confirm this for sheevaplug with freebsd 9.0 and PHP 5.3.10_1

it seems that the generic solution in sapi/fpm/fpm/fpm_atomic.h for __ARM__:

#define atomic_cmp_set(a,b,c) __sync_bool_compare_and_swap(a,b,c)

is not working in freebsd? can anyone provide instead of some atomic operations 
assembler code for the arm(v5) architecture?


[2012-03-02 23:57:38] jensrasmus at gmail dot com

Description:

I configured the php 5.4.0 source like this:

./configure --enable-fpm --enable-cgi --enable-fastcgi --prefix=/usr/local/php 

and then tried to compile with the gmake command. I expected it to complete 
compiling successfully so I could do a `gmake install'. What actually 
happened was a compile failure with this output at the end:

---ERROR MSG START---
In file included from /home/rasmus/php/php-
5.4.0/sapi/fpm/fpm/fpm_scoreboard.h:15,
 from /home/rasmus/php/php-5.4.0/sapi/fpm/fpm/fpm.c:21:
/home/rasmus/php/php-5.4.0/sapi/fpm/fpm/fpm_atomic.h:142:2: error: #error 
Unsupported processor. Please open a bug report (bugs.php.net).
In file included from /home/rasmus/php/php-
5.4.0/sapi/fpm/fpm/fpm_scoreboard.h:15,
 from /home/rasmus/php/php-5.4.0/sapi/fpm/fpm/fpm.c:21:
/home/rasmus/php/php-5.4.0/sapi/fpm/fpm/fpm_atomic.h:146: error: expected ')' 
before '*' token
In file included from /home/rasmus/php/php-5.4.0/sapi/fpm/fpm/fpm.c:21:
/home/rasmus/php/php-5.4.0/sapi/fpm/fpm/fpm_scoreboard.h:22: error: expected 
specifier-qualifier-list before 'atomic_t'
/home/rasmus/php/php-5.4.0/sapi/fpm/fpm/fpm_scoreboard.h:51: error: expected 
specifier-qualifier-list before 'atomic_t'
gmake: *** [sapi/fpm/fpm/fpm.lo] Error 1
---ERROR MSG END---

Also, this happened on FreeBSD/arm on a Marvell Sheevaplug. If I remove `--
enable-fpm' from the configure command, make completes successfully; so 
this may be a FPM related problem. This is my complete `uname -a':

FreeBSD frodo 8.2-STABLE FreeBSD 8.2-STABLE #7: Fri Feb 17 01:37:05 CET 2012
 
root@frodo:/usr/obj/usr/src/sys/FRODO  arm









-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61257&edit=1

Bug #64467 [Opn->Csd]: Segmentation fault after imap_reopen failure

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64467&edit=1

 ID: 64467
 Updated by: fel...@php.net
 Reported by:askalski at gmail dot com
 Summary:Segmentation fault after imap_reopen failure
-Status: Open
+Status: Closed
 Type:   Bug
 Package:IMAP related
 Operating System:   Ubuntu 12.04 LTS
 PHP Version:master-Git-2013-03-20 (Git)
 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=60dcc5851f0dd7cf387270d6ba243f9ac46bc396
Log: - Fixed bug #64467 (Segmentation fault after imap_reopen failure) patch 
by: askalski at gmail dot com


Previous Comments:

[2013-03-20 16:30:08] askalski at gmail dot com

Description:

Versions: 5.2, 5.3, 5.4, also confirmed on latest git master 
(78acb84b6e8fc07974283ce30c24596444d18cf7)

PHP will crash with a Segmentation Fault after imap_reopen() fails with the 
error message "imap_reopen(): Couldn't re-open stream ..."

When the UW-IMAP function 'mail_open' returns NIL after having been passed a 
valid MAILSTREAM pointer, this means UW-IMAP closed and freed the MAILSTREAM.  
However, PHP ignores this and returns FALSE without zeroing out 
imap_le_struct->imap_stream and calling zend_list_delete on the resource.

Because the resource was not freed, mail_close_it (the resource destructor) 
gets called on an invalid pointer during request shutdown.  If you're lucky, 
this crashes PHP with a Segmentation Fault.  (If you're unlucky, you've got a 
corrupt PHP interpreter handling new requests...)


Test script:
---



Expected result:

No crash.

Actual result:
--
$ /tmp/z/bin/php -v
PHP 5.6.0-dev (cli) (built: Mar 20 2013 12:13:31) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.6.0-dev, Copyright (c) 1998-2013 Zend Technologies


$ /tmp/z/bin/php imap-crash.php 
imap_open returned: resource(4) of type (imap)

Warning: imap_reopen(): Couldn't re-open stream in /tmp/imap-crash.php on line 
10
imap_reopen returned: bool(false)
Segmentation fault (core dumped)







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64467&edit=1

Bug #61868 [Opn->Asn]: ext\dom\tests\DOMDocument_validate_on_parse_variation.phpt fails

[felipe]

Edit report at https://bugs.php.net/bug.php?id=61868&edit=1

 ID: 61868
 Updated by: fel...@php.net
 Reported by:a...@php.net
 Summary:ext\dom\tests\DOMDocument_validate_on_parse_variation.phpt
 fails
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:DOM XML related
 Operating System:   windows
 PHP Version:5.3.11
-Assigned To:
+Assigned To:ab
 Block user comment: N
 Private report: N



Previous Comments:

[2012-04-27 16:43:06] a...@php.net

The following patch has been added/updated:

Patch Name: dom.diff
Revision:   1335544986
URL:
https://bugs.php.net/patch-display.php?bug=61868&patch=dom.diff&revision=1335544986


[2012-04-27 16:41:52] a...@php.net

Description:

Test diff:

001+ Warning: chdir(): No such file or directory (errno 2) in 
C:\snaps\php-test-pack-5.4-nts-windows-vc9-x86-rff7e1ff\ext\dom\tests\DOMDocument_validate_on_parse_variation.php
 on line 5
002+
003+ Warning: file_get_contents(note.xml): failed to open stream: No such file 
or directory in 
C:\snaps\php-test-pack-5.4-nts-windows-vc9-x86-rff7e1ff\ext\dom\tests\DOMDocument_validate_on_parse_variation.php
 on line 6
003- validateOnParse set to TRUE:
005+
006+ Warning: DOMDocument::loadXML(): Empty string supplied as input in 
C:\snaps\php-test-pack-5.4-nts-windows-vc9-x86-rff7e1ff\ext\dom\tests\DOMDocument_validate_on_parse_variation.php
 on line 13
005- Warning: DOMDocument::loadXML(): No declaration for element NYPHP in 
Entity, line: %d in %s on line %d
009+ Fatal error: Call to a member function appendChild() on a non-object in 
C:\snaps\php-test-pack-5.4-nts-windows-vc9-x86-rff7e1ff\ext\dom\tests\DOMDocument_validate_on_parse_variation.php
 on line 18
006-
007- Warning: DOMDocument::loadXML(): Element from was declared #PCDATA but 
contains non text nodes in Entity, line: %d in %s on line %d
008- Error Report Above

The test tries to chdir(__DIR__ . "/../examples") and some files in there, but 
that's not present in the test pack.

Expected result:

test pass

Actual result:
--
test fail






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61868&edit=1

Bug #61683 [Opn->Asn]: tests\basic\bug20539.phpt fails

[felipe]

Edit report at https://bugs.php.net/bug.php?id=61683&edit=1

 ID: 61683
 Updated by: fel...@php.net
 Reported by:a...@php.net
 Summary:tests\basic\bug20539.phpt fails
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:Session related
 Operating System:   all
 PHP Version:Irrelevant
-Assigned To:
+Assigned To:ab
 Block user comment: N
 Private report: N



Previous Comments:

[2012-04-11 15:18:29] a...@php.net

The following patch has been added/updated:

Patch Name: 61683.diff
Revision:   1334157509
URL:
https://bugs.php.net/patch-display.php?bug=61683&patch=61683.diff&revision=1334157509


[2012-04-09 16:55:29] a...@php.net

Description:

Test diff:

002+
002- bool(true)
003+ Warning: 
unlink(C:\php-sdk\php53\vc9\x86\php-src\tests\basic/sess_6dbcfb558bef9ad0fb3e73d179396858):
 Permission denied in C:\php-sdk\php53\vc9\x86\php-src\tests\basic\bug20539.php 
on line 4
004+ bool(false)

Expected result:

test pass

Actual result:
--
test fail






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61683&edit=1

Bug #64642 [Asn->Csd]: fpm_sockets.c struct tcp_info has no member tcpi_sacked or tcpi_unsacked

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64642&edit=1

 ID: 64642
 Updated by: fel...@php.net
 Reported by:mario at xenji dot com
 Summary:fpm_sockets.c struct tcp_info has no member
 tcpi_sacked or tcpi_unsacked
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   FreeBSD 9.1-RELEASE
 PHP Version:5.5.0beta3
-Assigned To:fat
+Assigned To:felipe
 Block user comment: N
 Private report: N

 New Comment:

The bug has been fixed on bug #63983, thanks.


Previous Comments:

[2013-04-23 03:21:20] larue...@php.net

yeah, seems FreeBSD has their own definition of the tcp_info names:
http://www.leidinger.net/FreeBSD/dox/netinet/html/d8/da5/tcp_8h_source.html


[2013-04-16 14:16:59] mario at xenji dot com

I found this one: http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2011-
November/222806.html

Seems like it is "just" a naming thing.


[2013-04-13 14:55:08] mario at xenji dot com

I've added a list of installed ports to the gist, maybe it's a library issue...


[2013-04-13 09:55:35] mario at xenji dot com

Description:

The configure call: 

env COPTFLAGS="-O2 -pipe -funroll-loops -ffast-math -fno-strict-aliasing" 
CC=clang CXX=clang++ CPP=clang-cpp CFLAGS="-O2 -pipe -fno-strict-aliasing" 
./configure --enable-fpm --with-fpm-user=www --with-fpm-group=www --disable-cgi 
--with-config-file-path=/usr/local/etc --with-config-file-scan-
dir=/usr/local/etc/php.d --with-openssl --with-zlib --enable-bcmath --enable-
calendar --with-curl --with-curlwrappers --enable-exif --enable-ftp --with-gd --
with-t1lib --enable-gd-native-ttf --with-mhash --enable-intl --enable-mbstring -
-with-mcrypt --with-mysqli --enable-pcntl --with-pdo-mysql --enable-soap --
enable-sockets --enable-sysvmsg --enable-sysvsem --enable-sysvshm --with-xsl --
enable-zip --enable-mysqlnd --with-pear

I've created a gist with more information https://gist.github.com/xenji/5377738

The gist has infos about:
- clang configure output
- the clang excerpt of the error
- a gcc version of the build attempt

I've attached the clang output in the backtrace field, too.

Please feel free to contact me for more information. As this server is not 
business critical, I could provide limited ssh access for further debugging.




Actual result:
--
/bin/sh /root/builds/php/php-5.5.0beta3/libtool --silent --preserve-dup-deps --
mode=compile clang -I/root/builds/php/php-5.5.0beta3/sapi/fpm -Isapi/fpm/ -
I/root/builds/php/php-5.5.0beta3/sapi/fpm/ -DPHP_ATOM_INC -
I/root/builds/php/php-5.5.0beta3/include -I/root/builds/php/php-5.5.0beta3/main 
-I/root/builds/php/php-5.5.0beta3 
-I/root/builds/php/php-5.5.0beta3/ext/date/lib 
-I/root/builds/php/php-5.5.0beta3/ext/ereg/regex -I/usr/local/include/libxml2 -
I/usr/local/include -I/root/builds/php/php-5.5.0beta3/ext/mbstring/oniguruma -
I/root/builds/php/php-5.5.0beta3/ext/mbstring/libmbfl -I/root/builds/php/php-
5.5.0beta3/ext/mbstring/libmbfl/mbfl -I/root/builds/php/php-
5.5.0beta3/ext/sqlite3/libsqlite -I/root/builds/php/php-5.5.0beta3/TSRM -
I/root/builds/php/php-5.5.0beta3/Zend-I/usr/local/include -O2 -pipe -fno-
strict-aliasing  -c /root/builds/php/php-5.5.0beta3/sapi/fpm/fpm/fpm_status.c 
-o 
sapi/fpm/fpm/fpm_status.lo
/bin/sh /root/builds/php/php-5.5.0beta3/libtool --silent --preserve-dup-deps --
mode=compile clang -I/root/builds/php/php-5.5.0beta3/sapi/fpm -Isapi/fpm/ -
I/root/builds/php/php-5.5.0beta3/sapi/fpm/ -DPHP_ATOM_INC -
I/root/builds/php/php-5.5.0beta3/include -I/root/builds/php/php-5.5.0beta3/main 
-I/root/builds/php/php-5.5.0beta3 
-I/root/builds/php/php-5.5.0beta3/ext/date/lib 
-I/root/builds/php/php-5.5.0beta3/ext/ereg/regex -I/usr/local/include/libxml2 -
I/usr/local/include -I/root/builds/php/php-5.5.0beta3/ext/mbstring/oniguruma -
I/root/builds/php/php-5.5.0beta3/ext/mbstring/libmbfl -I/root/builds/php/php-
5.5.0beta3/ext/mbstring/libmbfl/mbfl -I/root/builds/php/php-
5.5.0beta3/ext/sqlite3/libsqlite -I/root/builds/php/php-5.5.0beta3/TSRM -
I/root/builds/php/php-5.5.0beta3/Zend-I/usr/local/include -O2 -pipe -fno-
strict-aliasing  -c /root/builds/php/php-5.5.0beta3/sapi/fpm/fpm/fpm_stdio.c -o 
sapi/fpm/fpm/fpm_stdio.lo
/root/builds/php/php-5.5.0beta3/sapi/fpm/fpm/fpm_sockets.c:404:11: error: no 
member named 'tcpi_sacked' in 'struct tcp_info'; did you mean '__tcpi_sacked'?
if (info.tcpi_sacked == 0) {
 ^~~
 __tcpi_sacked
/usr/include/netinet/tcp

Bug #63983 [Opn->Csd]: enabling FPM borks compile

[felipe]

Edit report at https://bugs.php.net/bug.php?id=63983&edit=1

 ID: 63983
 Updated by: fel...@php.net
 Reported by:jhein_98 at swbell dot net
 Summary:enabling FPM borks compile
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   FreeBSD 9.1
 PHP Version:5.4.10
 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=cd176e045219373a10f32ed412092992cdbcc5b6
Log: - Fixed bug #63983 (enabling FPM borks compile on FreeBSD) patch by: 
chibisuke at web dot de


Previous Comments:

[2013-03-08 07:33:16] chibisuke at web dot de

I attached the patchfile we're using to fix this when we install a new server.

I did however NOT test this on any other OS than FreeBSD. So please be cautious 
when applying it to SVN.


[2013-03-08 07:29:18] chibisuke at web dot de

There's also a PR for FreeBSD on this one
http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2011-November/222806.html

And the php-bug that was there back then disappeared for some reason. At lest I 
can't find it anymore. 

but we got used to fixing this on each server we install over and over again, 
so..


[2013-02-21 23:40:11] phpfpm1 at gmail dot com

Any new on this? It's still not fixed. Patch submitted works fine.


[2013-01-14 05:39:01] jhein_98 at swbell dot net

After doing some research, I think I may have found a fix.  I'm testing it now

Fix:
just replace in file fpm_sockets.c :
1)info.tcpi_sacked => info.__tcpi_sacked
2)info.tcpi_unacked => info.__tcpi_unacked

Hopefully this works and helps someone else.


[2013-01-14 04:53:03] jhein_98 at swbell dot net

Description:

Running the configure script with --enable-fpm causes make to fail with the 
following errors:

/usr/local/src/php-5.4.10/sapi/fpm/fpm/fpm_sockets.c -o 
sapi/fpm/fpm/fpm_sockets.lo
/usr/local/src/php-5.4.10/sapi/fpm/fpm/fpm_sockets.c: In function 
'fpm_socket_get_listening_queue':
/usr/local/src/php-5.4.10/sapi/fpm/fpm/fpm_sockets.c:404: error: 'struct 
tcp_info' has no member named 'tcpi_sacked'
/usr/local/src/php-5.4.10/sapi/fpm/fpm/fpm_sockets.c:409: error: 'struct 
tcp_info' has no member named 'tcpi_unacked'
/usr/local/src/php-5.4.10/sapi/fpm/fpm/fpm_sockets.c:413: error: 'struct 
tcp_info' has no member named 'tcpi_sacked'
*** [sapi/fpm/fpm/fpm_sockets.lo] Error code 1

Stop in /usr/local/src/php-5.4.10.


The specific options I passed to the configure script was:
./configure --prefix=/usr/local/software/php --mandir=/usr/local/man  
--enable-cgi --enable-fpm --with-mysql=/usr/local/software/mysql  
--with-openssl-dir=/usr/local/software/openssl








-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63983&edit=1

Bug #63409 [Opn->Csd]: php-dba function test fails on big-endian machine

[felipe]

Edit report at https://bugs.php.net/bug.php?id=63409&edit=1

 ID: 63409
 Updated by: fel...@php.net
 Reported by:tianhonglouis at gmail dot com
 Summary:php-dba function test fails on big-endian machine
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Testing related
 Operating System:   linux
 PHP Version:5.4.8
 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=7e33b5d2fa89a6bf167fc4061dcf6aedab1cc6b8
Log: - Fixed bug #63409 (php-dba function test fails on big-endian machine) 
patch by: tianhonglouis at gmail dot com


Previous Comments:

[2012-11-01 09:06:17] tianhonglouis at gmail dot com

Description:

For ext/dba/tests/bug38698.phpt, if running the testcase on big-endian machine 
like ppc, it will fail. The main root cause is the function pack('i', 129), if 
add the format character "i", it's machine dependent size and byte order. Big 
endian and liitle endian will output the different string value. According to 
the 
string value, dba_insert() will insert the different position of the db, 
finally 
cause the different md5 value. 

Test script:
---
php run-tests.php ext/dba/tests/bug38698.phpt

Expected result:

Running selected tests.
PASS Bug #38698 (Bug #38698 for some keys cdbmake creates corrupted db and cdb 
can't read valid db) [ext/dba/tests/bug38698.phpt] 
=
Number of tests :1 1
Tests skipped   :0 (  0.0%) 
Tests warned:0 (  0.0%) (  0.0%)
Tests failed:0 (  0.0%) (  0.0%)
Expected fail   :0 (  0.0%) (  0.0%)
Tests passed:1 (100.0%) (100.0%)
-
Time taken  :0 seconds

Actual result:
--
Running selected tests.
FAIL Bug #38698 (Bug #38698 for some keys cdbmake creates corrupted db and cdb 
can't read valid db) [ext/dba/tests/bug38698.phpt] 
=
Number of tests :1 1
Tests skipped   :0 (  0.0%) 
Tests warned:0 (  0.0%) (  0.0%)
Tests failed:1 (100.0%) (100.0%)
Expected fail   :0 (  0.0%) (  0.0%)
Tests passed:0 (  0.0%) (  0.0%)
-
Time taken  :0 seconds
=

=
FAILED TEST SUMMARY
-
Bug #38698 (Bug #38698 for some keys cdbmake creates corrupted db and cdb can't 
read valid db) [ext/dba/tests/bug38698.phpt]







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63409&edit=1

Bug #64355 [Opn->Nab]: Segfault when accepting ssl connection

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64355&edit=1

 ID: 64355
 Updated by: fel...@php.net
 Reported by:nicolyon at free dot fr
 Summary:Segfault when accepting ssl connection
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:OpenSSL related
 Operating System:   Linux
 PHP Version:5.4.12
 Block user comment: N
 Private report: N

 New Comment:

Thanks for the info. So not a bug on PHP, but on OpenSSL library.


Previous Comments:

[2013-06-26 13:55:38] ntdm at hotmail dot com

OpenSSL bug #703031? http://openssl.6102.n7.nabble.com/NULL-ptr-deref-when-
calling-SSL-get-certificate-with-1-0-0k-td43636.html


[2013-05-09 08:32:09] simone at edinet dot info

Same problem happens with 
PHP 5.4.14
OpenSSL 1.0.1e


GDB bt:
#0  0x7f8493d2300a in ssl_set_cert_masks () from 
/usr/local/ssl/lib/libssl.so.1.0.0
#1  0x7f8493d23886 in ssl_get_server_send_pkey () from 
/usr/local/ssl/lib/libssl.so.1.0.0
#2  0x7f8493d23979 in ssl_get_server_send_cert () from 
/usr/local/ssl/lib/libssl.so.1.0.0
#3  0x0047880b in php_SSL_new_from_context (ctx=0x1504f80, 
stream=stream@entry=0x7f8495ef7c98) at 
/usr/local/sorgenti/src/php-5.4.14/ext/openssl/openssl.c:4574
#4  0x00479e2c in php_openssl_setup_crypto (sslsock=0x7f8495ef7c20, 
stream=0x7f8495ef7c98, cparam=) at 
/usr/local/sorgenti/src/php-5.4.14/ext/openssl/xp_ssl.c:410
#5  php_openssl_sockop_set_option (stream=0x7f8495ef7c98, option=, value=, ptrparam=0x7fff88da47b0) at 
/usr/local/sorgenti/src/php-5.4.14/ext/openssl/xp_ssl.c:755
#6  0x0071fe4c in _php_stream_set_option 
(stream=stream@entry=0x7f8495ef7c98, option=option@entry=8, 
value=value@entry=0, ptrparam=ptrparam@entry=0x7fff88da47b0)
at /usr/local/sorgenti/src/php-5.4.14/main/streams/streams.c:1358
#7  0x0072a487 in php_stream_xport_crypto_setup 
(stream=stream@entry=0x7f8495ef7c98, crypto_method=, 
session_stream=)
at /usr/local/sorgenti/src/php-5.4.14/main/streams/transports.c:364
#8  0x006cdea7 in zif_stream_socket_enable_crypto (ht=, 
return_value=0x7f8495ef9b00, return_value_ptr=, 
this_ptr=, return_value_used=)
at /usr/local/sorgenti/src/php-5.4.14/ext/standard/streamsfuncs.c:1506
#9  0x00808af0 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7f8495ec4288) at 
/usr/local/sorgenti/src/php-5.4.14/Zend/zend_vm_execute.h:643
#10 0x007c45ec in execute (op_array=0x1504e30) at 
/usr/local/sorgenti/src/php-5.4.14/Zend/zend_vm_execute.h:410
#11 0x00767790 in zend_execute_scripts (type=type@entry=8, 
retval=retval@entry=0x0, file_count=file_count@entry=3) at 
/usr/local/sorgenti/src/php-5.4.14/Zend/zend.c:1315
#12 0x00709d99 in php_execute_script 
(primary_file=primary_file@entry=0x7fff88da6db0) at 
/usr/local/sorgenti/src/php-5.4.14/main/main.c:2492
#13 0x0080b111 in do_cli (argc=60, argv=0x7fff88da8218) at 
/usr/local/sorgenti/src/php-5.4.14/sapi/cli/php_cli.c:988
#14 0x004382f5 in main (argc=60, argv=0x7fff88da8218) at 
/usr/local/sorgenti/src/php-5.4.14/sapi/cli/php_cli.c:1364

Test script:
---
FTP login (SSL) [ext/ftp/tests/002.phpt]

Expected result:

no crash

Actual result:
--
segfault


[2013-03-05 07:55:18] nicolyon at free dot fr

Description:

When accepting a connection from a SSL socket with openssl >= 1.0.1d PHP crash.
When using openssl 1.0.1c or lower there's no crash.

Here the stack :
#0  0x7f2f58eafd1a in ssl_set_cert_masks () from /usr/lib/libssl.so.1.0.0
#1  0x7f2f58eb0596 in ssl_get_server_send_pkey () from 
/usr/lib/libssl.so.1.0.0
#2  0x7f2f58eb0689 in ssl_get_server_send_cert () from 
/usr/lib/libssl.so.1.0.0
#3  0x7f2f4c84bf23 in php_SSL_new_from_context () from 
/usr/lib/php/extensions/openssl.so
#4  0x7f2f4c84d5b9 in php_openssl_sockop_set_option () from 
/usr/lib/php/extensions/openssl.so
#5  0x006247cc in _php_stream_set_option ()
#6  0x0062fe9e in php_stream_xport_crypto_setup ()
#7  0x7f2f4c84d294 in php_openssl_sockop_set_option () from 
/usr/lib/php/extensions/openssl.so
#8  0x006247cc in _php_stream_set_option ()
#9  0x0062fcb9 in php_stream_xport_accept ()
#10 0x005c9e9c in zif_stream_socket_accept ()


Test script:
---
$context = stream_context_create();
$errno = 0;
$errstr = "";
$s = stream_socket_server( "ssl://127.0.0.1:800", $errno, $errstr, 
STREAM_SERVER_BIND | STREAM_SERVER_LISTEN, $context );



do just telnet localhost 800 for crash 

Expected result:

no crash

Actual result:
--
segfault






-- 
Edit this bug 

Bug #65128 [Opn->Fbk]: undefined reference to `curl_easy_(un)escape'

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65128&edit=1

 ID: 65128
 Updated by: fel...@php.net
 Reported by:a178235 at yahoo dot com
 Summary:undefined reference to `curl_easy_(un)escape'
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:cURL related
 Operating System:   Linux 2.6.18-348.6.1.el5PAE
 PHP Version:5.5.0
 Block user comment: N
 Private report: N

 New Comment:

Hmm, it seems there's some messy about different version on build.

Check out the libcurl version on config.log.(`cat config.log | grep -i libcurl`)


Previous Comments:

[2013-06-26 00:43:00] a178235 at yahoo dot com

/usr/include/curl/curlver.h

#define LIBCURL_VERSION "7.15.5"


[2013-06-26 00:39:46] a178235 at yahoo dot com

-bash-3.2$  curl-config --version
libcurl 7.15.0


[2013-06-25 23:57:39] fel...@php.net

What's the libcurl version are you using?


[2013-06-25 23:52:47] a178235 at yahoo dot com

Description:

ext/curl/.libs/interface.o: In function `zif_curl_unescape':
/ip/iuecon/_Install/PHP/php-5.5.0/ext/curl/interface.c:3485: undefined 
reference to `curl_easy_unescape'
ext/curl/.libs/interface.o: In function `zif_curl_escape':
/ip/iuecon/_Install/PHP/php-5.5.0/ext/curl/interface.c:3461: undefined 
reference to `curl_easy_escape'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

Test script:
---
tar -xf php-5.5.0.tar.gz
cd php-5.5.0/
./configure --prefix=$HOME --with-curl
make








-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65128&edit=1

Bug #62475 [Opn->Csd]: variant_* functions causes crash when null given as an argument

[felipe]

Edit report at https://bugs.php.net/bug.php?id=62475&edit=1

 ID: 62475
 Updated by: fel...@php.net
 Reported by:deadb17ch at gmail dot com
 Summary:variant_* functions causes crash when null given as
 an argument
-Status: Open
+Status: Closed
 Type:   Bug
 Package:COM related
 Operating System:   Windows XP SP3
 PHP Version:5.4.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=42896968282a607a26e4aa152d3c8dc90dad5826
Log: - Fixed bug #62475 (variant_* functions causes crash when null given as an 
argument)


Previous Comments:

[2013-02-20 11:42:13] user at kkdf2 dot sakura dot ne dot jp

z is NULL, and then Z_TYPE_P(z) gets access violation, because 
zend_parse_parameters eats "z!z!". It may be safe with "zz".

---
PHP_COM_DOTNET_API void php_com_variant_from_zval(VARIANT *v, zval *z, int 
codepage TSRMLS_DC)
{
OLECHAR *olestring;
php_com_dotnet_object *obj;

switch (Z_TYPE_P(z)) {
case IS_NULL:
V_VT(v) = VT_NULL;
break;
---


[2012-07-03 20:56:12] deadb17ch at gmail dot com

Description:

As we can read in the php manual : 

"As with all the variant arithmetic functions, the parameters for this function 
can be either a PHP native type (integer, string, floating point, boolean or 
NULL), or an instance of a COM, VARIANT or DOTNET class. "

but actuall php instance crashes when we give NULL as first or second argument 
to some of the functions from variant_* familly.

Thoes functions are: 

variant_neg
variant_pow
variant_cat
variant_div
variant_fix
variant_idiv
variant_imp
variant_int
variant_mod
variant_mul
variant_neg
variant_not
variant_rount
variant_set
variant_sub
variant_xor
variant_or 
variant_eqv 
variant_cmp 
variant_abs 
variant_and

Test script:
---





Expected result:

nothing happens or an error occurs

Actual result:
--
crash

eax= ebx=01250080 ecx=00c0fac8 edx=1039bac6 esi= edi=00c0fac8
eip=100f4036 esp=00c0fa90 ebp=02296f08 iopl=0 nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs= efl=00200246
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for 
C:\\xampp\\php\\php5ts.dll - 
php5ts!php_com_variant_from_zval+0x6:
100f4036 0fb6460cmovzx   eax,byte ptr [esi+0Ch] ds:0023:000c=??






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62475&edit=1

Bug #61547 [Opn->Fbk]: session.progress

[felipe]

Edit report at https://bugs.php.net/bug.php?id=61547&edit=1

 ID: 61547
 Updated by: fel...@php.net
 Reported by:info at sperlingprog dot com
 Summary:session.progress
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Session related
 Operating System:   Windows
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

Have you figured what was going wrong there?


Previous Comments:

[2012-03-28 19:30:08] info at sperlingprog dot com

Description:

---
>From manual page: http://www.php.net/session.upload-progress
---

there are no session data for upload infos in the session on windows

i have test is on 3 windows systems

all php.ini settings are ok.

upload ok session progress is empty.

$_SESSION = empty!!

Greetings steffen

Test script:
---
session_start();

$key = ini_get("session.upload_progress.prefix") . "myForm";
if (!empty($_SESSION[$key])) 
  {
  $current = $_SESSION[$key]["bytes_processed"];
  $total = $_SESSION[$key]["content_length"];
  echo $current < $total ? ceil($current / $total * 100) : 100;
  }
else 
  {
  echo " PHP_VERSION: " . PHP_VERSION ."  " . date("H:m:s") . "key: 
$key";
  var_dump($_SESSION);
  
  }







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61547&edit=1

Bug #62672 [Opn->Csd]: Error on serialize of ArrayObject

[felipe]

Edit report at https://bugs.php.net/bug.php?id=62672&edit=1

 ID: 62672
 Updated by: fel...@php.net
 Reported by:t dot weber at interexa dot de
 Summary:Error on serialize of ArrayObject
-Status: Open
+Status: Closed
 Type:   Bug
 Package:SPL related
 Operating System:   Cent OS
 PHP Version:5.3.15
 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=04db57066deb73ef9c960a2c5bebad49195bc1bb
Log: - Fixed bug #62672 (Error on serialize of ArrayObject) patch by: lior dot 
k at zend dot com


Previous Comments:

[2012-11-25 11:16:18] lior dot k at zend dot com

ping ?


[2012-08-05 12:56:09] lior dot k at zend dot com

Please see the attached patch by Yoram Bar-Haim 


[2012-07-27 16:08:41] j dot henge-ernst at interexa dot de

The problem is that the unserialize of ArrayIterator (and also maybe 
ArrayObject or other SPL classes) can not dereference object references.

A simpler Testcase:
getIterator());
$s = serialize($t);
$e = unserialize($s);

Fatal error: Uncaught exception 'UnexpectedValueException' with message 'Error 
at offset 13 of 26 bytes' in /tmp/test2.php:5
Stack trace:
#0 [internal function]: ArrayIterator->unserialize('x:i:16777216;r:...')
#1 /tmp/test2.php(5): unserialize('a:2:{i:0;C:11:"...')
#2 {main}
  thrown in /tmp/test2.php on line 5

If the order in the array is reversed it works, as now the ArrayObject is only 
a reference in the array.

Same behaviour with PHP 5.4.5


[2012-07-27 11:04:48] t dot weber at interexa dot de

Description:

Serialize and direct unserialize of Objects does not work if return value of 
ArrayObject::getIterator is contained in parent class (see Test script)

Test script:
---
class ObjA
{
private $_varA;

public function __construct(Iterator $source)
{
$this->_varA = $source;
}
}

class ObjB extends ObjA
{
private $_varB;

public function __construct(ArrayObject $keys)
{
$this->_varB = $keys;
parent::__construct($keys->getIterator());
}
}

$obj = new ObjB(new ArrayObject());

unserialize(serialize($obj));







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62672&edit=1

Bug #65128 [Opn->Fbk]: undefined reference to `curl_easy_(un)escape'

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65128&edit=1

 ID: 65128
 Updated by: fel...@php.net
 Reported by:a178235 at yahoo dot com
 Summary:undefined reference to `curl_easy_(un)escape'
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:cURL related
 Operating System:   Linux 2.6.18-348.6.1.el5PAE
 PHP Version:5.5.0
 Block user comment: N
 Private report: N

 New Comment:

What's the libcurl version are you using?


Previous Comments:

[2013-06-25 23:52:47] a178235 at yahoo dot com

Description:

ext/curl/.libs/interface.o: In function `zif_curl_unescape':
/ip/iuecon/_Install/PHP/php-5.5.0/ext/curl/interface.c:3485: undefined 
reference to `curl_easy_unescape'
ext/curl/.libs/interface.o: In function `zif_curl_escape':
/ip/iuecon/_Install/PHP/php-5.5.0/ext/curl/interface.c:3461: undefined 
reference to `curl_easy_escape'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

Test script:
---
tar -xf php-5.5.0.tar.gz
cd php-5.5.0/
./configure --prefix=$HOME --with-curl
make








-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65128&edit=1

Bug #62964 [Opn->Csd]: Cross-Site Scripting

[felipe]

Edit report at https://bugs.php.net/bug.php?id=62964&edit=1

 ID: 62964
 Updated by: fel...@php.net
 Reported by:ymaryshev at ptsecurity dot ru
 Summary:Cross-Site Scripting
-Status: Open
+Status: Closed
 Type:   Bug
 Package:*General Issues
 Operating System:   win
 PHP Version:5.4.6
 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=41b73e4cee9ce68b8b78a00eddd4322b0d48dd06
Log: - Fixed bug #62964 (Possible XSS on "Registered stream filters" 
info) patch by: david at nnucomputerwhiz dot com


Previous Comments:

[2012-09-14 05:59:28] david at nnucomputerwhiz dot com

Added patch. It's a really simple change to use php_info_print_html_esc when 
appropriate. We do the same thing with other functions like 
php_print_gpcse_array()


[2012-09-14 05:35:31] david at nnucomputerwhiz dot com

I can't imagine this bug ever causing any real security problems but whenever 
outputting anything to the browser that could contain html entities they should 
be encoded. So php_info_print should probably be modified to use htmlentities 
so 
if it ever tried to print a '&' or '<' to the browser it will be displayed 
properly.


[2012-09-01 17:18:40] zyss at mail dot zp dot ua

Unfortunately most of PHP output functions are vulnerable in the same way...

For example, built-in echo function:

$a = "alert('Positive')";
echo $a; // echo IS VULNERABLE!!!11oneoneeleven

Seriously, healthy programmer never allows untrusted data (user input) to be 
passed to stream_filter_register() as well as to other functions.

Moreover, phpinfo() should never be exposed.


[2012-08-29 12:06:08] ymaryshev at ptsecurity dot ru

Description:

An attacker can conduct cross-site scripting attack because of incorrect 
implementation of php_info_print_stream_hash function in phpinfo in PHP.

Vulnerability exists in /ext/sqlite3/ info.c file. Here is the vulnerable code:
static void php_info_print_stream_hash(const char *name, HashTable *ht 
TSRMLS_DC) 
/* {{{ */ {
...
while (zend_hash_get_current_key_ex(ht, &key, &len, 
NULL, 
0, &pos) == HASH_KEY_IS_STRING)
{
php_info_print(key);
...

Test script:
---
alert('Positive')","a");
phpinfo();
?>







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62964&edit=1

Bug #62345 [Opn->Csd]: Misspelling of Occurred

[felipe]

Edit report at https://bugs.php.net/bug.php?id=62345&edit=1

 ID: 62345
 Updated by: fel...@php.net
 Reported by:marc at easen dot co dot uk
 Summary:Misspelling of Occurred
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   All
 PHP Version:Irrelevant
-Assigned To:
+Assigned To:felipe
 Block user comment: N
 Private report: N

 New Comment:

Such typos has been already fixed. Thanks.


Previous Comments:

[2012-06-17 19:26:55] marc at easen dot co dot uk

Description:

There are quite a few occurrences where the word 'occurred' is spelt incorrect

https://github.com/php/php-src/pull/104/files







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62345&edit=1

Bug #60803 [Opn->Fbk]: pdo-oci configuring bug

[felipe]

Edit report at https://bugs.php.net/bug.php?id=60803&edit=1

 ID: 60803
 Updated by: fel...@php.net
 Reported by:gureedo at gmail dot com
 Summary:pdo-oci configuring bug
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:PDO related
 Operating System:   linux x86-64
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

Still you facing such a problem?


Previous Comments:

[2012-01-19 12:00:43] gureedo at gmail dot com

Description:

This bug is regression from this bug solution:
https://bugs.php.net/bug.php?id=44989
And same bug on gentoo site:
https://bugs.gentoo.org/show_bug.cgi?id=380581

I've attached patch that searches for instant client in both oracle and orace64 
dirs.









-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60803&edit=1

Bug #60732 [Opn->Csd]: php_error_docref links to invalid pages

[felipe]

Edit report at https://bugs.php.net/bug.php?id=60732&edit=1

 ID: 60732
 Updated by: fel...@php.net
 Reported by:vr...@php.net
 Summary:php_error_docref links to invalid pages
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Irrelevant
 PHP Version:5.4SVN-2012-01-12 (SVN)
 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=6ba93a4bae355ac1d247d1e474381bb92d1eb038
Log: - Fixed bug #60732 (php_error_docref links to invalid pages) patch by: 
Jakub Vrana


Previous Comments:

[2012-01-12 17:22:43] vr...@php.net

The following patch has been added/updated:

Patch Name: php_error_docref-strip-leading-dashes
Revision:   1326388963
URL:
https://bugs.php.net/patch-display.php?bug=60732&patch=php_error_docref-strip-leading-dashes&revision=1326388963


[2012-01-12 17:18:05] vr...@php.net

Description:

Links to PHP Manual generated in case of an error are wrong if the function or 
method begins by __.

Test script:
---
try {
new DateTimeZone("x");
} catch (Exception $e) {
echo $e->getMessage();
}


Expected result:

DateTimeZone::__construct() [datetimezone.construct.php]: Unknown or bad 
timezone (x)

Actual result:
--
DateTimeZone::__construct() [datetimezone.--construct.php]: Unknown or bad 
timezone (x)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60732&edit=1

Bug #54428 [Opn->Fbk]: [function.imagecreatefromjpeg]: failed to open stream: HTTP request failed!

[felipe]

Edit report at https://bugs.php.net/bug.php?id=54428&edit=1

 ID: 54428
 Updated by: fel...@php.net
 Reported by:hoangvu4000 at gmail dot com
 Summary:[function.imagecreatefromjpeg]: failed to open
 stream: HTTP request failed!
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:GD related
 Operating System:   Windows 7
 PHP Version:5.2.17
 Block user comment: N
 Private report: N

 New Comment:

What if you supply an url encoded one?


Previous Comments:

[2011-03-31 04:29:30] hoangvu4000 at gmail dot com

Description:

---
>From manual page: http://www.php.net/function.imagecreatefromjpeg#Description
---


Warning: imagecreatefromjpeg(http://truyentranhtuan.com/IMAGES/SITE 
IMAGES/Kimi_ni_Todoke.jpg) [function.imagecreatefromjpeg]: failed to open 
stream: HTTP request failed! HTTP/1.1 404 Not Found in 
/home/thegioitru/domains/thegioitruyentranh.vn/public_html/z/facebook.php on 
line 39

Every things are OK if the URL don't have any space,
Ext: imagecreatefromjpeg(http://acb.com/PhotoImages.jpg) ==> OK
But: imagecreatefromjpeg(http://acb.com/Photo Images.jpg) ==> "failed to open 
stream: HTTP request failed!" (have one space in "Photo" & "Images")

we get images form orther host, so we can rename the suorce images, How we can 
get it with imagecreatefromjpeg. if this is Bug, please fix it. Thank!

Test script:
---
//return: OK
//$up_file = 
"http://truyentranhtuan.com/IMAGES/MANGA/Kimi_ni_Todoke/034/01.JPG";;

// return: "failed to open stream: HTTP request failed!" 
$up_file = "http://truyentranhtuan.com/IMAGES/SITE IMAGES/Kimi_ni_Todoke.jpg";

$new_image=imagecreatefromjpeg($up_file);

Expected result:

Warning: imagecreatefromjpeg(http://truyentranhtuan.com/IMAGES/SITE 
IMAGES/Kimi_ni_Todoke.jpg) [function.imagecreatefromjpeg]: failed to open 
stream: HTTP request failed! HTTP/1.1 404 Not Found in 
/home/thegioitru/domains/thegioitruyentranh.vn/public_html/z/facebook.php on 
line 39







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=54428&edit=1

Bug #53442 [Opn]: [fix provided] configure --with-iconv=DIR fails due to two faulty tests

[felipe]

Edit report at https://bugs.php.net/bug.php?id=53442&edit=1

 ID: 53442
 Updated by: fel...@php.net
 Reported by:fransmeulenbroeks at gmail dot com
 Summary:[fix provided] configure --with-iconv=DIR fails due
 to two faulty tests
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   linux
 PHP Version:5.2SVN-2010-12-01 (snap)
 Block user comment: N
 Private report: N

 New Comment:

There is a check right after what you have quoted which handles the supplied 
path.

...
  dnl
  dnl Check external libs for iconv funcs
  dnl
  if test "$found_iconv" = "no"; then

for i in $PHP_ICONV /usr/local /usr; do
...


Previous Comments:

[2010-12-01 23:10:25] fransmeulenbroeks at gmail dot com

oh and the subject line is wrong this reports and fixes only one faulty test, 
the other one is reported and fixed in 53443


[2010-12-01 23:09:00] fransmeulenbroeks at gmail dot com

oops, made typo in patch
This line:
+  if test "$PHP_ICONV" != no"; then
is missing a " and must read
+  if test "$PHP_ICONV" != "no"; then

Uploaded a new patch.
Sorry for any inconvenience!


[2010-12-01 22:50:49] fransmeulenbroeks at gmail dot com

Description:

when trying to cross-compile configure picked up the host iconv, not the target 
one, resulting in wrong paths later on and configure failing.

configure was called with configure --with-iconv=DIR (where DIR is the dir to 
find the iconv stuff).

This fails at two places. First one is due to a faulty test in acinclude.m4
It tests PHP_ICONV against "yes". However PHP_ICONV in my case contains the 
path so we should test against not "no"
(PHP_ICONV can be a dir because otherwise this code later on would not make any 
sense: for i in $PHP_ICONV /usr/local /usr; do )

The following patch is for 5.2.13, but I have verified it is also in the 5.2 
snap from today.

Index: php-5.2.13/acinclude.m4
===
--- php-5.2.13.orig/acinclude.m4
+++ php-5.2.13/acinclude.m4
@@ -2430,7 +2430,8 @@ AC_DEFUN([PHP_SETUP_ICONV], [
   dnl
   dnl Check libc first if no path is provided in --with-iconv
   dnl
-  if test "$PHP_ICONV" = "yes"; then
+  dnl must check against no, not against yes as PHP_ICONV can also include a 
path, which implies yes
+  if test "$PHP_ICONV" != no"; then
 AC_CHECK_FUNC(iconv, [
   found_iconv=yes
 ],[








-- 
Edit this bug report at https://bugs.php.net/bug.php?id=53442&edit=1

Bug #53156 [Opn->Asn]: imagerectangle problem with point ordering

[felipe]

Edit report at https://bugs.php.net/bug.php?id=53156&edit=1

 ID: 53156
 Updated by: fel...@php.net
 Reported by:ljb9832 at pobox dot com
 Summary:imagerectangle problem with point ordering
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:GD related
 Operating System:   Linux
 PHP Version:5.3.3
-Assigned To:
+Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

What do you think about, Pierre?


Previous Comments:

[2010-10-25 21:50:51] ljb9832 at pobox dot com

Description:

The documentation says imagerectangle() requires the upper left point first, 
then the lower right, whereas imagefilledrectangle() accepts the points in any 
order. In fact, imagerectangle() does work with all 4 possible orderings of the 
points, but only when drawing with unit thickness.  When drawing rectangles 
with thickness > 1, only 2 of the 4 cases work.

Before marking this as "working as documented" (which it is), please consider 
that there seems to be incorrect logic in gdImageRectangle() when handling the 
points.  It tests for y2https://bugs.php.net/bug.php?id=53156&edit=1

Bug #65120 [Opn->Fbk]: fpm build fails on ppc: #error Unsupported processor

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65120&edit=1

 ID: 65120
 Updated by: fel...@php.net
 Reported by:php-bugs-2013 at ryandesign dot com
 Summary:fpm build fails on ppc: #error Unsupported processor
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Compile Failure
 Operating System:   Mac OS X 10.5.8
 PHP Version:5.5.0
 Block user comment: N
 Private report: N

 New Comment:

Can you provide a patch that works on such architecture?


Previous Comments:

[2013-06-25 08:55:27] php-bugs-2013 at ryandesign dot com

Description:

Building the fpm sapi fails on a PowerBook G4 with Mac OS X 10.5.8 compiling 
with Apple's gcc 4.0.1 which comes with Xcode, with the following error:



:info:build /bin/sh 
/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_
lang_php/php55-fpm/work/php-5.5.0/libtool --silent --preserve-dup-deps --
mode=compile /usr/bin/gcc-4.0 -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0/sapi/fpm -Isapi/fpm/ -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/ -DPHP_ATOM_INC -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0/include -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0/main -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0 -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0/ext/date/lib -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0/ext/ereg/regex -
I/Volumes/Data/macports/leopard/include/libxml2 -
I/Volumes/Data/macports/leopard/include -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0/TSRM -
I/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports
_lang_php/php55-fpm/work/php-5.5.0/Zend  -
I/Volumes/Data/macports/leopard/include -no-cpp-precomp  -pipe -O2 -arch ppc -
fvisibility=hidden  -c 
/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_
lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm.c -o sapi/fpm/fpm/fpm.lo 
:info:build In file included from 
/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_
lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm_scoreboard.h:15,
:info:build  from 
/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_
lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm.c:21:
:info:build 
/Volumes/Data/macports/leopard/var/macports/build/_Volumes_Data_macports_dports_
lang_php/php55-fpm/work/php-5.5.0/sapi/fpm/fpm/fpm_atomic.h:142:2: error: 
#error 
Unsupported processor. Please open a bug report (bugs.php.net).


Previous bug reports about fpm sapi build failure on PowerPC or POWER 
processors 
include #51214 (closed as not a bug because fpm wasn't part of php at that 
time); #51772 (closed as no feedback; there was a patch attached but someone 
said it was unstable); #54273 (closed as won't fix because the person handling 
the bug had no access to PowerPC equipment).







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65120&edit=1

Bug #65111 [Asn->Nab]: Calling traits directly with static properties/methods

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65111&edit=1

 ID: 65111
 Updated by: fel...@php.net
 Reported by:ryan dot brothers at gmail dot com
 Summary:Calling traits directly with static
 properties/methods
-Status: Assigned
+Status: Not a bug
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux
 PHP Version:5.5.0
-Assigned To:gron
+Assigned To:
 Block user comment: N
 Private report: N

 New Comment:

Thanks for explaining it.


Previous Comments:

[2013-06-25 07:19:04] g...@php.net

Yes, traits are not supposed to be instantiated. However, this behavior is not 
really related to instantiation.

Traits are still a lexical entity, i.e., a programming language entity that 
provides a lexical scope when defined. Since PHP allows us to define functions 
in 
such scopes, we can define also static methods on traits.

The way to avoid that would be to change the grammar for traits.
I decided to not do that back in the day. And I still feel that it is unclear 
whether it would be conceptually cleaner if it is not possible to defined 
static 
state/methods.

So, I would leave it as it is. Except, someone comes up with a good reason to 
change it. But it would also be quite a bit of a BC issue.


[2013-06-25 04:30:41] larue...@php.net

hmm,  trait is actually a class in php, I have a quick look into this.. 
changing 
this will needs a significant works..

actually, the is_callable / do_call alreay is a little mess now. I mean the 
codes


[2013-06-24 16:52:52] ryan dot brothers at gmail dot com

Description:

The documentation for traits indicates that "it is not possible to instantiate 
a Trait on its own", but I have noticed that a trait can be called directly if 
it has a static property or method, as per the below example.  Is this intended 
behavior?  Or should traits be restricted from being called directly?  I was 
under the impression that traits cannot be called directly per the 
documentation.  If not, is there a way to prevent traits from being called 
directly as in the below example?

Test script:
---
https://bugs.php.net/bug.php?id=65111&edit=1

Bug #61594 [Asn->Csd]: ext/session/mod_mm.c: missing free of ps_mm_instance

[felipe]

Edit report at https://bugs.php.net/bug.php?id=61594&edit=1

 ID: 61594
 Updated by: fel...@php.net
 Reported by:jlawall at hotmail dot com
 Summary:ext/session/mod_mm.c: missing free of ps_mm_instance
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Session related
 PHP Version:master-Git-2012-04-01 (Git)
 Assigned To:yohgaki
 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=982c11573dd23d3070dfdd149e4ef1a5a1d14dab
Log: - Fixed bug #61594 (ext/session/mod_mm.c: missing free of ps_mm_instance) 
patch by: jlawall at hotmail dot com


Previous Comments:

[2012-04-01 20:29:05] jlawall at hotmail dot com

Description:

In the file ext/session/mod_mm.c, in the function PHP_MINIT_FUNCTION, it seems 
that ps_mm_instance should be freed and cleared when slprintf fails just as 
done on a later failure.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61594&edit=1

Bug #61828 [Opn->Asn]: Memleak when calling Directory(Recursive)Iterator/Spl(Temp)FileObject ctor twice

[felipe]

Edit report at https://bugs.php.net/bug.php?id=61828&edit=1

 ID: 61828
 Updated by: fel...@php.net
 Reported by:fel...@php.net
 Summary:Memleak when calling
 Directory(Recursive)Iterator/Spl(Temp)FileObject
 ctor twice
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:SPL related
 PHP Version:Irrelevant
-Assigned To:
+Assigned To:reeze
 Block user comment: N
 Private report: N

 New Comment:

I see the pull request was closed... but the fix has been in fact applied?


Previous Comments:

[2012-04-30 03:49:04] reeze dot xia at gmail dot com

Hi, felipe:
   I have attached a patch for this bug. and sent pull request at:
https://github.com/php/php-src/pull/71

will you take a look at this request?

Thank you!


[2012-04-23 16:10:34] fel...@php.net

Description:

See below.

Test script:
---
__construct('.');


Actual result:
------
/home/felipe/dev/php-src/main/streams/streams.c(530) : Stream of type 'dir' 
0x7fd490d7e5c0 (path:(null)) was not closed
[Mon Apr 23 13:07:34 2012]  Script:  '../bug.php'
/home/felipe/dev/php-src/main/streams/streams.c(292) :  Freeing 0x7FD490D7E5C0 
(248 bytes), script=../bug.php
/home/felipe/dev/php-src/main/streams/plain_wrapper.c(883) : Actual location 
(location was relayed)
[Mon Apr 23 13:07:34 2012]  Script:  '../bug.php'
/home/felipe/dev/php-src/ext/spl/spl_directory.c(252) :  Freeing 0x7FD490D7EA08 
(2 bytes), script=../bug.php
=== Total 2 memory leaks detected ===







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61828&edit=1

Bug #62129 [Asn->Fbk]: rfc1867 crashes php even though turned off

[felipe]

Edit report at https://bugs.php.net/bug.php?id=62129&edit=1

 ID: 62129
 Updated by: fel...@php.net
 Reported by:truth at proposaltech dot com
 Summary:rfc1867 crashes php even though turned off
-Status: Assigned
+Status: Feedback
 Type:   Bug
 Package:Session related
 Operating System:   CentOS
 PHP Version:5.4.3
-Assigned To:iliaa
+Assigned To:
 Block user comment: N
 Private report: N

 New Comment:

What's the problem assigning 'php_rfc1867_callback = 
php_session_rfc1867_orig_callback;' on PHP_MSHUTDOWN_FUNCTION? What happened to 
php_session_rfc1867_orig_callback is not pointing to the callback before MINIT?


Previous Comments:

[2013-01-27 05:18:33] gxd305 at gmail dot com

we should reset php_rfc1867_callback and php_session_rfc1867_orig_callback to 
null in MSHUTDOWN while changing them in MINIT.

with this patch
php-5.4.11-session-reset-global-var-in-shutdown
our php works fine in the production.

of course, it's not the fundamental solution


[2013-01-19 13:49:03] gxd305 at gmail dot com

i'm sorry for the last comment for the wrong analysis.

it should be php_rfc1867_callback reserve the old value ( 
php_session_rfc1867_callback) after reload, and make 
php_session_rfc1867_callback be called recursively.


[2013-01-19 11:26:34] gxd305 at gmail dot com

the other extensions have the similar problems if not set the global var to 
null in mshutdown after reload. 

php_session_rfc1867_orig_callback reserve the last value  after reload, instead 
of the default value null。

such as ice-php has the same problem, not set the global vars to null in 
mshutdown.

if i set the global vars ' default value explicitly or set the global vars to 
null in mshutdown, the problem goes away.


[2012-05-24 20:48:14] truth at proposaltech dot com

Here is a the relevant portion of the backtrace from the seg fault:

#104648 0x006cd5b8 in php_session_rfc1867_callback (event=0, 
event_data=0x7fffb2b8f950, extra=)
at /cns/build/php-5.4.3/ext/session/session.c:2388
#104649 0x006cd5b8 in php_session_rfc1867_callback (event=0, 
event_data=0x7fffb2b8f950, extra=)
at /cns/build/php-5.4.3/ext/session/session.c:2388
#104650 0x00473841 in rfc1867_post_handler (
content_type_dup=, arg=0x11535e8)
at /cns/build/php-5.4.3/main/rfc1867.c:773
#104651 0x00471372 in sapi_handle_post (arg=)
at /cns/build/php-5.4.3/main/SAPI.c:182
#104652 0x0067efd8 in mbstr_treat_data (arg=0, str=0x0, 
destArray=)
at /cns/build/php-5.4.3/ext/mbstring/mb_gpc.c:98
#104653 0x00475e9e in php_auto_globals_create_post (
name=0x12a6a60 "_POST", name_len=5)
at /cns/build/php-5.4.3/main/php_variables.c:682
#104654 0x0049aa4b in zend_auto_global_init (auto_global=0x110e800)
at /cns/build/php-5.4.3/Zend/zend_compile.c:
#104655 0x004ca974 in zend_hash_apply (ht=0x111bf20, 
apply_func=0x49aa30 )
at /cns/build/php-5.4.3/Zend/zend_hash.c:716
#104656 0x004772bb in php_hash_environment ()
at /cns/build/php-5.4.3/main/php_variables.c:642
#104657 0x004697f5 in php_request_startup ()
at /cns/build/php-5.4.3/main/main.c:1568
#104658 0x0056084f in apache_php_module_main (r=, 
display_source_mode=0) at /cns/build/php-5.4.3/sapi/apache/sapi_apache.c:33
#104659 0x00461c00 in send_php ()
#104660 0x00461c48 in send_parsed_php ()
#104661 0x0085f773 in ap_invoke_handler ()
#104662 0x00878d90 in process_request_internal ()
#104663 0x00878df3 in ap_process_request ()
#104664 0x0086e46f in child_main ()
#104665 0x0086e728 in make_child ()
#104666 0x0086e7e9 in startup_children ()
#104667 0x0086effb in standalone_main ()
#104668 0x0086f8cc in main ()

I don't know much about internals, but I'll try to translate the
above based on function names and values I saw in the debugger.

While activating auto_globals, the _POST auto_global had a
callback to be called: php_auto_globals_create_post().
That used the mbstring extension, which for the case of
PARSE_POST, relies on sapi_handle_post().
sapi_handle_post() used rfc1867_post_handler()
because the sapi_globals.request_info.post_entry had 
an rfc1867 post_handler:

print *sapi_globals.request_info.post_entry
$7 = {content_type = 0x8c4bc9 "multipart/form-data", content_type_len = 19, 
  post_reader = 0, post_handler = 0x473590 }

I don't know why that post_handler value was set to
rfc1867_post_handler given that my php.ini includes
session.upload_progress.enabled = off
Similarly, I don't know why php_rf

Bug #61387 [Asn->Csd]: NULL valued anonymous column causes segfault in odbc_fetch_array

[felipe]

Edit report at https://bugs.php.net/bug.php?id=61387&edit=1

 ID: 61387
 Updated by: fel...@php.net
 Reported by:marec at stringdata dot cz
 Summary:NULL valued anonymous column causes segfault in
 odbc_fetch_array
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:ODBC related
 Operating System:   windows server 2003 R2
 PHP Version:5.3.10
 Assigned To:ssb
 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=8776555d7a4fa510e79a986799921b4248c628c0
Log: - Fixed bug #61387 (NULL valued anonymous column causes segfault in 
odbc_fetch_array) patch by: Brandon Kirsch


Previous Comments:

[2013-04-15 13:50:05] brandonkirsch at gmail dot com

Here's a fix for this issue: https://github.com/php/php-src/pull/193

Please accept it! Would be nice to have a fix before the next 5.5 beta.


[2013-04-09 02:57:22] larue...@php.net

ssb, are you still active for odbc bugs fix?


[2012-09-12 23:51:50] brandonkirsch at gmail dot com

This problem is isolated to the SQL Server Native Client ODBC Driver. Most 
other 
ODBC drivers will automatically provide some type of aliased column name for 
arbitrary values that you select.

When using a SELECT 'VALUE' statement with SQL Server ODBC, the 
php_odbc_fetch_hash() function returns the column as 'VALUE' => 'VALUE' -- that 
is, the value you select is also the key in the array.

The problem occurs at the end of the php_odbc_fetch_hash() function in 
php_odbc.c (for me, on 5.2.17 it begins on line 1510) and it looks like this:

if (!*(result->values[i].name)) { // GDB says this evaluates to 1
  zend_hash_update(Z_ARRVAL_P(return_value), Z_STRVAL_P(tmp),
Z_STRLEN_P(tmp)+1, &tmp, sizeof(zval *), NULL); // SEGFAULT

This usage of zend_hash_update() causes a segfault in PHP 5.2.17 and PHP 
5.3.16.  
I guess that result->values[i].name looks legit and/or usable when it is not.

I updated the if statement to read:

if (!*(result->values[i].name) && Z_TYPE_P(tmp) != IS_NULL) { // Evaluates 
false 
for SQL NULLs that sets ZVAL_NULL(tmp)

This skips the incorrect usage of zend_hash_update with Z_STR* functions and 
proceeds to the "else" condition that handles it correctly.

For us, this solution works perfectly and the end-result is array("" => NULL) 
instead of a segfault.  Other unaliased NULL values from other databases 
continue to work the same way as before (iSeries ODBC drivers return 
array("0001" => NULL))

Here's the rub:  I have no idea how to generate or submit a patch.  But this 
fix 
works.  If someone can turn this into a real fix and run with it, great.  If 
someone would contact me and help me turn it into a real patch, I would be 
happy 
to help.


[2012-09-12 21:56:17] brandonkirsch at gmail dot com

I've been fighting with this bug all day long on PHP 5.2.17 *AND* PHP 5.3.16 
for 
64-bit Linux.

I have isolated the problem to odbc_fetch_array() for result sets that contain 
an anonymous (unnamed) column with a NULL value. If NULL value is aliased 
("SELECT NULL as SOMETHING") there is no crash.  If an anonymous (unnamed) 
column contains anything other than NULL, there is no crash.

Test Script:

$sql = 'SELECT NULL';

$c = odbc_connect('Driver=SQL Server Native Client 
11.0;server=hpesc1;uid=xxx;pwd=xxx;Database=xxx','','');

$e = odbc_exec($c, $sql);

$row = odbc_fetch_array($e);


Here are different combinations of SQL that will or won't crash PHP:

$sql = 'SELECT NULL'; // PHP SEGFAULT
$sql = 'SELECT NULL as [one]'; // OK
$sql = 'SELECT 1'; // OK
$sql = 'SELECT 1, NULL'; // SEGFAULT
$sql = 'SELECT 1, NULL as [two]'; // OK

And a backtrace:


#0  zend_inline_hash_func (nKeyLength=, arKey=0x0) at 
/usr/src/php-5.3.16/Zend/zend_hash.h:283
#1  _zend_hash_add_or_update (ht=0xfce8b8, arKey=0x0, nKeyLength=1, 
pData=0x7fffab90, nDataSize=8, pDest=0x0, flag=1) at /usr/src/php-
5.3.16/Zend/zend_hash.c:218
#2  0x0057528f in php_odbc_fetch_hash (ht=, 
return_value=0xfccfe8, result_type=2, return_value_ptr=, 
this_ptr=, 
return_value_used=) at /usr/src/php-
5.3.16/ext/odbc/php_odbc.c:1775


My comprehension of C & the PHP source code is very limited, but it looks like 
php_odbc.c lines 1752 (handling of SQL_NULL_DATA) and 1771 through 1779 are 
suspect.  I think php_odbc.c may be using zend

Bug #61697 [Asn]: spl_autoload_functions returns lambda functions incorrectly

[felipe]

Edit report at https://bugs.php.net/bug.php?id=61697&edit=1

 ID: 61697
 Updated by: fel...@php.net
 Reported by:stadli at gmx dot de
 Summary:spl_autoload_functions returns lambda functions
 incorrectly
 Status: Assigned
 Type:   Bug
 Package:SPL related
 PHP Version:5.4.0
-Assigned To:colder
+Assigned To:dsp
 Block user comment: N
 Private report: N

 New Comment:

David, what about this change on 5.5?


Previous Comments:

[2013-03-11 04:09:41] stadli at gmx dot de

Is there a reason, why this fix still hasn't been implemented?

I'd like to see this bug fixed in PHP 5.5


[2012-04-12 05:21:32] larue...@php.net

I have made a patch for this, but there is a BC break, that is, 
spl_autoload_functions return lambad_function with name "__lambad_function" 
previously.

after patched, it will return string like "lambad_1".


[2012-04-12 05:19:39] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61697.phpt
Revision:   1334207979
URL:
https://bugs.php.net/patch-display.php?bug=61697&patch=bug61697.phpt&revision=1334207979


[2012-04-12 05:16:05] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61697.patch
Revision:   1334207765
URL:
https://bugs.php.net/patch-display.php?bug=61697&patch=bug61697.patch&revision=1334207765


[2012-04-11 18:29:18] stadli at gmx dot de

Description:

spl_autoload_functions() doesn't return the names of lambda-functions 
registered with spl_autoload_register() correctly. Actually it always returns 
'__lambda_func' for every lambda function so you can't use the result with 
spl_autoload_unregister() for example.

Test script:
---



Expected result:

All autoload functions are unregistered

Actual result:
--
lambda functions aren't unregistered






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61697&edit=1

Bug #63570 [Opn->Asn]: Bogus warning 'Operation now in progress'

[felipe]

Edit report at https://bugs.php.net/bug.php?id=63570&edit=1

 ID: 63570
 Updated by: fel...@php.net
 Reported by:kakserpompoyaitsam at gmail dot com
 Summary:Bogus warning 'Operation now in progress'
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:Sockets related
 Operating System:   linux
 PHP Version:5.4.8
-Assigned To:
+Assigned To:cataphract
 Block user comment: N
 Private report: N

 New Comment:

Gustavo, what do you think about the patch?


Previous Comments:

[2012-12-03 11:57:06] osma...@php.net

I've uploaded a simple patch. But I'd rather do it via exceptions as in other 
languages like Python.


[2012-12-03 11:54:03] osma...@php.net

The following patch has been added/updated:

Patch Name: ignore-warnings-for-nonblocking
Revision:   1354535643
URL:
https://bugs.php.net/patch-display.php?bug=63570&patch=ignore-warnings-for-nonblocking&revision=1354535643


[2012-11-28 12:41:30] osma...@php.net

The following patch has been added/updated:

Patch Name: ignore-EINPROGRESS-warning-nonblocking-2
Revision:   1354106490
URL:
https://bugs.php.net/patch-display.php?bug=63570&patch=ignore-EINPROGRESS-warning-nonblocking-2&revision=1354106490


[2012-11-28 12:40:08] osma...@php.net

The following patch has been added/updated:

Patch Name: ignore-EINPROGRESS-warning-nonblocking
Revision:   1354106408
URL:
https://bugs.php.net/patch-display.php?bug=63570&patch=ignore-EINPROGRESS-warning-nonblocking&revision=1354106408


[2012-11-28 12:33:54] osma...@php.net

The following patch has been added/updated:

Patch Name: ignore-EINPROGRESS-warning
Revision:   1354106034
URL:
https://bugs.php.net/patch-display.php?bug=63570&patch=ignore-EINPROGRESS-warning&revision=1354106034




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=63570


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63570&edit=1

Bug #64258 [Opn->Asn]: --with-mcrypt causes bad linking (with --with-libxml-dir). Reason: -lltdl flag

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64258&edit=1

 ID: 64258
 Updated by: fel...@php.net
 Reported by:spamik at yum dot pl
 Summary:--with-mcrypt causes bad linking (with
 --with-libxml-dir). Reason: -lltdl flag
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:*Compile Issues
 PHP Version:5.4.16
-Assigned To:
+Assigned To:derick
 Block user comment: N
 Private report: N

 New Comment:

Derick, feedback has been supplied.


Previous Comments:

[2013-06-13 17:25:10] spamik at yum dot pl

./buildconf --force
sorry I've missed that.

Now patch does work


[2013-06-13 17:11:46] spamik at yum dot pl

# cat /usr/include/mutils/mcrypt.h | grep VER
#define MCRYPT_API_VERSION 20021217
#define LIBMCRYPT_VERSION "2.5.8"

I've aplied PATCH but it DOES NOT WORK (tested on freshly unpacked source)
root@sv18 [/root/naox/php-5.4.16]# patch -p1 < p
patching file ext/mcrypt/config.m4

# ./configure --with-libxml-dir=/usr/libxml2-2.7.8 --with-mcrypt && make

root@sv18 [/root/naox/php-5.4.16]# ldd sapi/cli/php|grep xml
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x7f95fe8bd000)

root@sv18 [/root/naox/php-5.4.16]# cat Makefile|grep 'lltdl'
EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lmcrypt -lltdl -lrt -lm -ldl -lnsl -
lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -lxml2 -lz -
lm -lxml2 -lz -lm -lcrypt

-lltdl is still present even with the pathc


[2013-06-13 08:56:02] der...@php.net

The following patch has been added/updated:

Patch Name: mcrypt-config-20130613
Revision:   1371113762
URL:
https://bugs.php.net/patch-display.php?bug=64258&patch=mcrypt-config-20130613&revision=1371113762


[2013-06-13 08:55:32] der...@php.net

It's a linker helper library as used by gnu libtool. I have no idea why it 
messes the libxml include though, and as far as I know, that library is no 
longer needed since libmcrypt 2.5.4. So unless your version is that old, -lltdl 
should not be part of your Makefile. If I manually remove -lltdl from the 
Makefile, PHP still compiles and links, so I would recommend you try the 
following:

cat /usr/include/mutils/mcrypt.h | grep VER

And let me know what it says. Secondly, apply the attached patch to 
ext/mcrypt/config.m4 and then run:

make clean
./buildconf --force
./config.nice
make

and see which libxml it now links too.


[2013-06-13 00:57:01] spamik at yum dot pl

root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 && 
make
root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml 
libxml2.so.2 => /usr/libxml2-2.9.0/lib/libxml2.so.2 (0x7f6b2c098000)

root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 --
with-mcrypt && make
root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x7f1478692000)

When configured with mcrypt Makefile has
EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lmcrypt -lltdl -lrt -lm -ldl -lnsl 
-lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -
lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt

when configured without mcrypt Makefile has
EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lxml2 -lz -lm 
-lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -
lxml2 -lz -lm -lxml2 -lz -lm -lcrypt


problem seems to be caused by flag -lltdl. When removed manualy, libxml2 is 
liked ok. What is this flag?




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=64258


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64258&edit=1

Bug #65018 [Opn->Asn]: SoapHeader problems with SoapServer

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65018&edit=1

 ID: 65018
 Updated by: fel...@php.net
 Reported by:guillaume dot lintot at laposte dot net
 Summary:SoapHeader problems with SoapServer
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:SOAP related
 PHP Version:Irrelevant
-Assigned To:
+Assigned To:dmitry
 Block user comment: N
 Private report: N



Previous Comments:

[2013-06-12 10:20:02] guillaume dot lintot at laposte dot net

Description:

SoapHeader::mustUnderstand are ignore in SoapServer context

Test script:
---
'.PHP_EOL.
'http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:ns1="namespace1"'.
' xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";'.
' xmlns:xsd="http://www.w3.org/2001/XMLSchema";>'.
'abc'.
'';

$soap = new SoapServer(null, array('uri' => '127.0.0.1'));
$soap->setClass('Tool'); $soap->handle($input);
$out = ob_get_contents(); ob_end_clean();

echo $out;
?>

Expected result:

abc

Actual result:
--
abc






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65018&edit=1

Bug #65110 [Opn->Asn]: mb_convert_encoding's auto is not work, when using mbstring.language=English

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65110&edit=1

 ID: 65110
 Updated by: fel...@php.net
 Reported by:f133715 at rmqkr dot net
 Summary:mb_convert_encoding's auto is not work, when using
 mbstring.language=English
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:mbstring related
 Operating System:   Windows
 PHP Version:5.4.16
-Assigned To:
+Assigned To:moriyoshi
 Block user comment: N
 Private report: N



Previous Comments:

[2013-06-24 12:44:21] f133715 at rmqkr dot net

Description:

1. The version number of the PHP package or files you are using.
Latest PHP 5.4 for Windows

2. A short script that reproduces the problem


Sometimes, it produce this error on log file:
Warning: mb_convert_encoding(): Unable to detect character encoding in XXX.php 
on line XXX

It seems that 'auto' is not expanding to "ASCII,JIS,UTF-8,EUC-JP,SJIS".

This is a temporary fix for me:
[TYPE A]
$out_strs = mb_convert_encoding($out_strs, "UTF-8", "ASCII,JIS,UTF-8,EUC-
JP,SJIS");

or,
[TYPE B]
mb_language("Japanese");
$out_strs = mb_convert_encoding($out_strs, "UTF-8", "auto");


Test script:
---
I'm Englishman, so I'm added this in php.ini;
mbstring.language = English
mbstring.internal_encoding = UTF-8

And the source code is;
$out_strs = mb_convert_encoding($out_strs, "UTF-8", "auto");

Expected result:

auto SHOULD expand to ASCII,JIS,UTF-8,EUC-JP,SJIS.
Why should I change mbstring.language = English to Japs?







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65110&edit=1

Bug #65111 [Opn->Asn]: Calling traits directly with static properties/methods

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65111&edit=1

 ID: 65111
 Updated by: fel...@php.net
 Reported by:ryan dot brothers at gmail dot com
 Summary:Calling traits directly with static
 properties/methods
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux
 PHP Version:5.5.0
-Assigned To:
+Assigned To:gron
 Block user comment: N
 Private report: N



Previous Comments:

[2013-06-24 16:52:52] ryan dot brothers at gmail dot com

Description:

The documentation for traits indicates that "it is not possible to instantiate 
a Trait on its own", but I have noticed that a trait can be called directly if 
it has a static property or method, as per the below example.  Is this intended 
behavior?  Or should traits be restricted from being called directly?  I was 
under the impression that traits cannot be called directly per the 
documentation.  If not, is there a way to prevent traits from being called 
directly as in the below example?

Test script:
---
https://bugs.php.net/bug.php?id=65111&edit=1

Bug #65055 [Opn->Asn]: new Operator shuld never return a NULL new ResourceBundle

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65055&edit=1

 ID: 65055
 Updated by: fel...@php.net
 Reported by:goetas at lignano dot it
 Summary:new Operator shuld never return a NULL new
 ResourceBundle
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:I18N and L10N related
 Operating System:   ubuntu 12.04
 PHP Version:5.4.16
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

Seems it is not the only class which has such behavior.


Previous Comments:

[2013-06-18 07:59:01] goetas at lignano dot it

Description:

sapi/cli/php -v
PHP 5.4.16 (cli) (built: Jun 18 2013 09:34:40) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies


Instantiating ResourceBundle class, a "new" operator should never return null.

http://php.net/manual/en/language.oop5.basic.php#language.oop5.basic.new

"To create an instance of a class, the new keyword must be used. An object will 
always be created unless the object has a constructor defined that throws an 
exception on error."

This behaviour it's also verified by Symfony team 
https://github.com/symfony/Intl/blob/master/ResourceBundle/Reader/BinaryBundleReader.php


Test script:
---
sapi/cli/php -r 'var_dump(new \ResourceBundle("ANY WRONG PATH", "it"));'



Expected result:

Thrown some exception

Actual result:
--
NULL






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65055&edit=1

Bug #65086 [Opn->Fbk]: libssl not found while configuring php-5.5.0

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65086&edit=1

 ID: 65086
 Updated by: fel...@php.net
 Reported by:mark at kreine dot ru
 Summary:libssl not found while configuring php-5.5.0
-Status: Open
+Status: Feedback
 Type:   Bug
-Package:Safe Mode/open_basedir
+Package:Compile Failure
 Operating System:   Ubuntu 12.04
 PHP Version:5.5.0
 Block user comment: N
 Private report: N

 New Comment:

Have you found any libssl*.so on your system?


Previous Comments:

[2013-06-21 13:15:06] mark at kreine dot ru

Description:

I'm trying to compile php-5.5.0 on my server using the following configure 
script: 

./configure --prefix=/soft/php --with-apxs2=/soft/httpd/bin/apxs 
--with-mysql=shared,/soft/mysql 
--with-mysqli=shared,/soft/mysql/bin/mysql_config 
--with-pdo-mysql=shared,/soft/mysql/bin/mysql --with-zlib-dir=/soft/zlib 
--with-zlib=shared,/soft/zlib --with-libxml-dir=/soft/libxml 
--with-jpeg-dir=/soft/libjpeg --with-png-dir=/soft/libpng 
--with-pcre-dir=/soft/pcre --enable-exif --enable-bcmath --enable-ftp 
--enable-calendar --enable-mbstring --with-bz2=shared,/soft/bzip 
--with-openssl-dir=/soft/openssl --with-openssl=shared,/soft/openssl 
LDFLAGS="-L/soft/openssl/lib" CPPFLAGS="-I/soft/openssl/include/openssl"

The configure script complains me on lack of the libssl library.

Test script:
---
./configure --prefix=/soft/php --with-apxs2=/soft/httpd/bin/apxs 
--with-mysql=shared,/soft/mysql 
--with-mysqli=shared,/soft/mysql/bin/mysql_config 
--with-pdo-mysql=shared,/soft/mysql/bin/mysql --with-zlib-dir=/soft/zlib 
--with-zlib=shared,/soft/zlib --with-libxml-dir=/soft/libxml 
--with-jpeg-dir=/soft/libjpeg --with-png-dir=/soft/libpng 
--with-pcre-dir=/soft/pcre --enable-exif --enable-bcmath --enable-ftp 
--enable-calendar --enable-mbstring --with-bz2=shared,/soft/bzip 
--with-openssl-dir=/soft/openssl --with-openssl=shared,/soft/openssl 
LDFLAGS="-L/soft/openssl/lib" CPPFLAGS="-I/soft/openssl/include/openssl"

Expected result:

Successful configuration

Actual result:
--
checking for OpenSSL support... yes, shared
checking for Kerberos support... no
checking for DSA_get_default_method in -lssl... no
checking for X509_free in -lcrypto... yes
checking for pkg-config... no
checking for OpenSSL version... >= 0.9.6
checking for CRYPTO_free in -lcrypto... yes
checking for SSL_CTX_set_ssl_version in -lssl... no
configure: error: libssl not found!







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65086&edit=1

Bug #65091 [Opn->Fbk]: Scanner Bug

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65091&edit=1

 ID: 65091
 Updated by: fel...@php.net
 Reported by:keithk at powderkeginteractive dot com
 Summary:Scanner Bug
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:*General Issues
 Operating System:   Linux
 PHP Version:5.5.0
 Block user comment: N
 Private report: N

 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




Previous Comments:

[2013-06-21 21:30:33] keithk at powderkeginteractive dot com

Description:

Environment:
-Debian Linux Etch, Lenny, Squeeze and Wheezy (standard LAMP stacks)
-Oracle Cluster File System (OCFS2)
-PHP 5.3, 5.4 and 5.5 (across any of the above systems)

PHP 5.3 and above seems to have an issue where the scanner scans past the end 
of a PHP script, allowing unexpected/junk characters to be tokenized and 
causing the parser to emit "unexpected ... at end of file" and related failures.

This has happened across many different valid PHP scripts, so there isn't any 
"test script" I can reasonably provide. A common theme among the scripts, 
however, is that they end with } or some other single-token character.

Note that this issue does *not* happen when using PHP 5.2 within the same 
environment and scripts.

I suspect that memory mapping with a look-ahead buffer, as PHP/Zend does, isn't 
always returning the ideal case of null-padded data. This may be related to the 
specific use of OCFS2... perhaps one bug revealing another.

At any rate, I've investigated the scanner and it does seem to make an 
assumption that supports the above edge case. The lex_scan function does not 
check if the buffer pointer is right at the limit, only before or after, 
allowing the scanner to read past the end of the buffer.

Proposed solution: replace all instances of "(YYCURSOR > YYLIMIT)" with 
"(YYCURSOR >= YYLIMIT)" in Zend/zend_language_scanner.l







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65091&edit=1

Bug #65011 [Opn->Asn]: ReflectionProperty::getDocComment() fails for multiple variable declarations

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65011&edit=1

 ID: 65011
 Updated by: fel...@php.net
 Reported by:benjamin dot morel at gmail dot com
 Summary:ReflectionProperty::getDocComment() fails for
 multiple variable declarations
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:Reflection related
 Operating System:   CentOS 6.4
 PHP Version:5.4.16
-Assigned To:
+Assigned To:johannes
 Block user comment: N
 Private report: N

 New Comment:

Johannes, what is your opinion about this suggestion?


Previous Comments:

[2013-06-11 10:54:07] benjamin dot morel at gmail dot com

Description:

When multiple class properties are declared at once, 
ReflectionProperty::getDocComment() only returns the doc comment for the first 
one.

I believe that the doc comment applies to all of the properties if they're 
declared together, so getDocComment() should return the same value for all of 
them, not just the first one.

Test script:
---
class Foo {
/** @var string */
public $a, $b;
}

$class = new \ReflectionClass('Foo');
foreach ($class->getProperties() as $property) {
echo $property->getName() . ': ' . var_export($property->getDocComment(), 
true) . PHP_EOL;
}

Expected result:

a: '/** @var string */'
b: '/** @var string */'

Actual result:
--
a: '/** @var string */'
b: false






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65011&edit=1

Bug #65093 [Opn->Asn]: password_hash ignores salts with spaces

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65093&edit=1

 ID: 65093
 Updated by: fel...@php.net
 Reported by:michael at squiloople dot com
 Summary:password_hash ignores salts with spaces
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:hash related
 Operating System:   Windows Vista SP2
 PHP Version:5.5.0
-Assigned To:
+Assigned To:ircmaxell
 Block user comment: N
 Private report: N



Previous Comments:

[2013-06-22 12:36:11] michael at squiloople dot com

Would it be worth then having an error or a boolean/null return value rather 
than 
have it "fail" silently? If at any point the allowed characters for the salt 
were 
to extend then past hashes (where a salt was generated by the developer with 
previously invalid characters) would be broken.

If you give the developer the option to provide a value then surely it should 
be 
either accepted or denied rather than just ignored.


[2013-06-22 05:48:33] r...@php.net

I think it's only a documentation problem which should explains which are the 
allowed characters in the salt (from code: a-z A-Z 0-9 . /)

(notice: It is strongly recommended that you do not generate your own salt for 
this function)


[2013-06-21 22:37:03] michael at squiloople dot com

Description:

When manually setting a salt which contains spaces the function ignores it and 
automatically generates its own.

Test script:
---
  echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' => 
'thisisatestthisisatest'));

  echo '';

  echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' => 
'thisisatestthisis test'));

Expected result:

$2y$10$thisisatestthisisateseLNFJ7M2ONUSijVBKli7sVFN6rQm7o36
$2y$10$thisisatestthisis tesOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO

(with the part after the salt being whatever it would be)

Actual result:
--
$2y$10$thisisatestthisisateseLNFJ7M2ONUSijVBKli7sVFN6rQm7o36
$2y$10$dGhpc2lzYXRlc3R0aGlzaOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65093&edit=1

Bug #65100 [Opn->Asn]: Reject root run

[felipe]

Edit report at https://bugs.php.net/bug.php?id=65100&edit=1

 ID: 65100
 Updated by: fel...@php.net
 Reported by:admin at mvpro dot net
 Summary:Reject root run
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:FPM related
 Operating System:   Linux Debian Wheezy
 PHP Version:5.5.0
-Assigned To:
+Assigned To:fat
 Block user comment: N
 Private report: N



Previous Comments:

[2013-06-23 03:36:07] admin at mvpro dot net

Description:

Php5-fpm rejected to run with user 'root' and group 'root', it fails to load.

While proccess priority was implemented, i assume, running PHP-fpm with user 
'root' should be allowed.

Test script:
---
Put in /etc/php5/fpm/pool.d/www.conf

user = root

Expected result:

Success run.

Actual result:
--
Fail to run.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65100&edit=1

Bug #64883 [Opn->Fbk]: SIGSEGV in var.c:363

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64883&edit=1

 ID: 64883
 Updated by: fel...@php.net
 Reported by:pyo at mail dot ru
 Summary:SIGSEGV in var.c:363
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:*General Issues
 Operating System:   FreeBSD 9.1
 PHP Version:5.4.15
 Block user comment: N
 Private report: N

 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




Previous Comments:

[2013-05-20 19:30:41] pyo at mail dot ru

Moved to General Issues.


[2013-05-20 15:47:56] pyo at mail dot ru

Description:

I have old 3rd party script, that was used on shared hosting with PHP 5.2.6 
running as apache module. I have no complaints about it from hosting.
Now I moved this code to VPS and have SIGSEGV in both php-fpm or php-cli mode.
The code was not written by me, so I do not know what statements make 
segmentation fault.

PHP Version => 5.4.15

System => FreeBSD torq1.pyo 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Mon Apr 
29 18:11:52 UTC 2013 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386
Build Date => May 14 2013 16:21:38
Configure Command =>  './configure'  '--with-layout=GNU' '--localstatedir=/var' 
'--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' 
'--enable-libxml' '--enable-mysqlnd' '--with-libxml-dir=/usr/local' 
'--with-pcre-regex=/usr/local' '--with-zlib-dir=/usr' '--program-prefix=' 
'--enable-fpm' '--with-fpm-user=www' '--with-fpm-group=www' '--with-regex=php' 
'--with-zend-vm=CALL' '--prefix=/usr/local' '--mandir=/usr/local/man' 
'--infodir=/usr/local/info/' '--build=i386-portbld-freebsd9.1'
Server API => Command Line Interface

modified ini settings:
expose_php = Off
max_execution_time = 59
memory_limit = 64M
default_charset = "UTF-8"
date.timezone = "Europe/Moscow"
mysql.allow_persistent = Off
mysqli.allow_persistent = Off
pgsql.allow_persistent = Off

Actual result:
--
Current language:  auto; currently minimal
#0  0x081f in php_array_element_export (zv=0xbfbfdf88, num_args=137402536, 
args=0x13e , hash_key=0x81dddce) at var.c:363
__nl = 0
__dest = (smart_str *) 0x29f8f894
tmp_spaces = 0x819a7f0 ""
tmp_spaces_len = 679495168
key = 0x819a815 "яй"
tmp_str = 0xbfbfdf38 "А'"
key_len = 28
tmp_len = 704231864
level = -107790
buf = (smart_str *) 0x29e0d038
#1  0x081af2fa in metaphone (word=0x2a184bb8 "", word_len=702293828, 
max_phonemes=704185368, phoned_word=0xbfbfdf88, traditional=137402536)
at metaphone.c:360
skip_letter = 10720
w_idx = 318
p_idx = 136175054
max_buffer_len = -107790
#2  0x081dccce in php_var_export_ex (struc=0x2881602c, level=702608140, 
buf=0x29e0d038) at var.c:489
__nl = 3217022776
__dest = (smart_str *) 0x1c
myht = (HashTable *) 0x2
tmp_str = 0x29571668 "8\001"
tmp_len = -1077944436
class_name = 0x29f88e84 "Ьна)"
class_name_len = 20
tmp_str2 = 0x0
tmp_len2 = 702606812
#3  0x08202ee4 in php_var_unserialize (rval=0x29e105a4, p=0x29571668, 
max=0x8202ee4 "MЛ\017¶EЛ=/", var_hash=0xbfbfe028)
at var_unserializer.c:1179
yych = 41 ')'
cursor = (const unsigned char *) 0x16 
limit = (const unsigned char *) 0x29e0f30c "\002p\036),са)Ьна)"
marker = (const unsigned char *) 0x2881602c "\234юа)\fуа)"
start = (const unsigned char *) 0x2881602c "\234юа)\fуа)"
rval_ref = (zval **) 0x29e0f30c
yybm = '\0' , 
"\200\200\200\200\200\200\200\200\200\200", '\0' 
#4  0x081de716 in php_array_element_export (zv=0xbfe068, num_args=702608140, 
args=0xbfe180 , hash_key=0x8320ae0)
at var.c:375
__nl = 3217023000
level = -1077944200
buf = (smart_str *) 0x1c
#5  0x081b0bb0 in _php_gettimeofday (ht=-1077944024, return_value=0x0, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, mode=0)
at microtime.c:77
offset = (timelib_time_offset *) 0x0
get_as_float = 0 '\0'
tp = {tv_sec = 0, tv_usec = 0}
#6  0x081ceeb6 in php_strtr_array_do_repl (text=0x0, d=0x0, return_value=0x101)
at string.c:3113
__nl = 3217023396
__dest = (smart_str *) 0xbfbfe1a8
pnr = (PATNREPL *) 0x0

Bug #64902 [Opn->Asn]: zip_entry_read never returns FALSE

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64902&edit=1

 ID: 64902
 Updated by: fel...@php.net
 Reported by:chad at getfidelis dot com
 Summary:zip_entry_read never returns FALSE
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:Zip Related
 Operating System:   Linux (Fedora)
 PHP Version:5.4.15
-Assigned To:
+Assigned To:pajoye
 Block user comment: N
 Private report: N



Previous Comments:

[2013-05-22 18:27:08] chad at getfidelis dot com

Description:

---
>From manual page: http://www.php.net/function.zip-entry-read#refsect1-
function.zip-entry-read-returnvalues
---
The function is documented as returning FALSE if the end of the file is 
reached.  
However, this never happens: it returns a 0-length string instead.

Observed on CentOS 6.4 and reproducible on:
PHP 5.4.15 (cli) (built: May 22 2013 14:14:09)
PHP 5.3.25 (cli) (built: May 22 2013 14:11:27)

Test script:
---
\n";
?>

Expected result:

processing part 

Actual result:
--
processing part 
processing part <>
processing part <>
processing part <>
processing part <>
processing part <>
processing part <>






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64902&edit=1

Bug #64913 [Opn->Fbk]: Segfault in zend_hash_find

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64913&edit=1

 ID: 64913
 Updated by: fel...@php.net
 Reported by:slusarz at curecanti dot org
 Summary:Segfault in zend_hash_find
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Linux
 PHP Version:5.4.15
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

  http://snaps.php.net/php-trunk-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




Previous Comments:

[2013-05-24 06:21:58] slusarz at curecanti dot org

Description:

(Mostly) reproducible segfault:

[353713.319612] php-fpm[24273]: segfault at 30 ip 00742b28 sp 
7fff3f5f3950 error 4 in php-fpm[40+97]

Verified occuring if either APC, ZendOPcache, or neither is active.

Appears to be happening in shutdown code.  Main actions in code is successful, 
but valid response is never sent back to browser.

Test script:
---
Script causing segfault is Spam message reporting in IMP 
(http://www.horde.org/imp/).  90% of time script crashes, although spam 
reporting is successful.  However, 10% of time script is successful with no 
segfault.  Additionally, saw this for months, upgraded OS (using Arch Linux) - 
had no issues for a month.  Recently rebooted (after several further upgrades) 
and am seeing again.

Actual result:
--
Core was generated by `php-fpm: pool www  '.
Program terminated with signal 11, Segmentation fault.
#0  0x00742b28 in zend_hash_find (ht=0x2ef2358,
arKey=arKey@entry=0xc13e40 "stream", nKeyLength=nKeyLength@entry=7,
pData=pData@entry=0x7fff3f5f39e8)
at /disk2/src/php-5.4.15/Zend/zend_hash.c:924
924 p = ht->arBuckets[nIndex];
(gdb) bt full
#0  0x00742b28 in zend_hash_find (ht=0x2ef2358,
arKey=arKey@entry=0xc13e40 "stream", nKeyLength=nKeyLength@entry=7,
pData=pData@entry=0x7fff3f5f39e8)
at /disk2/src/php-5.4.15/Zend/zend_hash.c:924
h = 229483039115121
nIndex = 0
p = 
#1  0x006b0b30 in userfilter_filter (stream=0x3072540,
thisfilter=, buckets_in=0x7fff3f5f3aa0,
buckets_out=0x7fff3f5f3ab0, bytes_consumed=0x7fff3f5f3a98, flags=2)
at /disk2/src/php-5.4.15/ext/standard/user_filters.c:183
ret = 0
obj = 0x2ef96d0
func_name = {value = {lval = 49225688, dval = 2.43207213336997e-316,
str = {val = 0x2ef1fd8 "\220\376\355\002", len = 3},
ht = 0x2ef1fd8, obj = {handle = 49225688, handlers = 0x3}},
  refcount__gc = 24, type = 0 '\000', is_ref__gc = 0 '\000'}
retval = 0x0
args = {0x0, 0x7f3c4d876770, 0x7f3c4d876808,
  0x75a5c4 }
zclosing = 0x710c48 <_zend_mm_free_int+200>
zconsumed = 0x2ef5058
zin = 0x710c48 <_zend_mm_free_int+200>
zout = 0x2f75eb0
zstream = 0x710c48 <_zend_mm_free_int+200>
zpropname = {value = {lval = 49225688, dval = 2.43207213336997e-316,
str = {val = 0x2ef1fd8 "\220\376\355\002", len = 7408712},
ht = 0x2ef1fd8, obj = {handle = 49225688,
  handlers = 0x710c48 <_zend_mm_free_int+200>}},
  refcount__gc = 49349512, type = 0 '\000', is_ref__gc = 0 '\000'}
call_result = 
#2  0x006eeff4 in _php_stream_write_filtered (
stream=stream@entry=0x3072540, buf=buf@entry=0x0, count=count@entry=0,
flags=2) at /disk2/src/php-5.4.15/main/streams/streams.c:1177
consumed = 0
bucket = 
brig_in = {head = 0x0, tail = 0x0}
brig_out = {head = 0x0, tail = 0x0}
brig_inp = 0x7fff3f5f3aa0
brig_outp = 0x7fff3f5f3ab0
brig_swap = 
status = PSFS_ERR_FATAL
filter = 0x2efb298
#3  0x006f065c in _php_stream_flush (stream=0x3072540,
closing=)
at /disk2/src/php-5.4.15/main/streams/streams.c:1226
No locals.
#4  0x006f224a in _php_stream_free (stream=,
close_options=11) at /disk2/src/php-5.4.15/main/streams/streams.c:461
ret = 1
preserve_handle = 0
release_cast = 1
context = 0x0
#5  0x006f2521 in stream_resource_regular_dtor (rsrc=)
at /disk2/src/php-5.4.15/main/streams/streams.c:1616
stream = 
#6  0x0074404e in list_entry_destructor (ptr=0x2efa320)
at /disk2/src/php-5.4.15/Zend/zend_list.c:183
le = 0x2efa320
ld = 0x27aaae0
#7  0x00741efe in zend_hash_del_key_or_index (
ht=0xfa0410 , arKey=arKey@entry=0x0,
nKeyLength=nKeyLength@entry=0, h=h@entry=89, flag=flag@entry=1)
at /disk2/src/php-5.4.15/Zend/zend_hash.c:531
nIndex = 
p = 0x2efa360
#8  0x007441f7 in _zend_list_delete (id=)
at /disk2/src/php-5.4.15/Zend/zend_list.c:57
le = 0x2efa320
#9  0x007269b2 in _zval_dtor (z

Bug #64942 [Opn->Fbk]: Segfault after Cannot declare self-referencing constant

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64942&edit=1

 ID: 64942
 Updated by: fel...@php.net
 Reported by:j_schumann at gmx dot de
 Summary:Segfault after Cannot declare self-referencing
 constant
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Ubuntu 10.04.4 LTS
 PHP Version:5.4.15
 Block user comment: N
 Private report: N

 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




Previous Comments:

[2013-05-29 10:01:47] j_schumann at gmx dot de

Description:

This is a followup/duplicate to Bug #63669 as this is not mine and was 
suspended:

I get the same "PHP Fatal error: Cannot declare self-referencing constant" as 
the opener of #63669. But after this the process dies by a segmentation fault.

Debugging gave me the same error file/line, but I could reduce the number of 
possible sources: It only happens for me on instantiation of 
Zend_Validate_File_Count 
(http://framework.zend.com/svn/framework/standard/trunk/library/Zend/Validate/File/Count.php).


Environment:
PHP 5.4.11
APC 3.1.13 
Apache 2.2.14
Ubuntu 10.04.4 LTS

Test script:
---
I can not provide a reproduction script as this does not happen always, so 
maybe it is instead an APC problem.

Expected result:

PHP Shutdown after the fatal error instead of segmentation fault.

Actual result:
--
I can provide a backtrace from the coredump (still using 5.4.11, I could 
produce a newer trace if required):

#0  0x7fab657aec05 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fab6113c4e4 in xbuf_format_converter (xbuf=0x7fff625433b0, fmt=0x1 
, ap=0x7fff62542b20)
at /build/buildd/php5-5.4.11/main/spprintf.c:576
#2  0x7fab6113d214 in vspprintf (pbuf=0x7fff62543450, max_len=1024, 
format=0xffbd1ad6 , ap=0x18)
at /build/buildd/php5-5.4.11/main/spprintf.c:799
#3  0x7fab611367a8 in php_error_cb (type=1,
error_filename=0x7fab56404f80 
"/var/www/application/library/Zend/File/Transfer/Adapter/Abstract.php", 
error_lineno=339,
format=0x18 , args=0x7fff625436c8) at 
/build/buildd/php5-5.4.11/main/main.c:944
#4  0x7fab61054710 in soap_error_handler (error_num=1447055232, 
error_filename=0x20 , error_lineno=32683,
format=0x7fff62543be8 "\020", args=0x7fff62543de0) at 
/build/buildd/php5-5.4.11/ext/soap/soap.c:2171
#5  0x7fab611993ec in zend_error (type=1, format=0x7fab6157c5b0 "Cannot 
declare self-referencing constant '%s'")
at /build/buildd/php5-5.4.11/Zend/zend.c:1118
#6  0x7fab6118a896 in zval_update_constant_ex (pp=0x7fab67731270, 
arg=0xffbd1ad6, scope=0x0)
at /build/buildd/php5-5.4.11/Zend/zend_execute_API.c:502
#7  0x7fab611a6d6a in zend_hash_apply_with_argument (ht=0x7fab67730b40, 
apply_func=0x7fab6118ad10 , argument=0x0)
at /build/buildd/php5-5.4.11/Zend/zend_hash.c:740
#8  0x7fab6118a732 in zval_update_constant_ex (pp=0x7fab67732918, 
arg=0xffbd1ad6, scope=0x0)
at /build/buildd/php5-5.4.11/Zend/zend_execute_API.c:683
#9  0x7fab6119bd8a in zend_update_class_constants 
(class_type=0x7fab67730f20) at /build/buildd/php5-5.4.11/Zend/zend_API.c:1037
#10 0x7fab6119c02d in _object_and_properties_init (arg=0x7fab67730910, 
class_type=0x7fab67730f20, properties=0x0)
at /build/buildd/php5-5.4.11/Zend/zend_API.c:1124
#11 0x7fab611ff7d9 in ZEND_NEW_SPEC_HANDLER (execute_data=0x7fab6697a480) 
at /build/buildd/php5-5.4.11/Zend/zend_vm_execute.h:813
#12 0x7fab611fa49f in execute (op_array=0x7fab67734dc8) at 
/build/buildd/php5-5.4.11/Zend/zend_vm_execute.h:410
#13 0x7fab6119a208 in zend_execute_scripts (type=1178393146, retval=0x3, 
file_count=2049551044) at /build/buildd/php5-5.4.11/Zend/zend.c:1315
#14 0x7fab611397e3 in php_execute_script (primary_file=0x0) at 
/build/buildd/php5-5.4.11/main/main.c:2492
#15 0x7fab6124293d in php_handler (r=0x7fab6124293d) at 
/build/buildd/php5-5.4.11/sapi/apache2handler/sapi_apache2.c:682
#16 0x7fab66527508 in ap_run_handler ()
#17 0x7fab6652797e in ap_invoke_handler ()
#18 0x7fab66536bdc in ap_internal_redirect ()
#19 0x7fab5f45d5e5 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so
#20 0x7fab66527508 in ap_run_handler ()
#21 0x7fab6652797e in ap_invoke_handler ()
#22 0x7fab66537570 in ap_process_request ()
#23 0x7fab66534398 in ?? ()

Bug #64969 [Opn->Asn]: Failure crosscompiling with fpm for ARM

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64969&edit=1

 ID: 64969
 Updated by: fel...@php.net
 Reported by:hardware at fabatsa dot com dot mx
 Summary:Failure crosscompiling with fpm for ARM
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:Compile Failure
 Operating System:   Ubuntu 11.04
 PHP Version:5.4.15
-Assigned To:
+Assigned To:fat
 Block user comment: N
 Private report: N



Previous Comments:

[2013-06-04 13:28:07] hardware at fabatsa dot com dot mx

Description:

I've tryed to congigure and compile PHP in order to use fpm, since I have a 
Monkey Web server that Works with fastcgi.

During the make commmand I got a message "Unsupported processor, please open a 
bug report".

I have already crooscompiled libxml2.

Test script:
---
./configure --host=arm-unknown-linux-gnueabi 
--prefix=/home/user/php-5-4-15Installer --enable-fpm --enable-libxml 
--with-libxml-dir=/home/user/opt/crosstool/gcc-4.2.3-glibc-2.7/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi
 --with-sqlite3 --disable-all 

make


make install

Expected result:

I want to have a crosscompiled version of PHP that Works with my already 
crosscompiled Monkey Web server

Actual result:
--
user@ubuntu:~/php-5.4.15$ make
/bin/bash /home/user/php-5.4.15/libtool --silent --preserve-dup-deps 
--mode=compile arm-unknown-linux-gnueabi-gcc  -Iext/standard/ 
-I/home/user/php-5.4.15/ext/standard/ -DPHP_ATOM_INC 
-I/home/user/php-5.4.15/include -I/home/user/php-5.4.15/main 
-I/home/user/php-5.4.15 -I/home/user/php-5.4.15/ext/date/lib 
-I/home/user/php-5.4.15/ext/ereg/regex 
-I/home/user/lixml2Installer/include/libxml2 -I/home/user/php-5.4.15/TSRM 
-I/home/user/php-5.4.15/Zend-g -O2 -fvisibility=hidden  -c 
/home/user/php-5.4.15/ext/standard/info.c -o ext/standard/info.lo 
/bin/bash /home/user/php-5.4.15/libtool --silent --preserve-dup-deps 
--mode=compile arm-unknown-linux-gnueabi-gcc  -Imain/ 
-I/home/user/php-5.4.15/main/ -DPHP_ATOM_INC -I/home/user/php-5.4.15/include 
-I/home/user/php-5.4.15/main -I/home/user/php-5.4.15 
-I/home/user/php-5.4.15/ext/date/lib -I/home/user/php-5.4.15/ext/ereg/regex 
-I/home/user/lixml2Installer/include/libxml2 -I/home/user/php-5.4.15/TSRM 
-I/home/user/php-5.4.15/Zend-g -O2 -fvisibility=hidden  -c 
main/internal_functions_cli.c -o main/internal_functions_cli.lo 
/bin/bash /home/user/php-5.4.15/libtool --silent --preserve-dup-deps 
--mode=link arm-unknown-linux-gnueabi-gcc -export-dynamic -g -O2 
-fvisibility=hidden  -L/home/user/lixml2Installer/lib  -R 
/home/user/lixml2Installer/lib ext/date/php_date.lo ext/date/lib/astro.lo 
ext/date/lib/dow.lo ext/date/lib/parse_date.lo ext/date/lib/parse_tz.lo 
ext/date/lib/timelib.lo ext/date/lib/tm2unixtime.lo ext/date/lib/unixtime2tm.lo 
ext/date/lib/parse_iso_intervals.lo ext/date/lib/interval.lo ext/ereg/ereg.lo 
ext/ereg/regex/regcomp.lo ext/ereg/regex/regexec.lo ext/ereg/regex/regerror.lo 
ext/ereg/regex/regfree.lo ext/libxml/libxml.lo 
ext/pcre/pcrelib/pcre_chartables.lo ext/pcre/pcrelib/pcre_ucd.lo 
ext/pcre/pcrelib/pcre_compile.lo ext/pcre/pcrelib/pcre_config.lo 
ext/pcre/pcrelib/pcre_exec.lo ext/pcre/pcrelib/pcre_fullinfo.lo 
ext/pcre/pcrelib/pcre_get.lo ext/pcre/pcrelib/pcre_globals.lo 
ext/pcre/pcrelib/pcre_maketables.lo ext/pcre/pcrelib/pcre_newline.lo 
ext/pcre/pcrelib/pcre_ord2utf8.lo ext/pcre/pcrelib/pcre_refcount.lo 
ext/pcre/pcrelib/pcre_study.lo ext/pcre/pcrelib/pcre_tables.lo 
ext/pcre/pcrelib/pcre_valid_utf8.lo ext/pcre/pcrelib/pcre_version.lo 
ext/pcre/pcrelib/pcre_xclass.lo ext/pcre/php_pcre.lo ext/sqlite3/sqlite3.lo 
ext/sqlite3/libsqlite/sqlite3.lo ext/reflection/php_reflection.lo 
ext/spl/php_spl.lo ext/spl/spl_functions.lo ext/spl/spl_engine.lo 
ext/spl/spl_iterators.lo ext/spl/spl_array.lo ext/spl/spl_directory.lo 
ext/spl/spl_exceptions.lo ext/spl/spl_observer.lo ext/spl/spl_dllist.lo 
ext/spl/spl_heap.lo ext/spl/spl_fixedarray.lo ext/standard/crypt_freesec.lo 
ext/standard/crypt_blowfish.lo ext/standard/crypt_sha512.lo 
ext/standard/crypt_sha256.lo ext/standard/php_crypt_r.lo ext/standard/array.lo 
ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo 
ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo 
ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo 
ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo 
ext/standard/filestat.lo ext/standard/flock_compat.lo 
ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo 
ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo 
ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo 
ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo 
ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo 
ext/standard/pageinfo.lo e

Bug #64592 [Opn->Asn]: ReflectionClass::getMethods() returns methods out of scope

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64592&edit=1

 ID: 64592
 Updated by: fel...@php.net
 Reported by:benjamin dot morel at gmail dot com
 Summary:ReflectionClass::getMethods() returns methods out of
 scope
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:Reflection related
 Operating System:   Linux
 PHP Version:5.4.13
-Assigned To:
+Assigned To:johannes
 Block user comment: N
 Private report: N

 New Comment:

Hey Johannes, what do you think about this behavior? Since reflection has 
worked in this way for a long time...


Previous Comments:

[2013-04-06 16:25:28] benjamin dot morel at gmail dot com

@felipe, did you read the bug before closing it? We're not talking about "not 
accessible", but "not in scope".
This is totally different.

The fact is, if you run my example, getMethods() and getProperties() do not 
behave 
in the same way, thus either this is a bug in getMethods(), and if not, this is 
a 
bug in getProperties().

But I'm pretty sure it's getProperties() that behaves correctly here.
Could you please comment on this?


[2013-04-06 15:27:46] fel...@php.net

It is not intended to just show the accessible ones, hence we already have 
introduced method like ReflectionMethod::setAccessible().


[2013-04-06 15:11:19] benjamin dot morel at gmail dot com

Works like a charm with your patch, thanks!
Any chance that gets into 5.4, or at least 5.5 (if there is a fear of breaking 
BC 
with existing libraries that would rely on this behaviour)?


[2013-04-06 13:19:41] larue...@php.net

The following patch has been added/updated:

Patch Name: bug64592.patch
Revision:   1365254381
URL:
https://bugs.php.net/patch-display.php?bug=64592&patch=bug64592.patch&revision=1365254381


[2013-04-06 11:54:57] benjamin dot morel at gmail dot com

But at least, getMethods() and getProperties() should behave in the same way, 
shouldn't they?




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=64592


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64592&edit=1

Bug #64592 [Nab->Opn]: ReflectionClass::getMethods() returns methods out of scope

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64592&edit=1

 ID: 64592
 Updated by: fel...@php.net
 Reported by:benjamin dot morel at gmail dot com
 Summary:ReflectionClass::getMethods() returns methods out of
 scope
-Status: Not a bug
+Status: Open
 Type:   Bug
 Package:Reflection related
 Operating System:   Linux
 PHP Version:5.4.13
 Block user comment: N
 Private report: N



Previous Comments:

[2013-04-06 16:25:28] benjamin dot morel at gmail dot com

@felipe, did you read the bug before closing it? We're not talking about "not 
accessible", but "not in scope".
This is totally different.

The fact is, if you run my example, getMethods() and getProperties() do not 
behave 
in the same way, thus either this is a bug in getMethods(), and if not, this is 
a 
bug in getProperties().

But I'm pretty sure it's getProperties() that behaves correctly here.
Could you please comment on this?


[2013-04-06 15:27:46] fel...@php.net

It is not intended to just show the accessible ones, hence we already have 
introduced method like ReflectionMethod::setAccessible().


[2013-04-06 15:11:19] benjamin dot morel at gmail dot com

Works like a charm with your patch, thanks!
Any chance that gets into 5.4, or at least 5.5 (if there is a fear of breaking 
BC 
with existing libraries that would rely on this behaviour)?


[2013-04-06 13:19:41] larue...@php.net

The following patch has been added/updated:

Patch Name: bug64592.patch
Revision:   1365254381
URL:
https://bugs.php.net/patch-display.php?bug=64592&patch=bug64592.patch&revision=1365254381


[2013-04-06 11:54:57] benjamin dot morel at gmail dot com

But at least, getMethods() and getProperties() should behave in the same way, 
shouldn't they?




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=64592


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64592&edit=1

Bug #64527 [Opn->Asn]: Add cli.pager and cli.prompt to php.ini-*

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64527&edit=1

 ID: 64527
 Updated by: fel...@php.net
 Reported by:s...@php.net
 Summary:Add cli.pager and cli.prompt to php.ini-*
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:CGI/CLI related
 PHP Version:5.5.0beta1
-Assigned To:
+Assigned To:johannes
 Block user comment: N
 Private report: N



Previous Comments:

[2013-03-26 20:54:40] s...@php.net

Description:

The cli.pager and cli.prompt parameters are missing from php.ini-*.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64527&edit=1

Bug #64589 [Opn->Asn]: SOAP arrays with non-sequentially indexed keys ignored

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64589&edit=1

 ID: 64589
 Updated by: fel...@php.net
 Reported by:cwei...@php.net
 Summary:SOAP arrays with non-sequentially indexed keys
 ignored
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:SOAP related
 Operating System:   Linux
 PHP Version:5.5.0beta1
-Assigned To:
+Assigned To:dmitry
 Block user comment: N
 Private report: N



Previous Comments:

[2013-04-05 09:32:11] cwei...@php.net

Description:

When passing a non-sequentially numerically indexed array to a SOAPClient 
method, it gets ignored as "empty".

Test script:
---
http://p.cweiske.de/35

Expected result:


 foo
 foo2



Actual result:
--








-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64589&edit=1

Bug #64571 [Opn->Nab]: PDO CREATE TRIGGER

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64571&edit=1

 ID: 64571
 Updated by: fel...@php.net
 Reported by:jehoshua02 at gmail dot com
 Summary:PDO CREATE TRIGGER
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:PDO related
 Operating System:   Ubuntu 12.10 Desktop 64bit
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

DELIMITER is not a mysql statement, but a mysql client command.

Use a separated statement for create trigger part. e.g. $pdo->query("CREATE 
TRIGGER ...");


Previous Comments:

[2013-04-03 00:28:44] jehoshua02 at gmail dot com

Could the root of this problem be somehow related to the multiple-query problem?


[2013-04-03 00:09:02] jehoshua02 at gmail dot com

Description:

I'm using PDO in some simple script to do database migrations and realized that 
my triggers weren't being created. I checked to make sure the triggers were 
correct by first copying and pasting them into mysql interactive console, then 
by using `SOURCE ...`, then by passing the file name into mysql command, each 
time verifying the trigger was created by using "SHOW TRIGGERS WHERE `Trigger` 
= :trigger". I concluded that the problem was not with my trigger statements, 
or with mysql, but with PDO.

The actual PHP version is 5.4.6-1ubuntu1.2 so I chose the closest one.

Test script:
---
https://gist.github.com/jehoshua02/5297332

Expected result:

I would expect to see the trigger printed as an associative array.

Actual result:
--
The trigger is not created even though the script completes without any errors 
or exceptions.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64571&edit=1

Bug #64576 [Opn->Nab]: stream_notification_callback doesn't seem to work

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64576&edit=1

 ID: 64576
 Updated by: fel...@php.net
 Reported by:zelnaga at gmail dot com
 Summary:stream_notification_callback doesn't seem to work
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Streams related
 Operating System:   Windows 7
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

You have called stream_context_set_option() instead of 
stream_context_set_params().


Previous Comments:

[2013-04-03 13:12:49] zelnaga at gmail dot com

Description:

http://www.php.net/manual/en/function.stream-notification-callback.php

Per that I'd wouldn't expect the following test scripts to produce errors but 
they 
do.

Test script:
---
 'callback'));
?>

 'callback'));
?>

Expected result:

(blank)

Actual result:
--
Warning: stream_context_create(): options should have the form ["wrappername"]
["optionname"] = $value in /path/to/file.php on line 2






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64576&edit=1

Bug #64598 [Opn->Nab]: function array dereferencing not completely implemented

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64598&edit=1

 ID: 64598
 Updated by: fel...@php.net
 Reported by:php at flyingsoft dot phatcode dot net
 Summary:function array dereferencing not completely
 implemented
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Arrays related
 Operating System:   WAMP..
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

This nothing have to do with "function array dereferencing".


Previous Comments:

[2013-04-06 08:06:19] php at flyingsoft dot phatcode dot net

Description:

Function array dereferencing does not work for splFixedArray.

Test script:
---


Expected result:

No error.

Actual result:
--
"Notice: Indirect modification of overloaded element of SplFixedArray has no 
effect in [filename] on line 4"






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64598&edit=1

Bug #64592 [Opn->Nab]: ReflectionClass::getMethods() returns methods out of scope

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64592&edit=1

 ID: 64592
 Updated by: fel...@php.net
 Reported by:benjamin dot morel at gmail dot com
 Summary:ReflectionClass::getMethods() returns methods out of
 scope
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Reflection related
 Operating System:   Linux
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

It is not intended to just show the accessible ones, hence we already have 
introduced method like ReflectionMethod::setAccessible().


Previous Comments:

[2013-04-06 15:11:19] benjamin dot morel at gmail dot com

Works like a charm with your patch, thanks!
Any chance that gets into 5.4, or at least 5.5 (if there is a fear of breaking 
BC 
with existing libraries that would rely on this behaviour)?


[2013-04-06 13:19:41] larue...@php.net

The following patch has been added/updated:

Patch Name: bug64592.patch
Revision:   1365254381
URL:
https://bugs.php.net/patch-display.php?bug=64592&patch=bug64592.patch&revision=1365254381


[2013-04-06 11:54:57] benjamin dot morel at gmail dot com

But at least, getMethods() and getProperties() should behave in the same way, 
shouldn't they?


[2013-04-06 02:08:02] larue...@php.net

for php, even the private inherited function is not "visible", but it exists in 
the child function table.


[2013-04-05 16:14:30] benjamin dot morel at gmail dot com

Description:

As far as I understand it, ReflectionClass::getMethods() should return only the 
methods that are in the scope of the reflected class, thus excluding private 
methods from parent classes.

That's moreover the behaviour exposed by ReflectionClass::getProperties(), 
making 
the two methods behave in different manners.

Test script:
---
class Foo {
private $a;
private function a() {}

protected $b;
protected function b() {}
}
class Bar extends Foo {
private $c;
private function c() {}
}

$r = new ReflectionClass('Bar');

echo 'Properties in scope: ';
foreach ($r->getProperties() as $property) {
echo $property->getName() . ' ';
}

echo PHP_EOL, 'Methods in scope: ';
foreach ($r->getMethods() as $method) {
echo $method->getName() . ' ';
}

Expected result:

Properties in scope: c b 
Methods in scope: c b 

Actual result:
--
Properties in scope: c b 
Methods in scope: c a b 






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64592&edit=1

Bug #64094 [Nab]: preg_match crashes php

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64094&edit=1

 ID: 64094
 Updated by: fel...@php.net
 Reported by:george at polarismail dot com
 Summary:preg_match crashes php
 Status: Not a bug
 Type:   Bug
 Package:PCRE related
 Operating System:   FreeBSD 8.0
 PHP Version:5.4.11
 Block user comment: N
 Private report: N

 New Comment:

When no crash happens, check the preg_last_error() return for understanding 
what is happening. Any way, this is a PCRE library issue.

Thanks.


Previous Comments:

[2013-02-01 21:38:18] george at polarismail dot com

I forgot to mention in my original comment - and this is what you are referring 
to 
- that I tried increasing the backtrack limit and recursion limit to really 
high 
numbers without any effect. It still crashes. If I lower them to a really small 
number - like 10 or 100 - then it doesn't crash anymore but it doesn't provide 
any 
output either.


[2013-02-01 00:17:13] fel...@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.

It isn't a PHP bug, but a PCRE known issue. Check out PCRE manpage to figure 
out the issue, or use the search on our bugtracker to find similar issues.


[2013-01-29 11:09:07] george at polarismail dot com

Description:

We had this preg_match code running on PHP 5.3.6 and it was crashing so we 
updated 
to 5.4.11 and it's still crashing. We are using PCRE 8.3.2 

Test script:
---
$uidlist="40065,40066,40067,40068,40069,40070,40071,40072,40073,40074,40075,40076,40077,40078,40079,40080,40082,40081,40083,40084,40085,40086,40087,40088,40090,40089,40092,40093,40094,40095,40097,40153,40154,40155,40156,40157,40158,40159,40161,40160,40162,40163,40164,40165,40166,40167,40168,40170,40171,40172,40173,40174,40176,40178,40180,40181,40182,40183,40184,40185,40186,40187,40188,40189,40190,40191,40192,40193,40194,40195,40196,40198,40199,40200,40201,40202,40203,40204,40205,40206,40207,40209,40210,40211,40212,40213,40214,40215,40217,40218,40222,40223,40225,40226,40227,40228,40229,40230,40231,40232,40233,40234,40235,40237,40236,40238,40239,40240,40241,40242,40244,40245,40246,40247,40248,40249,40250,40251,40254,40252,40253,40255,40256,40257,40259,40260,40261,40262,40264,40265,40270,40271,40272,40273,40275,40263,40276,40277,40278,40279,40280,40281,40282,40283,40284,40285,40286,40287,40288,40289,40290,40291,40292,40293,40294,40295,40296,40297,40298,40299,40300,40301,40303,40304,40305,40306,40307,40308,40309,40310,40311,40312,40313,40314,40315,40316,40317,40318,40319,40320,40321,40324,40322,40323,40325,40326,40327,40329,40330,40331,40332,40333,40335,40334,40336,40337,40338,40339,40340,40341,40342,40345,40346,40347,40349,40350,40351,40352,40353,40355,40357,40358,40359,40360,40361,40362,40363,40364,40365,40366,40367,40369,40371,40372,40373,40379,40374,40375,40376,40377,40378,40380,40381,40382,40383,40384,40387,40388,40389,40390,40391,40392,40395,40396,40397,40398,40399,40400,40401,40402,40403,40404,40405,40406,40407,40408,40409,40410,40415,40413,40416,40414,40417,40418,40419,40420,40421,40423,40433,40425,40426,40427,40428,40429,40430,40431,40441,40434,40435,40436,40437,40438,40443,40439,40440,40447,40442,40444,40445,40446,40448,40450,40449,40451,40452,40453,40454,40456,40455,40458,40459,40460,40461,40462,40463,40464,40465,40466,40467,40468,40469,40470,40471,40472,40473,40474,40475,40476,40477,40478,40479,40480,40481,40482,40483,40484,40485,40486,40487,40488,40489,40490,40491,40492,40493,40494,40495,40496,40497,40498,40499,40500,40501,40502,40503,40504,40505,40506,40507,40508,40509,40510,40511,40512,40513,40514,40515,40516,40518,40519,40520,40521,40522,40523,40524,40525,40526,40527,40528,40529,40530,40531,40532,40533,40534,40535,40536,40537,40538,40539,40540,40541,40542,40543,40544,40545,40546,40547,40548,40549,40550,40551,40552,40553,40554,40555,40556,40557,40558,40563,40559,40560,40561,40562,40564,40565,40566,40567,40568,40569,40570,40571,40572,40573,40574,40575,40576,40577,40578,40579,40580,40581,40588,40594,40616,40626,40630,40644,40645,40646,40647,40648,40649,40650,40669,40679,40680,40681,40682,40684,40685,40691,40686,40687,40688,40690,40689,40692,40695,40696,40697,40698,40700,40702,40701,40705,40706,40707,40708,40710,40711,40716,40718,40732,40733,40734,40735,40736,40737,40738,40739,40740,40741,40742,40743,40744,40745,40746,40747,

Bug #64089 [Opn->Nab]: Posting multipart/form-data forms results in Segmentation fault

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64089&edit=1

 ID: 64089
 Updated by: fel...@php.net
 Reported by:bas at bushbaby dot nl
 Summary:Posting multipart/form-data forms results in
 Segmentation fault
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Reproducible crash
 Operating System:   OSX 10.8.2
 PHP Version:5.4.11
 Block user comment: N
 Private report: N

 New Comment:

Thanks for testing. :)


Previous Comments:

[2013-01-29 08:40:22] bas at bushbaby dot nl

Hmm, after I compiled with debug enabled, restarted apache and accessed this 
script, the crash did not occur. Once I enabled the non debug version (and 
restarted apache) it still did not occur (?). I don't know what is going on (I 
did 
not restart my computer overnight), but it seems for now I can submit multipart 
forms... I'll keep an eye on it and when it happens again I'll try to submit a 
backtrace.


[2013-01-29 03:19:06] larue...@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.




[2013-01-28 23:23:14] bas at bushbaby dot nl

Rattletrap:~ bas$ diff /opt/local/etc/php54/php.ini 
/opt/local/etc/php54/php.ini-development
405c405
< memory_limit = 256M
---
> memory_limit = 128M
672c672
< post_max_size = 50M
---
> post_max_size = 8M
705c705
< include_path = ".:/opt/local/lib/php54/share/pear"
---
> ;include_path = ".:/php/includes"
800c800
< upload_max_filesize = 50M
---
> upload_max_filesize = 2M
919c919
< date.timezone = Europe/Amsterdam
---
> ;date.timezone =
1582c1582
< session.upload_progress.enabled = On
---
> ;session.upload_progress.enabled = On
1613c1613
< session.upload_progress.freq =  "1%"
---
> ;session.upload_progress.freq =  "1%"
1620c1620
< session.upload_progress.min_freq = "1"
---
> ;session.upload_progress.min_freq = "1"
1862,1869d1861


[2013-01-28 23:21:00] bas at bushbaby dot nl

oh, I check it is PHP that crashes, by changing the extention and action to 
html. 
Then it works.


[2013-01-28 23:19:01] bas at bushbaby dot nl

Description:

'./configure' '--prefix=/opt/local' '--mandir=/opt/local/share/man' '--
infodir=/opt/local/share/info' '--program-suffix=54' '--
includedir=/opt/local/include/php54' '--libdir=/opt/local/lib/php54' '--with-
config-file-path=/opt/local/etc/php54' '--with-config-file-scan-
dir=/opt/local/var/db/php54' '--disable-all' '--enable-bcmath' '--enable-ctype' 
'-
-enable-dom' '--enable-fileinfo' '--enable-filter' '--enable-hash' 
'--enable-json' 
'--enable-libxml' '--enable-pdo' '--enable-phar' '--enable-session' '--enable-
simplexml' '--enable-tokenizer' '--enable-xml' '--enable-xmlreader' '--enable-
xmlwriter' '--with-bz2=/opt/local' '--with-mhash=/opt/local' '--with-pcre-
regex=/opt/local' '--with-libxml-dir=/opt/local' '--with-zlib=/opt/local' '--
without-pear' '--disable-cgi' '--disable-cli' '--disable-fpm' '--with-
apxs2=/opt/local/apache2/bin/apxs'

Test script:
---
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>

http://www.w3.org/1999/xhtml";>

  



  this form crashes php

  

  
  

  this form won't

  

  



Expected result:

see the form again

Actual result:
--
black screen, apache log shows segmentation fault






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64089&edit=1

Bug #64094 [Opn->Nab]: preg_match crashes php

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64094&edit=1

 ID: 64094
 Updated by: fel...@php.net
 Reported by:george at polarismail dot com
 Summary:preg_match crashes php
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:PCRE related
 Operating System:   FreeBSD 8.0
 PHP Version:5.4.11
 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.

It isn't a PHP bug, but a PCRE known issue. Check out PCRE manpage to figure 
out the issue, or use the search on our bugtracker to find similar issues.


Previous Comments:

[2013-01-29 11:09:07] george at polarismail dot com

Description:

We had this preg_match code running on PHP 5.3.6 and it was crashing so we 
updated 
to 5.4.11 and it's still crashing. We are using PCRE 8.3.2 

Test script:
---
$uidlist="40065,40066,40067,40068,40069,40070,40071,40072,40073,40074,40075,40076,40077,40078,40079,40080,40082,40081,40083,40084,40085,40086,40087,40088,40090,40089,40092,40093,40094,40095,40097,40153,40154,40155,40156,40157,40158,40159,40161,40160,40162,40163,40164,40165,40166,40167,40168,40170,40171,40172,40173,40174,40176,40178,40180,40181,40182,40183,40184,40185,40186,40187,40188,40189,40190,40191,40192,40193,40194,40195,40196,40198,40199,40200,40201,40202,40203,40204,40205,40206,40207,40209,40210,40211,40212,40213,40214,40215,40217,40218,40222,40223,40225,40226,40227,40228,40229,40230,40231,40232,40233,40234,40235,40237,40236,40238,40239,40240,40241,40242,40244,40245,40246,40247,40248,40249,40250,40251,40254,40252,40253,40255,40256,40257,40259,40260,40261,40262,40264,40265,40270,40271,40272,40273,40275,40263,40276,40277,40278,40279,40280,40281,40282,40283,40284,40285,40286,40287,40288,40289,40290,40291,40292,40293,40294,40295,40296,40297,40298,40299,40300,40301,40303,40304,40305,40306,40307,40308,40309,40310,40311,40312,40313,40314,40315,40316,40317,40318,40319,40320,40321,40324,40322,40323,40325,40326,40327,40329,40330,40331,40332,40333,40335,40334,40336,40337,40338,40339,40340,40341,40342,40345,40346,40347,40349,40350,40351,40352,40353,40355,40357,40358,40359,40360,40361,40362,40363,40364,40365,40366,40367,40369,40371,40372,40373,40379,40374,40375,40376,40377,40378,40380,40381,40382,40383,40384,40387,40388,40389,40390,40391,40392,40395,40396,40397,40398,40399,40400,40401,40402,40403,40404,40405,40406,40407,40408,40409,40410,40415,40413,40416,40414,40417,40418,40419,40420,40421,40423,40433,40425,40426,40427,40428,40429,40430,40431,40441,40434,40435,40436,40437,40438,40443,40439,40440,40447,40442,40444,40445,40446,40448,40450,40449,40451,40452,40453,40454,40456,40455,40458,40459,40460,40461,40462,40463,40464,40465,40466,40467,40468,40469,40470,40471,40472,40473,40474,40475,40476,40477,40478,40479,40480,40481,40482,40483,40484,40485,40486,40487,40488,40489,40490,40491,40492,40493,40494,40495,40496,40497,40498,40499,40500,40501,40502,40503,40504,40505,40506,40507,40508,40509,40510,40511,40512,40513,40514,40515,40516,40518,40519,40520,40521,40522,40523,40524,40525,40526,40527,40528,40529,40530,40531,40532,40533,40534,40535,40536,40537,40538,40539,40540,40541,40542,40543,40544,40545,40546,40547,40548,40549,40550,40551,40552,40553,40554,40555,40556,40557,40558,40563,40559,40560,40561,40562,40564,40565,40566,40567,40568,40569,40570,40571,40572,40573,40574,40575,40576,40577,40578,40579,40580,40581,40588,40594,40616,40626,40630,40644,40645,40646,40647,40648,40649,40650,40669,40679,40680,40681,40682,40684,40685,40691,40686,40687,40688,40690,40689,40692,40695,40696,40697,40698,40700,40702,40701,40705,40706,40707,40708,40710,40711,40716,40718,40732,40733,40734,40735,40736,40737,40738,40739,40740,40741,40742,40743,40744,40745,40746,40747,40748,40749,40750,40751,40752,40753,40754,40755,40756,40758,40762,40759,40760,40761,40763,40764,40765,40775,40776,40777,40778,40779,40780,40781,40782,40783,40784,40785,40786,40792,40794,40795,40796,40798,40799,40800,40802,40803,40804,40805,40806,40807,40808,40809,40810,40811,40812,40813,40814,40829,40821,40815,40816,40817,40818,40819,40820,40822,40823,40824,40825,40826,40827,40828,40830,40831,40833,40832,40834,40836,40835,40837,40838,40840,40841,40846,40842,40843,40844,40845,40847,40849,40853,40854,40855,40856,40857,40858,40859,40860,40861,40862,40863,40864,40865,40866,40868,40869,40870,40871,40872,40873,40874,40877,40884,40886,40889,40920,40908,40909,40910,40911,40912,40913,40914,40915,40916,4091

Bug #64119 [Opn->Nab]: Segmentation fault when calling preg_replace

[felipe]

Edit report at https://bugs.php.net/bug.php?id=64119&edit=1

 ID: 64119
 Updated by: fel...@php.net
 Reported by:vasiliy at hotger dot com
 Summary:Segmentation fault when calling preg_replace
-Status: Open
+Status: Not a bug
 Type:   Bug
-Package:Regexps related
+Package:PCRE related
 Operating System:   Linux anfa-desktop 2.6.32-38-gen
 PHP Version:5.3.21
 Block user comment: N
 Private report: N

 New Comment:

It is not a bug on PHP itself, but a known issue from lib PCRE. Check out 
previous bug reports about PCRE on our bugtrucker to figure out the issue.


Thanks.


Previous Comments:

[2013-01-31 18:24:27] vasiliy at hotger dot com

Description:

---
>From manual page: 
>http://www.php.net/function.preg-replace#refsect1-function.preg-replace-description
---

a simple call to preg_replace with valid regular expression and string 
arguments generates SEGMENTATION FAULT.

Test script:
---
).)*/s', '', 
'

Bug #63867 [Fbk]: make test core dumps on bug63377.php

[felipe]

Edit report at https://bugs.php.net/bug.php?id=63867&edit=1

 ID: 63867
 Updated by: fel...@php.net
 Reported by:mamfelt at gmail dot com
 Summary:make test core dumps on bug63377.php
 Status: Feedback
 Type:   Bug
 Package:Testing related
 Operating System:   AIX 6.1
 PHP Version:5.3.20
 Block user comment: N
 Private report: N

 New Comment:

Hi, I've fixed an issue in this test. (bug63377.phpt)

Please, apply the change manually and try again:
http://git.php.net/?p=php-src.git;a=commitdiff;h=56d9edbbb93a2a338211b2e7c05cf52347a963ce


Previous Comments:

[2012-12-28 13:43:44] mamfelt at gmail dot com

Description:

make test fails (fatal error) on test 63377 and does not continue with 
remaining tests.

AIX 6.1, two different TL levels,
one with 2G RAM and 1.5G paging space
one with 9G RAM, 512 MByte paging space

michael@x054:[/data/prj/php/php-5.3.20]ulimit -a
time(seconds)unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes)4194304
memory(kbytes)   unlimited
coredump(blocks) 0
nofiles(descriptors) 2000
threads(per process) unlimited
processes(per user)  unlimited

I am aware that AIX has a different HW memory model (10 or 11 256M Byte memory 
segments, so it may lie in the 3072M limit used in the test. However, I do not 
really see the system grab that much memory before the test crashes. I will 
assume it is hard to spot using topas/nmon.

The test is also running a loop that is allocating? and writing? 1024 x 1024 x 
100 'a' characters (or 22 x 102400k)

Some suggestions, read instructions, for:
1) setting up a situation that I can debug this test to see what is failing
2) instructions for the letting make test continue, even though this has failed.
3) instructions on how to skip this test for the time being.

Test script:
---
# ./configure ...
# make
# make test

Expected result:

that "make test" completes normally, asking to send test results, etc.

Actual result:
--
PASS ZE2 type hinting [tests/lang/type_hints_002.phpt] 
PASS ZE2 type hinting [tests/lang/type_hints_003.phpt] 
PASS Bug #46897: ob_flush() should fail to flush unerasable buffers 
[tests/output/bug46897.phpt] 
TEST 630/9330 [tests/output/bug63377.phpt]
Fatal error: Out of memory (allocated 213647360) (tried to allocate 209715545 
bytes) in /data/prj/php/php-5.3.20/run-tests.php on line 1818







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63867&edit=1

Bug #63867 [Opn->Fbk]: make test core dumps on bug63377.php

[felipe]

Edit report at https://bugs.php.net/bug.php?id=63867&edit=1

 ID: 63867
 Updated by: fel...@php.net
 Reported by:mamfelt at gmail dot com
 Summary:make test core dumps on bug63377.php
-Status: Open
+Status: Feedback
 Type:   Bug
-Package:Unknown/Other Function
+Package:Testing related
 Operating System:   AIX 6.1
 PHP Version:5.3.20
 Block user comment: N
 Private report: N

 New Comment:

Hi, I've fixed an issue in this test. (bug63377.phpt)

Please, apply the change manually and try again:
https://mail.google.com/mail/u/0/?shva=1#search/63377/13bbae260e67d914


Previous Comments:

[2012-12-28 13:43:44] mamfelt at gmail dot com

Description:

make test fails (fatal error) on test 63377 and does not continue with 
remaining tests.

AIX 6.1, two different TL levels,
one with 2G RAM and 1.5G paging space
one with 9G RAM, 512 MByte paging space

michael@x054:[/data/prj/php/php-5.3.20]ulimit -a
time(seconds)unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes)4194304
memory(kbytes)   unlimited
coredump(blocks) 0
nofiles(descriptors) 2000
threads(per process) unlimited
processes(per user)  unlimited

I am aware that AIX has a different HW memory model (10 or 11 256M Byte memory 
segments, so it may lie in the 3072M limit used in the test. However, I do not 
really see the system grab that much memory before the test crashes. I will 
assume it is hard to spot using topas/nmon.

The test is also running a loop that is allocating? and writing? 1024 x 1024 x 
100 'a' characters (or 22 x 102400k)

Some suggestions, read instructions, for:
1) setting up a situation that I can debug this test to see what is failing
2) instructions for the letting make test continue, even though this has failed.
3) instructions on how to skip this test for the time being.

Test script:
---
# ./configure ...
# make
# make test

Expected result:

that "make test" completes normally, asking to send test results, etc.

Actual result:
--
PASS ZE2 type hinting [tests/lang/type_hints_002.phpt] 
PASS ZE2 type hinting [tests/lang/type_hints_003.phpt] 
PASS Bug #46897: ob_flush() should fail to flush unerasable buffers 
[tests/output/bug46897.phpt] 
TEST 630/9330 [tests/output/bug63377.phpt]
Fatal error: Out of memory (allocated 213647360) (tried to allocate 209715545 
bytes) in /data/prj/php/php-5.3.20/run-tests.php on line 1818







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63867&edit=1

Bug #63846 [Opn->Nab]: preg_match cause segmentation fault

[felipe]

Edit report at https://bugs.php.net/bug.php?id=63846&edit=1

 ID: 63846
 Updated by: fel...@php.net
 Reported by:saprykin dot dmitry at gmail dot com
 Summary:preg_match cause segmentation fault
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:PCRE related
 PHP Version:5.4.10
 Block user comment: N
 Private report: N

 New Comment:

Related to bug #63829


Previous Comments:

[2012-12-24 10:40:07] saprykin dot dmitry at gmail dot com

Description:

simple regular expression causes segmentation fault. Details are below.

Test script:
---
$text = str_repeat('text ', 870);
echo 'Text size: '.strlen($text).PHP_EOL;
preg_match('/([a-z]\s*)+/', $text);
echo 'Working!';

Expected result:

Text size: 4350
Working!

Actual result:
--
Text size: 4350
Segmentation fault (core dumped)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63846&edit=1

Bug #53326 [Nab]: [IGNORE] Testing

[felipe]

Edit report at https://bugs.php.net/bug.php?id=53326&edit=1

 ID: 53326
 Updated by: fel...@php.net
 Reported by:felipensp at gmail dot com
 Summary:[IGNORE] Testing
 Status: Not a bug
 Type:   Bug
 Package:Unknown/Other Function
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Testing... related to bug #55087


Previous Comments:

[2011-11-18 11:17:55] fel...@php.net

.


[2011-06-30 09:08:07] fel...@php.net

test


[2011-06-30 09:05:36] fel...@php.net

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




[2011-06-30 08:53:19] fel...@php.net

test


[2011-04-21 19:27:47] felipensp at gmail dot com

test




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=53326


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=53326&edit=1

Bug #63724 [Opn->Nab]: MessageFormatter buggy when using select formats with nested parameters

[felipe]

Edit report at https://bugs.php.net/bug.php?id=63724&edit=1

 ID: 63724
 Updated by: fel...@php.net
 Reported by:eskwayrd at gmail dot com
 Summary:MessageFormatter buggy when using select formats
 with nested parameters
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:I18N and L10N related
 Operating System:   Linux
 PHP Version:5.4.9
 Block user comment: N
 Private report: N

 New Comment:

If it's really a problem, it occurred on ICU. See a related bug #62673

Using "{1, select, k {{0, number} kB} M {{0, number, #.##} MB} other {{0, 
number} B}}" does the job, somehow just like suggested in the bug I pointed out 
above.


Previous Comments:

[2012-12-07 23:11:49] eskwayrd at gmail dot com

Description:

When a message formatter formats selects with nested variables, its behaviour 
is 
buggy.

Test script:
---
// attempting to translate file size
$locale = 'en_US';
$args = array(1.23435, 'M');
$format = "{1, select, k {{0} kB} M {{0} MB} other {{0} B}}";
echo "#1: ". msgfmt_format_message($locale, $format, $args) ."\n";

$format = "{1, select, k {{0} kB} M {{0, number, #.##} MB} other {{0} B}}";
echo "#2: ". msgfmt_format_message($locale, $format, $args) ."\n";
echo "Error? ". intl_get_error_message() ."\n";

Expected result:

#1: 1.23435 MB
#2: 1.23 MB
Error? U_ZERO_ERROR


Actual result:
--
#1: 1.23435 MB
#2: 
Error? Creating message formatter failed: U_ARGUMENT_TYPE_MISMATCH






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63724&edit=1

Bug #63782 [Opn->Nab]: php.ini not loaded by php-fpm unless -c switch is used

[felipe]

Edit report at https://bugs.php.net/bug.php?id=63782&edit=1

 ID: 63782
 Updated by: fel...@php.net
 Reported by:infected817 at gmail dot com
 Summary:php.ini not loaded by php-fpm unless -c switch is
 used
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:*Configuration Issues
 Operating System:   Ubuntu Desktop 12.10
 PHP Version:5.4.9
 Block user comment: N
 Private report: N

 New Comment:

Already exists a hint which does not uses trailing slash.

"  --with-config-file-path=PATH
  Set the path in which to look for php.ini 
[PREFIX/lib]"


Previous Comments:

[2012-12-17 03:35:20] infected817 at gmail dot com

Mystery solved.

I recompiled PHP with this configuration flag: --with-config-file-path=/etc/php5

Notice that before, I used --with-config-file-path=/etc/php5/

The trailing slash seems to be causing problems.

I think it would be helpful to do the following:
- Fix PHP to accept configuration folders with or without the trailing slash.

OR

- Add a note for --with-config-file-path in ./configure --help that says the 
trailing slash should be omitted.


[2012-12-17 02:52:05] larue...@php.net

make sure that  you have did "make clean" after you re-configure


[2012-12-17 02:30:29] infected817 at gmail dot com

Clarified php.ini location.


[2012-12-16 22:28:53] infected817 at gmail dot com

Hi there,

I actually made a mistake when copying the contents of the phpinfo() output as 
I had 2 virtual machines running at the time. My apologies for that.

I just checked again and these are the results:

Ubuntu Desktop 12.10
Configuration File (php.ini) Path   /etc/php5/
Loaded Configuration File   (none) 

However, there is a valid php.ini in /etc/php5 that is not being loaded.

Is there anything else/more information I can check/provide?


[2012-12-16 10:58:27] re...@php.net

It's compiled with: /etc/php5/fpm

Configuration File (php.ini) Path   */etc/php5/[fpm]*
Loaded Configuration File   (none)

but you try to load php.ini from: /etc/php5   <-- no fpm
it's different.




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=63782


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63782&edit=1

Bug #63784 [Opn]: var_export() produces EOL symbols irregardless of target OS

[felipe]

Edit report at https://bugs.php.net/bug.php?id=63784&edit=1

 ID: 63784
 Updated by: fel...@php.net
 Reported by:hayk at mail dot ru
 Summary:var_export() produces EOL symbols irregardless of
 target OS
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows XP
 PHP Version:5.4.9
 Block user comment: N
 Private report: N

 New Comment:

Actually it is not only var_export(), var_dump() also uses hardcoded LF.


Previous Comments:

[2012-12-16 23:25:05] hayk at mail dot ru

Description:

var_export() produces EOL symbols irregardless of target OS. It's always "\n" 
even on Windows.

Test script:
---
 1);
echo var_export($a, true);
echo strlen(var_export($a, true));
?>

Expected result:

array (
  'a' => 1,
)23

Actual result:
--
array (
  'a' => 1,
)21






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63784&edit=1

Bug #63809 [Opn->Asn]: ORA-01461 when inserting/updating more that 1333 characters

[felipe]

Edit report at https://bugs.php.net/bug.php?id=63809&edit=1

 ID: 63809
 Updated by: fel...@php.net
 Reported by:blair dot chesnut at gmail dot com
 Summary:ORA-01461 when inserting/updating more that 1333
 characters
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:PDO related
 Operating System:   Unix/Solaris 10
 PHP Version:5.4.9
-Assigned To:
+Assigned To:sixd
 Block user comment: N
 Private report: N



Previous Comments:

[2012-12-19 19:42:49] blair dot chesnut at gmail dot com

Description:

Using PDO/OCI via Yii framework. Inserts/updates to varchar2(4000) column fail 
with error ORA-01461 when value exceeds 1332 characters. 

Line 300 of source php-5.4.9/ext/pdo_oci/oci_statement.c:

value_sz = 1332; /* maximum size before value is interpreted as a LONG value */

Why???  

I changed to "value_sz = 4000", recompiled, and inserts/updates work fine. I'm 
not using CLOBs, only varchar2() columns. 


Test script:
---
$dbh = new PDO($dsn, $dbuser, $dbpass);
 
$sth = $dbh->prepare('insert into some_table (some_varchar4000_column) values 
(:p1)');
 
$big_value = str_repeat('ABCDEFGHIJ', 300);
$sth->bindValue(':p1', $big_value, PDO::PARAM_STR);
 
$sth->execute();
print_r($sth->errorInfo());


Expected result:

Array
(
[0] => 0
[1] => 
[2] => 
)


Actual result:
--
Array
(
[0] => HY000
[1] => 1461
[2] => OCIStmtExecute: ORA-01461: can bind a LONG value only for insert 
into a LONG column
 (/usr/local/src/php-5.4.5/ext/pdo_oci/oci_statement.c:146)
)







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63809&edit=1

Bug #63813 [Opn->Nab]: FETCH_GROUP Does not work with FETCH_KEY_PAIR

[felipe]

Edit report at https://bugs.php.net/bug.php?id=63813&edit=1

 ID: 63813
 Updated by: fel...@php.net
 Reported by:contact at joycebabu dot com
 Summary:FETCH_GROUP Does not work with FETCH_KEY_PAIR
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:PDO related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Your query must be only "SELECT location, name FROM employees"


Previous Comments:

[2012-12-20 07:56:36] contact at joycebabu dot com

Description:

Documentation for PDO::FETCH_GROUP says

"Group return by values. Usually combined with PDO::FETCH_COLUMN or 
PDO::FETCH_KEY_PAIR."

But FETCH_GROUP does not work with FETCH_KEY_PAIR. When three columns are 
specified in the query, the fetch fails with the erorr message

"Warning: PDOStatement::fetchAll(): SQLSTATE[HY000]: General error: 
PDO::FETCH_KEY_PAIR fetch mode requires the result set to contain extactly 2 
columns."

When 2 columns are specified in the query, the fetch returns an associative 
array 
with only one value for each unique grouped key, which is useless.

Test script:
---
/*
employee table

| location | emp_id | name |

| New York |  1 | John |
| New York |  2 | Jane |
| London   |  3 | Jack |
| London   |  4 | Nick |

*/

$db->query('SELECT location, emp_id, name FROM employees');
$employees = $db->fetchAll(PDO::FETCH_GROUP | PDO::FETCH_KEY_PAIR);


Expected result:

array(
   'New York' => array(
  1 => 'John',
  2 => 'Jane'
   ),
   'London' => array(
  3 => 'Jack',
  4 => 'Nick'
   )
)


Actual result:
--
array(
'New York' => 'Jane', 
'London' => 'Nick'
)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63813&edit=1

Bug #63823 [Opn]: SPL InfiniteIterator needs explicit rewind to be usable in a closure

[felipe]

Edit report at https://bugs.php.net/bug.php?id=63823&edit=1

 ID: 63823
 Updated by: fel...@php.net
 Reported by:s...@php.net
 Summary:SPL InfiniteIterator needs explicit rewind to be
 usable in a closure
 Status: Open
 Type:   Bug
 Package:SPL related
 Operating System:   Linux
 PHP Version:5.4Git-2012-12-21 (Git)
 Block user comment: N
 Private report: N

 New Comment:

Are you referring to bug #44063?


Previous Comments:

[2012-12-21 02:35:41] larue...@php.net

I saw similar report before, and remembered someone mark it as won't fix.. I 
just 
can not find the previous report now...


[2012-12-21 02:20:57] s...@php.net

A bigger example is:
 $val) {
var_dump($val);
}

echo "\n'foreach' on InfiniteIterator\n";

$a = array('one', 'two', 'three');
$a_it = new InfiniteIterator(new ArrayIterator($a));
$i = 0;
foreach ($a_it as $key => $val) {
if ($i++ >= 7) break;
var_dump($val);
}

echo "\n'for' on ArrayIterator\n";
$d = array('one', 'two', 'three');
$d_it = new ArrayIterator($d);
for ($i = 0; $i < 3; $i++) {
var_dump($d_it->current()); 
$d_it->next();
}

echo "\n'for' on InfiniteIterator\n";

$b = array('one', 'two', 'three');
$b_it = new InfiniteIterator(new ArrayIterator($b));
for ($i = 0; $i < 7; $i++) {
var_dump($b_it->current()); 
$b_it->next();
}

?>

This outputs:
'foreach' on ArrayIterator
string(3) "one"
string(3) "two"
string(5) "three"

'foreach' on InfiniteIterator
string(3) "one"
string(3) "two"
string(5) "three"
string(3) "one"
string(3) "two"
string(5) "three"
string(3) "one"

'for' on ArrayIterator
string(3) "one"
string(3) "two"
string(5) "three"

'for' on InfiniteIterator
NULL
string(3) "two"
string(5) "three"
string(3) "one"
string(3) "two"
string(5) "three"
string(3) "one"

So the odd behavior is with the last loop.

A "real" life script (from discussion on php.internals) is:

rewind();  // why is the rewind needed?

$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements_iterator) {
$r = $replacements_iterator->current();
$replacements_iterator->next();
return $r;
},
'word word word word word'
); 

var_dump($result);

// Outputs: 
//string(21) "one two three one two"
// Without the call to $replacements_iterator->rewind(), the output is:
//string(18) " two three one two"

?>


[2012-12-21 02:17:17] s...@php.net

Description:

SPL's InfiniteIterator returns NULL for the first access, unless used in a 
'foreach' loop, or a rewind is done.

This means that an explicit rewind is needed before an InfiniteIterator can be 
safely be used in an application.

Test script:
---
current()); 
$b_it->next();
}

?>

Expected result:

string(3) "one"
string(3) "two"
string(5) "three"
string(3) "one"
string(3) "two"
string(5) "three"
string(3) "one"

Actual result:
--
NULL
string(3) "two"
string(5) "three"
string(3) "one"
string(3) "two"
string(5) "three"
string(3) "one"






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63823&edit=1

Bug #63839 [Opn->Asn]: iconv_mime_decode_headers function is skipping headers

[felipe]

Edit report at https://bugs.php.net/bug.php?id=63839&edit=1

 ID: 63839
 Updated by: fel...@php.net
 Reported by:nidhikaushal28 at gmail dot com
 Summary:iconv_mime_decode_headers function is skipping
 headers
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:ICONV related
 Operating System:   Windows 7, CentOS
 PHP Version:5.3.20
-Assigned To:
+Assigned To:aharvey
 Block user comment: N
 Private report: N



Previous Comments:

[2012-12-23 14:48:08] nidhikaushal28 at gmail dot com

Description:

iconv_mime_decode_headers function is skipping headers when '=?' is present in 
the subject. 

For example if the subject header of a mime message is : 
Subject: Reply Is? white side-LED =? in Help

Then the rest of the headers after subject like content-type, date etc are not 
returned. Similar bug is filed https://bugs.php.net/bug.php?id=52941 but in the 
above mentioned example the subject is not encoded. 

My php version is 5.3.3 and the issue is reproducible in 5.3.20 and 5.4.10. 

Test script:
---

To: 
Subject: Reply Is? white side-LED =? in Help
Date: Sat, 22 Dec 2012
Message-ID: <006f01cde00e$d9f79da0$8de6d8e0>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_NextPart_000_0070_01CDE03C.F3AFD9A0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac3gDtcH2huHjzYcQVmFJPPoWjJogA==
Content-Language: en-us

';
$headers = iconv_mime_decode_headers($headers, 
ICONV_MIME_DECODE_CONTINUE_ON_ERROR);
print_r($headers);
?>

Expected result:

Array
(
[From] => "xyz" 
[To] => 
[Subject] => Reply Is? white side-LED =? in Help
[Date] => Sat, 22 Dec 2012
[Message-ID] => <006f01cde00e$d9f79da0$8de6d8e0>
[MIME-Version] => 1.0
[Content-Type] => multipart/alternative; boundary="=_NextPart_000_0070_0
1CDE03C.F3AFD9A0"
[X-Mailer] => Microsoft Office Outlook 12.0
[Thread-Index] => Ac3gDtcH2huHjzYcQVmFJPPoWjJogA==
[Content-Language] => en-us
)

Actual result:
--
Array
(
[From] => "xyz" 
[To] => 
[Subject] => Reply Is? white side-LED
)







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63839&edit=1

Bug #63840 [Opn->Nab]: preg_peplace crash

[felipe]

Edit report at https://bugs.php.net/bug.php?id=63840&edit=1

 ID: 63840
 Updated by: fel...@php.net
 Reported by:DuMOHsmol at yandex dot ru
 Summary:preg_peplace crash
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:*Regular Expressions
 Operating System:   Windows
 PHP Version:5.3Git-2012-12-23 (snap)
 Block user comment: N
 Private report: N

 New Comment:

See bug #63829


Previous Comments:

[2012-12-23 16:19:04] DuMOHsmol at yandex dot ru

Description:

Hello, this code crashes Apache with PHP on Windows. I know that this regex is 
not quite correct, but still.

The solution is to increase Apache stack, but I think there should be some 
check in PHP to prevent crashing.

Test script:
---
$text = '
test_test_test_test_test_test_test_test_test_test_test_test_test_test_test
test_test_test_test_test_test_test_test_test_test_test_test_test_test_test
test_test_test_test_test_test_test_test_test_test_test_test_test_test_test
test_test_test_test_test_test_test_test_test_test_test_test_test_test_test
test_test_test_test_test_test_test_test_test_test_test_test_test_test_test
test_test_test_test_test_test_test_test_test_test_test_test_test_test_test
test_test_test_test_test_test_test_test_test_test_test_test_test_test_test
test_test_test_test_test_test_test_test_test_test_test_test_test_test_test
test_test_test_test_test_test_test_test_test_test_test_test_test_test_test
';

$text = preg_replace('/([\n]|.)*/','test',$text);

echo $text;







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63840&edit=1

Bug #63829 [Opn->Nab]: Apache stack overflow on PCRE subpatterns

[felipe]

Edit report at https://bugs.php.net/bug.php?id=63829&edit=1

 ID: 63829
 Updated by: fel...@php.net
 Reported by:a...@php.net
 Summary:Apache stack overflow on PCRE subpatterns
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:PCRE related
 Operating System:   Windows
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

This has been already discussed: 
http://marc.info/?l=php-internals&m=121811425119001


Previous Comments:

[2012-12-21 16:28:56] a...@php.net

It seems to me more like strictly related apache+pcre under windows issue, as i 
read here http://lxr.php.net/xref/PHP_5_4/ext/pcre/pcrelib/pcre_exec.c#232 . 
CLI isn't affected by this. After defining

#define NO_RECURSE 1

in pcrelib/config.h the issue disappears. The phpt tests pass. I'm not sure 
whether this would cause a big performance penalty, this should be tested.


[2012-12-21 16:18:29] a...@php.net

Description:

Running the test ext/pcre/tests/bug47662.phpt under Apache 2.2 or 2.4 causes 
the CRT error with the following message:

Unhandled exception at 0x01E3FC19 (php5ts_debug.dll) in httpd.exe: 0xC0FD: 
Stack overflow (parameters: 0x0001, 0x03CE2948).

This error seems to have been existed for a very long time. It happens not only 
with the pcre ext lately upgraded to 8.31, but also with previous version using 
PCRE 8.12 . It also happens in both release and debug builds. Here is the 
backtrace delivered by VS

... a lot of match(...) calls .
php5ts_debug.dll!match(const unsigned char * eptr, const unsigned char 
* ecode, const unsigned char * mstart, int offset_top, match_data * md, 
eptrblock * eptrb, unsigned int rdepth) Line 956 C
php5ts_debug.dll!match(const unsigned char * eptr, const unsigned char 
* ecode, const unsigned char * mstart, int offset_top, match_data * md, 
eptrblock * eptrb, unsigned int rdepth) Line 956 C
php5ts_debug.dll!match(const unsigned char * eptr, const unsigned char 
* ecode, const unsigned char * mstart, int offset_top, match_data * md, 
eptrblock * eptrb, unsigned int rdepth) Line 956 C
php5ts_debug.dll!match(const unsigned char * eptr, const unsigned char 
* ecode, const unsigned char * mstart, int offset_top, match_data * md, 
eptrblock * eptrb, unsigned int rdepth) Line 956 C
php5ts_debug.dll!match(const unsigned char * eptr, const unsigned char 
* ecode, const unsigned char * mstart, int offset_top, match_data * md, 
eptrblock * eptrb, unsigned int rdepth) Line 956 C
php5ts_debug.dll!php_pcre_exec(const real_pcre * argument_re, const 
pcre_extra * extra_data, const char * subject, int length, int start_offset, 
int options, int * offsets, int offsetcount) Line 6917 C
php5ts_debug.dll!php_pcre_match_impl(pcre_cache_entry * pce, char * 
subject, int subject_len, _zval_struct * return_value, _zval_struct * subpats, 
int global, int use_flags, long flags, long start_offset, void * * * tsrm_ls) 
Line 653   C
php5ts_debug.dll!php_do_pcre_match(int ht, _zval_struct * return_value, 
_zval_struct * * return_value_ptr, _zval_struct * this_ptr, int 
return_value_used, void * * * tsrm_ls, int global) Line 547 C
php5ts_debug.dll!zif_preg_match(int ht, _zval_struct * return_value, 
_zval_struct * * return_value_ptr, _zval_struct * this_ptr, int 
return_value_used, void * * * tsrm_ls) Line 798C
php5ts_debug.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * 
execute_data, void * * * tsrm_ls) Line 642   C
php5ts_debug.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data * 
execute_data, void * * * tsrm_ls) Line 2236  C
php5ts_debug.dll!execute(_zend_op_array * op_array, void * * * tsrm_ls) 
Line 410C
php5ts_debug.dll!zend_execute_scripts(int type, void * * * tsrm_ls, 
_zval_struct * * retval, int file_count, ...) Line 1309 C
php5ts_debug.dll!php_execute_script(_zend_file_handle * primary_file, 
void * * * tsrm_ls) Line 2482 C
php5apache2_2.dll!php_handler(request_rec * r) Line 667 C


Test script:
---
$regex = '@';
for($bar=0; $bar<4027; $bar++) {
$regex .= '((?P))';
}
$regex .= 'fo+bar@';

var_dump(preg_match($regex, 'foobar', $m));

Expected result:

int(1)

Actual result:
--
An exception is thrown.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63829&edit=1

Bug #63831 [Opn->Nab]: Specific 4G/4096M/4194304K memory_limit Fatal Error

[felipe]

Edit report at https://bugs.php.net/bug.php?id=63831&edit=1

 ID: 63831
 Updated by: fel...@php.net
 Reported by:scott at schrecktech dot com
 Summary:Specific 4G/4096M/4194304K memory_limit Fatal Error
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:*Configuration Issues
 Operating System:   Multiple
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Please, take a look at bug #54201.


Previous Comments:

[2012-12-21 20:24:36] scott at schrecktech dot com

Description:

---
>From manual page: http://www.php.net/ini.core
---

PHP will not run with a 4G, 4096M or 4194304K

PHP Fatal error:  Allowed memory size of 262144 bytes exhausted (tried to 
allocate 
523800 bytes) in Unknown on line 0


Test script:
---
Change the memory_limit from the byte value to the "K", "M" or "G" version of 
4Gb to see fatal error.

EXAMPLE:

; works:
memory_limit = 4294967296

; fails:
;memory_limit = 4G
;memory_limit = 4096M
;memory_limit = 4194304K

Expected result:

One should be able to set the memory_limit with the "G", "M" and "K" versions 
of 
4Gb.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63831&edit=1