date:20130805

Bug #65391 [Ver]: Unable to send vary header user-agent when ob_start('ob_gzhandler') is called

2013-08-05 Thread nikcomestotalk at gmail dot com

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

 ID: 65391
 User updated by:nikcomestotalk at gmail dot com
 Reported by:nikcomestotalk at gmail dot com
 Summary:Unable to send vary header user-agent when
 ob_start('ob_gzhandler') is called
 Status: Verified
 Type:   Bug
 Package:Output Control
 Operating System:   any
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

Not yet fixed, still getting "Vary: Accept-Encoding" only


But working fine on version 5.3.2 and 5.2[Checked on my other server having 
this 
version on php]


Previous Comments:

[2013-08-06 05:26:45] yohg...@php.net

[yohgaki@dev PHP-5.4]$ ./sapi/cgi/php-cgi 
https://bugs.php.net/bug.php?id=65391&edit=1

[PHP-BUG] Bug #65398 [NEW]: Race condition between SIGCHLD and child stdout/stderr event leads to segfault

2013-08-05 Thread gonzalo dot paniagua at acquia dot com

From: gonzalo dot paniagua at acquia dot com
Operating system: Linux
PHP version:  5.5.1
Package:  FPM related
Bug Type: Bug
Bug description:Race condition between SIGCHLD and child stdout/stderr event 
leads to segfault

Description:

This problem affects 5.3.27, 5.4.17, 5.5.1.

The master fpm process dies with a SIGSEGV. Relevant configuration options
that 
we have set is "catch_workers_output = yes" and pm on_demand.

What follows is a stack trace, the strace output, and an explanation of the

events that lead to the segfault.

StaThread 1 (Thread 0x7ff47eed4720 (LWP 15282)):
#0  0x7ff479fe5cc6 in fork () from /lib/libc.so.6
#1  0x00870c05 in fpm_children_make (wp=0x1d746d0,
in_event_loop=, nb_to_spawn=, is_debug=0)
at /usr/local/src/php-5.3.26/sapi/fpm/fpm/fpm_children.c:400
#2  0x0087125c in fpm_children_bury () at /usr/local/src/php-
5.3.26/sapi/fpm/fpm/fpm_children.c:288
#3  0x00875942 in fpm_got_signal (ev=,
which=, arg=)
at /usr/local/src/php-5.3.26/sapi/fpm/fpm/fpm_events.c:73
#4  0x00880833 in fpm_event_epoll_wait (queue=, 
timeout=) at /usr/local/src/php-
5.3.26/sapi/fpm/fpm/events/epoll.c:143
#5  0x008755d7 in fpm_event_loop (err=0) at /usr/local/src/php-
5.3.26/sapi/fpm/fpm/fpm_events.c:403
#6  0x008708c7 in fpm_run (max_requests=0x7fffafba0acc) at 
/usr/local/src/php-5.3.26/sapi/fpm/fpm/fpm.c:113
#7  0x00877dec in main (argc=5, argv=0x7fffafba2c38) at 
/usr/local/src/php-5.3.26/sapi/fpm/fpm/fpm_main.c:1842ck trace:

Strace output:
[pid 25742] <... clock_gettime resumed> {4285884, 268457129}) = 0
[pid 25742] --- SIGCHLD (Child exited) @ 0 (0) ---
[pid 25742] write(33, "C", 1)   = 1
[pid 25742] rt_sigreturn(0) = 0
[pid 25742] --- SIGCHLD (Child exited) @ 0 (0) ---
[pid 25742] write(33, "C", 1)   = 1
[pid 25742] rt_sigreturn(0) = 0
[pid 25742] epoll_wait(86, {{EPOLLHUP, {u32=24867480, u64=24867480}},
{EPOLLHUP, 
{u32=24867552, u64=24867552}}, {EPOLLIN, {u32=17325088, u64=17325088}}, 
{EPOLLHUP, {u32=24866200, u64=24866200}}, {EPOLLHUP, {u32=24866272, 
u64=24866272}}}, 261, 1001) = 5
[pid 25742] read(87, "", 1023)  = 0
[pid 25742] epoll_ctl(86, EPOLL_CTL_DEL, 87, {EPOLLIN, {u32=24867480, 
u64=24867480}}) = 0
[pid 25742] close(87)   = 0
[pid 25742] read(90, "", 1023)  = 0
[pid 25742] epoll_ctl(86, EPOLL_CTL_DEL, 90, {EPOLLIN, {u32=24867552, 
u64=24867552}}) = 0
[pid 25742] close(90)   = 0
[pid 25742] read(31, "C", 1)= 1
[pid 25742] wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}],
WNOHANG|WSTOPPED, 
NULL) = 26809
[pid 25742] clock_gettime(CLOCK_MONOTONIC, {4285884, 268457129}) = 0
[pid 25742] wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}],
WNOHANG|WSTOPPED, 
NULL) = 26813
[pid 25742] clock_gettime(CLOCK_MONOTONIC, {4285884, 268457129}) = 0
[pid 25742] read(89, "", 1023)  = 0
[pid 25742] epoll_ctl(86, EPOLL_CTL_DEL, 89, {EPOLLIN, {u32=24866200, 
u64=24866200}}) = 0
[pid 25742] close(89)   = 0
[pid 25742] read(92, "", 1023)  = 0
[pid 25742] epoll_ctl(86, EPOLL_CTL_DEL, 92, {EPOLLIN, {u32=24866272, 
u64=24866272}}) = 0
[pid 25742] close(92)   = 0
[pid 25742] wait4(-1, 0x7fffc66ba82c, WNOHANG|WSTOPPED, NULL) = 0
[pid 25742] read(31, "C", 1)= 1
[pid 25742] wait4(-1, 0x7fffc66ba82c, WNOHANG|WSTOPPED, NULL) = 0
[pid 25742] read(31, 0x7fffc66ba90f, 1) = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 25742] read(89, 0x7fffc66ba490, 1023) = -1 EBADF (Bad file
descriptor)
[pid 25742] gettimeofday({1375385643, 703965}, NULL) = 0
[pid 25742] open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo",
O_RDONLY) 
= -1 ENOENT (No such file or directory)
[pid 25742] open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo",
O_RDONLY) = 
-1 ENOENT (No such file or directory)
[pid 25742] open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) =
-1 
ENOENT (No such file or directory)
[pid 25742] open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo",
O_RDONLY) = 
-1 ENOENT (No such file or directory)
[pid 25742] open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY)
= -1 
ENOENT (No such file or directory)
[pid 25742] open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1

ENOENT (No such file or directory)
[pid 25742]
open("/usr/share/locale-langpack/en_US.UTF-8/LC_MESSAGES/libc.mo", 
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 25742]
open("/usr/share/locale-langpack/en_US.utf8/LC_MESSAGES/libc.mo", 
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 25742] open("/usr/share/locale-langpack/en_US/LC_MESSAGES/libc.mo", 
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 25742] open("/usr/share/locale-langpack/en.UTF-8/LC_MESSAGES/libc.mo",

O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 25742] open("/usr/share/locale-langpack/en.utf8/LC_MESSAGES/libc.mo",

O_RDONLY) = -1 ENOENT (No such file or di

Req #48016 [Opn->Csd]: stdClass::__setState is not defined although var_export() uses it

2013-08-05 Thread yohgaki

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

 ID: 48016
 Updated by: yohg...@php.net
 Reported by:c dot r1 at gmx dot de
 Summary:stdClass::__setState is not defined although
 var_export() uses it
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:Class/Object related
 Operating System:   Linux
 PHP Version:5.3
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

It seems issue is fixed.

[yohgaki@dev PHP-5.4]$ ./php-bin -a
Interactive shell

php > $o = new stdClass;
php > var_export($o);
stdClass::__set_state(array(
))php > $o->foo = 123;
php > $o->bar = 456;
php > var_export($o);
stdClass::__set_state(array(
   'foo' => 123,
   'bar' => 456,
))php >


Previous Comments:

[2009-04-19 12:51:05] c dot r1 at gmx dot de

Description:

var_export() for an object which is just used for storing properties and is of 
stdClass produces invalid code as stdClass::__setState is not implemented, for 
no appearant reason. It would be nice to have an implementation of this in 
5.3.0, and, if possible, a workaround for earlier versions of php.







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

Bug #65367 [ReO]: Segmentation fault when mixing =& and =

2013-08-05 Thread mbeccati

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

 ID: 65367
 Updated by: mbecc...@php.net
 Reported by:mbecc...@php.net
 Summary:Segmentation fault when mixing =& and =
 Status: Re-Opened
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Any
 PHP Version:5.5.1
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

Yes, I've used a fresh git clone.


Previous Comments:

[2013-08-06 03:02:53] larue...@php.net

did you built it frome a fresh work dir?


[2013-08-05 14:50:51] mbecc...@php.net

I have upgraded PHP 5.4 to latest-git on a new machine. With the patch applied 
I now see many test runs consistently fail with a segafult. Reverting to 5.4.17 
fixes the segfault.

Backtrace is:

#0  0x009beb33 in zend_std_object_get_class (object=0x7fffef535cd0) at 
/root/compile/php-src/Zend/zend_object_handlers.c:1500
zobj = 0x7fff0021
#1  0x0098dd98 in zend_get_class_entry (zobject=0x7fffef535cd0) at 
/root/compile/php-src/Zend/zend_API.c:238
No locals.
#2  0x00a17121 in ZEND_INIT_METHOD_CALL_SPEC_CV_CONST_HANDLER 
(execute_data=0x77fa1ea0)
at /root/compile/php-src/Zend/zend_vm_execute.h:29282
opline = 0x70a34228
function_name = 0x70a35058
function_name_strval = 0x77f97d50 "setFileNameProtection"
function_name_strlen = 21
#3  0x009c6513 in execute (op_array=0x1446f00) at 
/root/compile/php-src/Zend/zend_vm_execute.h:410
ret = 0
execute_data = 0x77fa1ea0
nested = 1 '\001'
original_in_execution = 0 '\000'
#4  0x0098ca9f in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /root/compile/php-src/Zend/zend.c:1315
files = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 
0x7fffae40, reg_save_area = 0x7fffad80}}
i = 1
file_handle = 0x7fffd1e0
orig_op_array = 0x0
orig_retval_ptr_ptr = 0x0
orig_interactive = 0
#5  0x00902ff4 in php_execute_script (primary_file=0x7fffd1e0) at 
/root/compile/php-src/main/main.c:2497
realfile = 
"/home/atlassian/bamboo/xml-data/build-dir/AP-RET-P53P/tests/run.php\000\000\000\000\000\021",
 '\000' , 
"P\301\377\377\377\177\000\000\336U\225\000\000\000\000\000\234\066\336\367\377\177\000\000\000\020$\001\000\000\000\000\016\000\000\000\000\000\000\000\260\302\377\377\377\177\000\000-\000\000\000\000\000\000\000fII\"\000\000\000\000\240>\336\367\377\177\000\000\000\000\000\000\000\000\000\000&\000\000\000\000\000\000\000%%\211\000\000\000\000\000\030\255\231\365\377\177\000\000\214\236\231\365\377\177\000\000"...
__orig_bailout = 0x7fffd2f0
__bailout = {{__jmpbuf = {0, -26362260470167, 4380576, 
140737488348720, 0, 0, -263622602725482883, 263621642691976829},
__mask_was_saved = 0, __saved_mask = {__val = {0, 0, 
140737314399616, 140737488343184, 0, 140737488343200, 4380576, 140737488348720, 
0, 0,
9431409, 140737488344000, 140737488349319, 19186208, 
287762808856, 21253568
prepend_file_p = 0x0
append_file_p = 0x0
prepend_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0, 
opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0,
  isatty = 0, mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0, 
old_handle = 0x0, old_closer = 0x0}, reader = 0x0, fsizer = 0x0,
  closer = 0x0}}, free_filename = 0 '\000'}
append_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0, opened_path 
= 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, isatty = 0,
  mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0, old_handle = 0x0, 
old_closer = 0x0}, reader = 0x0, fsizer = 0x0, closer = 0x0}},
  free_filename = 0 '\000'}
old_cwd = 0x7fffae60 ""
use_heap = 0 '\000'
retval = 0


[2013-08-02 16:24:26] larue...@php.net

fixed in http://git.php.net/?p=php-
src.git;a=commitdiff;h=ce9169e360701ea3b1ab2366171c24d4de5e78e3


[2013-08-02 07:29:59] mbecc...@php.net

Yes, the patch fixes the issue as far as I can tell. Well done!


[2013-08-02 02:00:15] larue...@php.net

could you please verify the fix I attached at #65372?
thanks




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


-- 
Edit this bug report at https://bugs.php.net/bug.php

Bug #65393 [Fbk->Nab]: SIGSEGV

2013-08-05 Thread laruence

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

 ID: 65393
 Updated by: larue...@php.net
 Reported by:lukyrys at gmail dot com
 Summary:SIGSEGV
-Status: Feedback
+Status: Not a bug
 Type:   Bug
 Package:PCRE related
 Operating System:   Debian 7.1
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

hi, this is obviously a stack overflow issue. no bug here.

please refer to 
http://www.php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit


Previous Comments:

[2013-08-06 04:43:32] yohg...@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.

We also needs complete backtrace. Please attach backtrace also.

https://wiki.debian.org/HowToGetABacktrace


[2013-08-06 04:41:46] yohg...@php.net

Cannot reproduce w/o input.

php > $html = file_get_contents('http://edition.cnn.com/'); 
   
php > preg_match_all('#]*?)\?img_id=(\d+)"\s*>((? var_dump($outA);
array(5) {
  [0]=>
  array(0) {
  }
  [1]=>
  array(0) {
  }
  [2]=>
  array(0) {
  }
  [3]=>
  array(0) {
  }
  [4]=>
  array(0) {
  }
}
php > 


Could you provide short self contained "complete" script that reproduce 
segfault?


[2013-08-05 12:14:26] lukyrys at gmail dot com

Description:

Hello, i have a problem with php when i use pcre regexp ((?]*?)\?img_id=(\d+)"\s*>((?https://bugs.php.net/bug.php?id=65393&edit=1

Bug #65391 [Fbk->Ver]: Unable to send vary header user-agent when ob_start('ob_gzhandler') is called

2013-08-05 Thread yohgaki

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

 ID: 65391
 Updated by: yohg...@php.net
 Reported by:nikcomestotalk at gmail dot com
 Summary:Unable to send vary header user-agent when
 ob_start('ob_gzhandler') is called
-Status: Feedback
+Status: Verified
 Type:   Bug
 Package:Output Control
 Operating System:   any
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

[yohgaki@dev PHP-5.4]$ ./sapi/cgi/php-cgi 
https://bugs.php.net/bug.php?id=65391&edit=1

Bug #65391 [Opn->Fbk]: Unable to send vary header user-agent when ob_start('ob_gzhandler') is called

2013-08-05 Thread yohgaki

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

 ID: 65391
 Updated by: yohg...@php.net
 Reported by:nikcomestotalk at gmail dot com
 Summary:Unable to send vary header user-agent when
 ob_start('ob_gzhandler') is called
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Output Control
 Operating System:   any
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

Oops, you have

header("Vary: User-Agent,Accept,Accept-Encoding");
ob_start("ob_gzhandler");
ob_flush();

Change it to 

ob_start("ob_gzhandler");
header("Vary: User-Agent,Accept,Accept-Encoding");
ob_flush();

Then it should work. If it works, please close this bug. If not, please reopen.


Previous Comments:

[2013-08-06 04:52:55] yohg...@php.net

Reclassified as output control issue, since this is output issue.


[2013-08-06 04:50:39] yohg...@php.net

zlib module is the one writing Vary header.


[2013-08-05 09:22:52] nikcomestotalk at gmail dot com

Description:

ob_start('ob_gzhandler') is overwriting vary-header "Vary: User-
Agent,Accept,Accept-Encoding" to "Vary: Accept-Encoding"


Not using apache level gzip



Test script:
---
header("Vary: User-Agent,Accept,Accept-Encoding");
ob_start("ob_gzhandler");
ob_flush();


Client side response header
vary: Accept Encoding

Expected result:

Vary: User-Agent,Accept,Accept-Encoding

Actual result:
--
vary: Accept Encoding






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

Bug #65391 [Opn]: Unable to send vary header user-agent when ob_start('ob_gzhandler') is called

2013-08-05 Thread yohgaki

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

 ID: 65391
 Updated by: yohg...@php.net
 Reported by:nikcomestotalk at gmail dot com
 Summary:Unable to send vary header user-agent when
 ob_start('ob_gzhandler') is called
 Status: Open
 Type:   Bug
-Package:Zlib related
+Package:Output Control
 Operating System:   any
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

Reclassified as output control issue, since this is output issue.


Previous Comments:

[2013-08-06 04:50:39] yohg...@php.net

zlib module is the one writing Vary header.


[2013-08-05 09:22:52] nikcomestotalk at gmail dot com

Description:

ob_start('ob_gzhandler') is overwriting vary-header "Vary: User-
Agent,Accept,Accept-Encoding" to "Vary: Accept-Encoding"


Not using apache level gzip



Test script:
---
header("Vary: User-Agent,Accept,Accept-Encoding");
ob_start("ob_gzhandler");
ob_flush();


Client side response header
vary: Accept Encoding

Expected result:

Vary: User-Agent,Accept,Accept-Encoding

Actual result:
--
vary: Accept Encoding






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

Bug #65391 [Opn]: Unable to send vary header user-agent when ob_start('ob_gzhandler') is called

2013-08-05 Thread yohgaki

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

 ID: 65391
 Updated by: yohg...@php.net
 Reported by:nikcomestotalk at gmail dot com
 Summary:Unable to send vary header user-agent when
 ob_start('ob_gzhandler') is called
 Status: Open
 Type:   Bug
-Package:zip
+Package:Zlib related
 Operating System:   any
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

zlib module is the one writing Vary header.


Previous Comments:

[2013-08-05 09:22:52] nikcomestotalk at gmail dot com

Description:

ob_start('ob_gzhandler') is overwriting vary-header "Vary: User-
Agent,Accept,Accept-Encoding" to "Vary: Accept-Encoding"


Not using apache level gzip



Test script:
---
header("Vary: User-Agent,Accept,Accept-Encoding");
ob_start("ob_gzhandler");
ob_flush();


Client side response header
vary: Accept Encoding

Expected result:

Vary: User-Agent,Accept,Accept-Encoding

Actual result:
--
vary: Accept Encoding






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

[PHP-BUG] Bug #65397 [NEW]: Mysql_* functions hide their warning

2013-08-05 Thread info at markoheijnen dot com

From: info at markoheijnen dot com
Operating system: Debian Wheezy
PHP version:  5.5.1
Package:  MySQL related
Bug Type: Bug
Bug description:Mysql_* functions hide their warning

Description:

When I run mysql_query() in PHP 5.4 without having a valid connection I
will get 
the warning about not having a valid connection and access to the user has
been 
denied. But when I now call mysql_query() in PHP 5.5 I only get the
deprecation 
message. I would expect to also see the warnings.

I only tested this with mysql_query() but I guess it will infect other
functions 
that can throw warnings.

Test script:
---
https://bugs.php.net/bug.php?id=65397&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=65397&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=65397&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=65397&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=65397&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=65397&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65397&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=65397&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=65397&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65397&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=65397&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65397&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65397&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=65397&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65397&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=65397&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=65397&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65397&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65397&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65397&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=65397&r=mysqlcfg

Bug #65393 [Fbk]: SIGSEGV

2013-08-05 Thread yohgaki

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

 ID: 65393
 Updated by: yohg...@php.net
 Reported by:lukyrys at gmail dot com
 Summary:SIGSEGV
 Status: Feedback
 Type:   Bug
 Package:PCRE related
 Operating System:   Debian 7.1
 PHP Version:5.4.17
 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.

We also needs complete backtrace. Please attach backtrace also.

https://wiki.debian.org/HowToGetABacktrace


Previous Comments:

[2013-08-06 04:41:46] yohg...@php.net

Cannot reproduce w/o input.

php > $html = file_get_contents('http://edition.cnn.com/'); 
   
php > preg_match_all('#]*?)\?img_id=(\d+)"\s*>((? var_dump($outA);
array(5) {
  [0]=>
  array(0) {
  }
  [1]=>
  array(0) {
  }
  [2]=>
  array(0) {
  }
  [3]=>
  array(0) {
  }
  [4]=>
  array(0) {
  }
}
php > 


Could you provide short self contained "complete" script that reproduce 
segfault?


[2013-08-05 12:14:26] lukyrys at gmail dot com

Description:

Hello, i have a problem with php when i use pcre regexp ((?]*?)\?img_id=(\d+)"\s*>((?https://bugs.php.net/bug.php?id=65393&edit=1

Bug #65393 [Opn->Fbk]: SIGSEGV

2013-08-05 Thread yohgaki

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

 ID: 65393
 Updated by: yohg...@php.net
 Reported by:lukyrys at gmail dot com
 Summary:SIGSEGV
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:PCRE related
 Operating System:   Debian 7.1
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

Cannot reproduce w/o input.

php > $html = file_get_contents('http://edition.cnn.com/'); 
   
php > preg_match_all('#]*?)\?img_id=(\d+)"\s*>((? var_dump($outA);
array(5) {
  [0]=>
  array(0) {
  }
  [1]=>
  array(0) {
  }
  [2]=>
  array(0) {
  }
  [3]=>
  array(0) {
  }
  [4]=>
  array(0) {
  }
}
php > 


Could you provide short self contained "complete" script that reproduce 
segfault?


Previous Comments:

[2013-08-05 12:14:26] lukyrys at gmail dot com

Description:

Hello, i have a problem with php when i use pcre regexp ((?]*?)\?img_id=(\d+)"\s*>((?https://bugs.php.net/bug.php?id=65393&edit=1

Bug #64977 [Com]: ob_start() fails when passed default parameters

2013-08-05 Thread kubo at iteman dot jp

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

 ID: 64977
 Comment by: kubo at iteman dot jp
 Reported by:rewilliams at newtekemail dot com
 Summary:ob_start() fails when passed default parameters
 Status: Analyzed
 Type:   Bug
 Package:Scripting Engine problem
 PHP Version:5.5.0RC2
 Block user comment: N
 Private report: N

 New Comment:

> This is more like a documentation bug. There is a bunch of constants 
> undocumented http://lxr.php.net/xref/PHP_5_4/main/output.c#204 . Also the 
third 
> ob_start() argument can be not only true/false, you can pass various flags 
> there. As such, if you change your first line

> ob_start(null, 0, PHP_OUTPUT_HANDLER_REMOVABLE)

> no warnings will be to see.

It works. But the "del" entry for ob_get_status() is never set with the default 
value or the built-in constants on PHP 5.4. The "del" entry is always set on 
PHP 
5.3.


Previous Comments:

[2013-06-06 08:20:57] a...@php.net

This is more like a documentation bug. There is a bunch of constants 
undocumented http://lxr.php.net/xref/PHP_5_4/main/output.c#204 . Also the third 
ob_start() argument can be not only true/false, you can pass various flags 
there. As such, if you change your first line

ob_start(null, 0, PHP_OUTPUT_HANDLER_REMOVABLE)

no warnings will be to see.

Please change this bug to be a documentation one. Or you could even fix the 
docs.


[2013-06-05 20:03:11] rewilliams at newtekemail dot com

Description:

Calling ob_start() with explicit parameters that match the defaults (using null 
to 
get past the first one, as documented), the various functions to end output 
buffering generate notices, which are also added to the buffered content. For 
example, ob_get_clean() returns the following:

ob_get_clean(): failed to discard buffer of default output handler [...]
ob_get_clean(): failed to delete buffer of default output handler (0) 
in 
[...]

It looks like output is spit out just as though buffering were not enabled, 
*and* 
the buffer gets saved - albeit with the buffering-related notices mixed in.

Testing at , it appears the bug was 
introduced in 5.4 (it works in 5.3.23) and continues through the latest version 
of 
5.5.

Test script:
---


Expected result:

string(11) "hello world"


Actual result:
--
PHP Notice:  ob_get_clean(): failed to discard buffer of default output handler 
(0) in [...] on line 5
PHP Notice:  ob_get_clean(): failed to delete buffer of default output handler 
(0) 
in [...] on line 5
hello world
Notice: ob_get_clean(): failed to discard buffer of default output handler (0) 
in 
[...] on line 5

Notice: ob_get_clean(): failed to delete buffer of default output handler (0) 
in 
[...] on line 5
string(11) "hello world"







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

Bug #65367 [ReO]: Segmentation fault when mixing =& and =

2013-08-05 Thread laruence

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

 ID: 65367
 Updated by: larue...@php.net
 Reported by:mbecc...@php.net
 Summary:Segmentation fault when mixing =& and =
 Status: Re-Opened
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Any
 PHP Version:5.5.1
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

did you built it frome a fresh work dir?


Previous Comments:

[2013-08-05 14:50:51] mbecc...@php.net

I have upgraded PHP 5.4 to latest-git on a new machine. With the patch applied 
I now see many test runs consistently fail with a segafult. Reverting to 5.4.17 
fixes the segfault.

Backtrace is:

#0  0x009beb33 in zend_std_object_get_class (object=0x7fffef535cd0) at 
/root/compile/php-src/Zend/zend_object_handlers.c:1500
zobj = 0x7fff0021
#1  0x0098dd98 in zend_get_class_entry (zobject=0x7fffef535cd0) at 
/root/compile/php-src/Zend/zend_API.c:238
No locals.
#2  0x00a17121 in ZEND_INIT_METHOD_CALL_SPEC_CV_CONST_HANDLER 
(execute_data=0x77fa1ea0)
at /root/compile/php-src/Zend/zend_vm_execute.h:29282
opline = 0x70a34228
function_name = 0x70a35058
function_name_strval = 0x77f97d50 "setFileNameProtection"
function_name_strlen = 21
#3  0x009c6513 in execute (op_array=0x1446f00) at 
/root/compile/php-src/Zend/zend_vm_execute.h:410
ret = 0
execute_data = 0x77fa1ea0
nested = 1 '\001'
original_in_execution = 0 '\000'
#4  0x0098ca9f in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /root/compile/php-src/Zend/zend.c:1315
files = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 
0x7fffae40, reg_save_area = 0x7fffad80}}
i = 1
file_handle = 0x7fffd1e0
orig_op_array = 0x0
orig_retval_ptr_ptr = 0x0
orig_interactive = 0
#5  0x00902ff4 in php_execute_script (primary_file=0x7fffd1e0) at 
/root/compile/php-src/main/main.c:2497
realfile = 
"/home/atlassian/bamboo/xml-data/build-dir/AP-RET-P53P/tests/run.php\000\000\000\000\000\021",
 '\000' , 
"P\301\377\377\377\177\000\000\336U\225\000\000\000\000\000\234\066\336\367\377\177\000\000\000\020$\001\000\000\000\000\016\000\000\000\000\000\000\000\260\302\377\377\377\177\000\000-\000\000\000\000\000\000\000fII\"\000\000\000\000\240>\336\367\377\177\000\000\000\000\000\000\000\000\000\000&\000\000\000\000\000\000\000%%\211\000\000\000\000\000\030\255\231\365\377\177\000\000\214\236\231\365\377\177\000\000"...
__orig_bailout = 0x7fffd2f0
__bailout = {{__jmpbuf = {0, -26362260470167, 4380576, 
140737488348720, 0, 0, -263622602725482883, 263621642691976829},
__mask_was_saved = 0, __saved_mask = {__val = {0, 0, 
140737314399616, 140737488343184, 0, 140737488343200, 4380576, 140737488348720, 
0, 0,
9431409, 140737488344000, 140737488349319, 19186208, 
287762808856, 21253568
prepend_file_p = 0x0
append_file_p = 0x0
prepend_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0, 
opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0,
  isatty = 0, mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0, 
old_handle = 0x0, old_closer = 0x0}, reader = 0x0, fsizer = 0x0,
  closer = 0x0}}, free_filename = 0 '\000'}
append_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0, opened_path 
= 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, isatty = 0,
  mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0, old_handle = 0x0, 
old_closer = 0x0}, reader = 0x0, fsizer = 0x0, closer = 0x0}},
  free_filename = 0 '\000'}
old_cwd = 0x7fffae60 ""
use_heap = 0 '\000'
retval = 0


[2013-08-02 16:24:26] larue...@php.net

fixed in http://git.php.net/?p=php-
src.git;a=commitdiff;h=ce9169e360701ea3b1ab2366171c24d4de5e78e3


[2013-08-02 07:29:59] mbecc...@php.net

Yes, the patch fixes the issue as far as I can tell. Well done!


[2013-08-02 02:00:15] larue...@php.net

could you please verify the fix I attached at #65372?
thanks


[2013-08-02 01:11:26] larue...@php.net

Seems similar to #65372




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


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

Bug #64699 [Com]: is_dir() is inaccurate result on Windows with japanese locale.

2013-08-05 Thread ku at digitaldolphins dot jp

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

 ID: 64699
 Comment by: ku at digitaldolphins dot jp
 Reported by:sharkpp at gmail dot com
 Summary:is_dir() is inaccurate result on Windows with
 japanese locale.
 Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Windows
 PHP Version:5.4.14
 Block user comment: N
 Private report: N

 New Comment:

Ah, sorry...

---
Insert the prefix: wfio://

is_dir("wfio://C:/")

is_dir("wfio://C:\\")

---
It will list entries in Shift-JIS charset, with Japanese Windows.

php.exe -r "print_r(scandir('C:/'));"

---
It will list entries in UTF8.

php.exe -r "print_r(scandir('wfio://C:/'));"

---
"wfio://" may support:
fopen, fwrite, fread, stat, fclose,
opendir, readdir, closedir,
rename, copy, unlink,
mkdir, rmdir.

Here is first post about php-wfio.

http://news.php.net/php.windows/30987

Thanks


Previous Comments:

[2013-07-30 16:48:43] a...@php.net

Related To: Bug #65358


[2013-05-25 04:28:05] sharkpp at gmail dot com

Thank you.
I hope a major version.

Incidentally, php-wfio is not work.
Because is_dir() is not implemented.


[2013-05-07 06:54:57] paj...@php.net

For the record, it is not that it won't be fixed but can't be fixed at this 
stage 
but in a major version. Not only PHP's code and not only for file stream 
wrapper.


[2013-05-07 06:36:39] ku at digitaldolphins dot jp

Hi.

It is known problem. And it won't be fixed.

If you need a patch, check my one at:

https://bugs.php.net/bug.php?id=61315

Or you can try php-wfio extension instead.

https://code.google.com/p/php-wfio/

It needs to be built manually with step by step instruction. 

https://wiki.php.net/internals/windows/stepbystepbuild

Try at your own risk!

Thanks
kenji uno.


[2013-04-23 15:48:54] sharkpp at gmail dot com

Description:

Environment

I'm testing this problem on Windows 7 Ultimate x86 english.

Configuration changes little is required to reproduce.

1. Please open "Control Panel".
2. Please click "Change display language" link.
3. Please select "Administrative" tab and click "Change system locale..." 
button.
4. Please change current system locale "Japanese(Japan)".

The above procedure is not needed if you want to try in the Japanese versions 
of 
Windows.

php in immediately after installation, the default state is also php.ini (does 
not exist).

Problem

is_dir() will lie If you create a folder that contains the "\x5C" in the string.
It may  is included in the second byte of Shift_JIS.
For example ã½(\x83\x5C).
More example: 
https://ja.wikipedia.org/wiki/Shift_JIS (japanese)


Test script:
---
@mkdir("a");
@mkdir("\x83\x5D");
@mkdir("\x83\x5C");

$dir = './';
if ($dh = opendir($dir)) {
while (($file = readdir($dh)) !== false) {
$path = $dir . $file;
$type = filetype($path);
$type2= is_dir($path) ? 'dir' : 'file';
$comp = $type == $type2 ? 'OK' : 'NG';
echo "filetype()[".str_pad($type, 4)."] == is_dir()[".str_pad($type2, 
4)."] -> $comp: {$file}\n";
}
closedir($dh);
}


Expected result:

filetype()[dir ] == is_dir()[dir ] -> OK: .
filetype()[dir ] == is_dir()[dir ] -> OK: ..
filetype()[dir ] == is_dir()[dir ] -> OK: a
filetype()[file] == is_dir()[file] -> OK: test.php
filetype()[dir ] == is_dir()[file] -> NG: ã½
filetype()[dir ] == is_dir()[dir ] -> OK: ã¾


Actual result:
--
filetype()[dir ] == is_dir()[dir ] -> OK: .
filetype()[dir ] == is_dir()[dir ] -> OK: ..
filetype()[dir ] == is_dir()[dir ] -> OK: a
filetype()[file] == is_dir()[file] -> OK: test.php
filetype()[dir ] == is_dir()[dir ] -> OK: ã½
filetype()[dir ] == is_dir()[dir ] -> OK: ã¾







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

Bug #61268 [Csd]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d

2013-08-05 Thread mike at harschsystems dot com

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

 ID: 61268
 User updated by:mike at harschsystems dot com
 Reported by:mike at harschsystems dot com
 Summary:--enable-dtrace leads make to clobber
 Zend/zend_dtrace.d
 Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   solaris
 PHP Version:5.4.0
 Assigned To:dsp
 Block user comment: N
 Private report: N

 New Comment:

Building on solaris/illumos is still broken per the description in bug 62692.  
I 
don't know how it reached 'verified' state but it needs to be re-opened and 
evaluated.


Previous Comments:

[2013-08-05 22:50:43] s...@php.net

The fix for this bug has been committed.

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/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




[2013-08-05 16:05:25] mike at harschsystems dot com

The suggested patch does appear to fix the clobber problem on illumos.

This clears the way to hit bug 62692 (which also breaks dtrace on solaris-based 
systems).

Let's fix the issue of not applying the 'dtrace -G' step to the files in 
Zend/.libs so that we can reach a working state for dtrace on solaris.


[2013-08-03 01:14:49] s...@php.net

After some investigation, I think the easiest patch is below.  This has only 
been tested on Linux in one install scenario.  I'll continuing testing after 
the weekend.

diff --git a/acinclude.m4 b/acinclude.m4
index 07b1f8e..01eabf2 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -2962,8 +2962,12 @@ dnl DTrace objects
   esac
 
 dnl Generate Makefile.objects entries
+dnl The empty $ac_provsrc command stops an implicit circular dependency
+dnl triggering which lead to the .d file being overwritten with GNU make (Bug 
61268)
   cat>>Makefile.objects< \$[]@


[2013-08-03 01:14:49] s...@php.net

Related To: Bug #61268


[2013-07-23 10:54:27] eugene at zhegan dot in

Still there on 5.5.1.




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


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

[PHP-BUG] Bug #65396 [NEW]: Separators at the beginning of string are also exploded

2013-08-05 Thread empaingeo at hotmail dot com

From: empaingeo at hotmail dot com
Operating system: Windows Vista
PHP version:  Irrelevant
Package:  Strings related
Bug Type: Bug
Bug description:Separators at the beginning of string are also exploded

Description:

---
>From manual page:
http://www.php.net/function.explode#refsect1-function.explode-returnvalues
---

Hi, to reproduce the problem :



Test script:
---
";
echo print_r(explode(' ', "test1 test2"));
echo "";
?>

Expected result:

Array
(
[0] => test1
[1] => test2
)
1

Actual result:
--
Array
(
[0] => 
[1] => 
[2] => 
[3] => 
[4] => test1
[5] => test2
)
1

-- 
Edit bug report at https://bugs.php.net/bug.php?id=65396&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=65396&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=65396&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=65396&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=65396&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=65396&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65396&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=65396&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=65396&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65396&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=65396&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65396&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65396&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=65396&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65396&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=65396&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=65396&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65396&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65396&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65396&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=65396&r=mysqlcfg

Bug #61268 [Asn->Csd]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d

2013-08-05 Thread sixd

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

 ID: 61268
 Updated by: s...@php.net
 Reported by:mike at harschsystems dot com
 Summary:--enable-dtrace leads make to clobber
 Zend/zend_dtrace.d
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   solaris
 PHP Version:5.4.0
 Assigned To:dsp
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2013-08-05 16:05:25] mike at harschsystems dot com

The suggested patch does appear to fix the clobber problem on illumos.

This clears the way to hit bug 62692 (which also breaks dtrace on solaris-based 
systems).

Let's fix the issue of not applying the 'dtrace -G' step to the files in 
Zend/.libs so that we can reach a working state for dtrace on solaris.


[2013-08-03 01:14:49] s...@php.net

After some investigation, I think the easiest patch is below.  This has only 
been tested on Linux in one install scenario.  I'll continuing testing after 
the weekend.

diff --git a/acinclude.m4 b/acinclude.m4
index 07b1f8e..01eabf2 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -2962,8 +2962,12 @@ dnl DTrace objects
   esac
 
 dnl Generate Makefile.objects entries
+dnl The empty $ac_provsrc command stops an implicit circular dependency
+dnl triggering which lead to the .d file being overwritten with GNU make (Bug 
61268)
   cat>>Makefile.objects< \$[]@


[2013-08-03 01:14:49] s...@php.net

Related To: Bug #61268


[2013-07-23 10:54:27] eugene at zhegan dot in

Still there on 5.5.1.


[2013-02-18 16:11:27] mike at harschsystems dot com

Change from closed to assigned.




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


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

Bug #65088 [Com]: Generated configure script is malformed on OpenBSD

2013-08-05 Thread glen at delfi dot ee

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

 ID: 65088
 Comment by: glen at delfi dot ee
 Reported by:stolen dot data dot net at gmail dot com
 Summary:Generated configure script is malformed on OpenBSD
 Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   OpenBSD 5.3 (possibly all BSDs)
 PHP Version:5.5.0
 Assigned To:aharvey
 Block user comment: N
 Private report: N

 New Comment:

this is actually old bug going back to 2006, fixed in pld, but seems never 
reached php.net

http://git.pld-linux.org/?
p=packages/php.git;a=commitdiff;h=0c510837964981255f8f3bdb0bd9473d404770a1

pld uses (used) pdksh as well at that time


Previous Comments:

[2013-06-23 18:07:42] ahar...@php.net

Automatic comment on behalf of aharvey
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=2531307be601b95a4aac38dc26dd2d27112b9291
Log: Fix bug #65088 (Generated configure script is malformed on OpenBSD).


[2013-06-23 18:01:03] ahar...@php.net

Editing the summary so that the news entry is more obvious.


[2013-06-23 17:41:42] ahar...@php.net

Terrific; thanks for that. I'll run a couple more tests quickly, and assuming 
they're OK, will push this.


[2013-06-23 16:32:13] stolen dot data dot net at gmail dot com

Backslash-escaping the quotes seems to be the issue, turning the quotes into 
literals causing broken substitution on both sh, ksh and bash.

sdata@antikythera$ cd /home/"sdata" && pwd 
/home/sdata

sdata@antikythera$ cd /home/\"sdata\" && pwd
ksh: cd: /home/"sdata" - No such file or directory


[2013-06-23 16:14:25] stolen dot data dot net at gmail dot com

Yes, I understand the quotation has to be reworked rather than removed 
("quick'n'dirty") - aharvey's supplied patch that changed the manner of 
quotation 
solved the problem, by the way.

No modifications have been done to my sh binary, and same goes for my 
environment 
with the exception of setting LC_CTYPE to get proper UTF-8 support. The problem 
is 
identical whether I run the vanilla configure or the rebuilt one, without 
arguments, or with the arguments I use for my PHP build.

I reported this problem already with PHP 5.4.0 on OpenBSD 5.0 - the PHP 5.3 
branch 
did not show this problem on OpenBSD 5.0 or any other earlier version that I've 
been running for years, all of which use an unmodified environment.

Quoting portion of a path - cd /some/path/"somewhere" - works just fine 
straight 
off the shell with sh, ksh and bash, just like expected. I tested this already 
over a year ago when when I found this issue the first time. Why it fails when 
executed inside the configure script confused me already back then.




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


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

Bug #43372 [Nab]: FILTER_VALIDATE_INT returns null for numbers with leading zero(s)

2013-08-05 Thread rasmus

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

 ID: 43372
 Updated by: ras...@php.net
 Reported by:gbml at bravogroup dot org
 Summary:FILTER_VALIDATE_INT returns null for numbers with
 leading zero(s)
 Status: Not a bug
 Type:   Bug
 Package:Filter related
 Operating System:   linux
 PHP Version:5.2.5
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

How is it ludicrous? You understand that 08 is an invalid value in octal, 
right? 
The filters are all about filtering out invalid input. If you specify you want 
valid integers (which are in decimal notation by default) and you also say you 
want to accept integers in octal notation, then it *must* return false on a 
value 
which is neither an octal nor a decimal representation of an integer.


Previous Comments:

[2013-08-05 16:21:18] kodafixed at gmail dot com

That assumes one has control over the input. If for example, the input data 
comes from a form submission then it may in fact come into the program with 
leading zero(es). In order to make the data in this scenario "valid" for the 
test you would have to cast it or manipulate it - which makes using the 
built-in function moot. 
The concept that filter_var('8', FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_OCTAL) 
should return 8, but filter_var('08', FILTER_VALIDATE_INT, 
FILTER_FLAG_ALLOW_OCTAL) should return false is ludicrous.


[2013-08-05 15:41:28] ras...@php.net

Don't use FILTER_VALIDATE_INT if you don't want to validate decimal notation 
integers. Decimal notation integers do not have a leading 0, except for 0 
itself, 
of course. If you just want a filter that checks if the input is entirely made 
of 
digits, just use a regex. eg.

filter_var($string, FILTER_VALIDATE_REGEXP, ["options"=>["regexp"=>"/^[0-
9]+$/"]]);


[2013-08-05 14:05:50] kodafixed at gmail dot com

FILTER_FLAG_ALLOW_OCTAL is not a feasible workaround for this issue.

echo filter_var('08', FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_OCTAL) ? "OKAY" : 
"NOT OKAY";
// RESULT: "NOT OKAY"

FILTER_FLAG_ALLOW_OCTAL completely invalidates tests where the value has a 
leading 0 and includes an 8 or 9.


[2007-11-22 11:13:09] paj...@php.net

See FILTER_FLAG_ALLOW_OCTAL.


[2007-11-22 10:54:54] gbml at bravogroup dot org

Description:

Filtering input numbers with leading zero(s) and filter FILTER_VALIDATE_INT 
does not produce number


Reproduce code:
---
// $_POST ["size"] has value "002"

filter_input (INPUT_POST, "size", FILTER_VALIDATE_INT)



Expected result:

2

Actual result:
--
null






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

Bug #43372 [Com]: FILTER_VALIDATE_INT returns null for numbers with leading zero(s)

2013-08-05 Thread kodafixed at gmail dot com

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

 ID: 43372
 Comment by: kodafixed at gmail dot com
 Reported by:gbml at bravogroup dot org
 Summary:FILTER_VALIDATE_INT returns null for numbers with
 leading zero(s)
 Status: Not a bug
 Type:   Bug
 Package:Filter related
 Operating System:   linux
 PHP Version:5.2.5
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

That assumes one has control over the input. If for example, the input data 
comes from a form submission then it may in fact come into the program with 
leading zero(es). In order to make the data in this scenario "valid" for the 
test you would have to cast it or manipulate it - which makes using the 
built-in function moot. 
The concept that filter_var('8', FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_OCTAL) 
should return 8, but filter_var('08', FILTER_VALIDATE_INT, 
FILTER_FLAG_ALLOW_OCTAL) should return false is ludicrous.


Previous Comments:

[2013-08-05 15:41:28] ras...@php.net

Don't use FILTER_VALIDATE_INT if you don't want to validate decimal notation 
integers. Decimal notation integers do not have a leading 0, except for 0 
itself, 
of course. If you just want a filter that checks if the input is entirely made 
of 
digits, just use a regex. eg.

filter_var($string, FILTER_VALIDATE_REGEXP, ["options"=>["regexp"=>"/^[0-
9]+$/"]]);


[2013-08-05 14:05:50] kodafixed at gmail dot com

FILTER_FLAG_ALLOW_OCTAL is not a feasible workaround for this issue.

echo filter_var('08', FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_OCTAL) ? "OKAY" : 
"NOT OKAY";
// RESULT: "NOT OKAY"

FILTER_FLAG_ALLOW_OCTAL completely invalidates tests where the value has a 
leading 0 and includes an 8 or 9.


[2007-11-22 11:13:09] paj...@php.net

See FILTER_FLAG_ALLOW_OCTAL.


[2007-11-22 10:54:54] gbml at bravogroup dot org

Description:

Filtering input numbers with leading zero(s) and filter FILTER_VALIDATE_INT 
does not produce number


Reproduce code:
---
// $_POST ["size"] has value "002"

filter_input (INPUT_POST, "size", FILTER_VALIDATE_INT)



Expected result:

2

Actual result:
--
null






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

Bug #61268 [Asn]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d

2013-08-05 Thread mike at harschsystems dot com

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

 ID: 61268
 User updated by:mike at harschsystems dot com
 Reported by:mike at harschsystems dot com
 Summary:--enable-dtrace leads make to clobber
 Zend/zend_dtrace.d
 Status: Assigned
 Type:   Bug
 Package:Compile Failure
 Operating System:   solaris
 PHP Version:5.4.0
 Assigned To:dsp
 Block user comment: N
 Private report: N

 New Comment:

The suggested patch does appear to fix the clobber problem on illumos.

This clears the way to hit bug 62692 (which also breaks dtrace on solaris-based 
systems).

Let's fix the issue of not applying the 'dtrace -G' step to the files in 
Zend/.libs so that we can reach a working state for dtrace on solaris.


Previous Comments:

[2013-08-03 01:14:49] s...@php.net

After some investigation, I think the easiest patch is below.  This has only 
been tested on Linux in one install scenario.  I'll continuing testing after 
the weekend.

diff --git a/acinclude.m4 b/acinclude.m4
index 07b1f8e..01eabf2 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -2962,8 +2962,12 @@ dnl DTrace objects
   esac
 
 dnl Generate Makefile.objects entries
+dnl The empty $ac_provsrc command stops an implicit circular dependency
+dnl triggering which lead to the .d file being overwritten with GNU make (Bug 
61268)
   cat>>Makefile.objects< \$[]@


[2013-08-03 01:14:49] s...@php.net

Related To: Bug #61268


[2013-07-23 10:54:27] eugene at zhegan dot in

Still there on 5.5.1.


[2013-02-18 16:11:27] mike at harschsystems dot com

Change from closed to assigned.


[2013-02-18 16:10:16] mike at harschsystems dot com

This bug should not be closed unless someone can confirm that the broken 
behavior 
has been corrected.  The issue is described in detail below.  The requested 
feedback was provided and the issue was reproduced by multiple people on 
several 
versions.




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


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

Bug #43372 [Nab]: FILTER_VALIDATE_INT returns null for numbers with leading zero(s)

2013-08-05 Thread rasmus

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

 ID: 43372
 Updated by: ras...@php.net
 Reported by:gbml at bravogroup dot org
 Summary:FILTER_VALIDATE_INT returns null for numbers with
 leading zero(s)
 Status: Not a bug
 Type:   Bug
 Package:Filter related
 Operating System:   linux
 PHP Version:5.2.5
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

Don't use FILTER_VALIDATE_INT if you don't want to validate decimal notation 
integers. Decimal notation integers do not have a leading 0, except for 0 
itself, 
of course. If you just want a filter that checks if the input is entirely made 
of 
digits, just use a regex. eg.

filter_var($string, FILTER_VALIDATE_REGEXP, ["options"=>["regexp"=>"/^[0-
9]+$/"]]);


Previous Comments:

[2013-08-05 14:05:50] kodafixed at gmail dot com

FILTER_FLAG_ALLOW_OCTAL is not a feasible workaround for this issue.

echo filter_var('08', FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_OCTAL) ? "OKAY" : 
"NOT OKAY";
// RESULT: "NOT OKAY"

FILTER_FLAG_ALLOW_OCTAL completely invalidates tests where the value has a 
leading 0 and includes an 8 or 9.


[2007-11-22 11:13:09] paj...@php.net

See FILTER_FLAG_ALLOW_OCTAL.


[2007-11-22 10:54:54] gbml at bravogroup dot org

Description:

Filtering input numbers with leading zero(s) and filter FILTER_VALIDATE_INT 
does not produce number


Reproduce code:
---
// $_POST ["size"] has value "002"

filter_input (INPUT_POST, "size", FILTER_VALIDATE_INT)



Expected result:

2

Actual result:
--
null






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

[PHP-BUG] Bug #65395 [NEW]: Memory leak in TSRM.c

2013-08-05 Thread naitik dot dani at gmail dot com

From: naitik dot dani at gmail dot com
Operating system: Freebsd
PHP version:  5.5.1
Package:  *General Issues
Bug Type: Bug
Bug description:Memory leak in TSRM.c

Description:

I am seeing the following backtrace in the memory plumber output which
points 
that there is a memory leak with respect to tsrm_tls_entry in TSRM.c file:

==165== at  0x80395a890: __zend_realloc (php-5.3.25/Zend/zend_alloc.h:112)
==165== at  0x80395c7ef: _zend_hash_quick_add_or_update (php-
5.3.25/Zend/zend_hash.c:337)
==165== at  0x80395cb71: zend_hash_copy (php-5.3.25/Zend/zend_hash.c:788)
==165== at  0x80394c269: compiler_globals_ctor
(php-5.3.25/Zend/zend.c:506)
==165== at  0x8038e65ca: allocate_new_resource
(php-5.3.25/TSRM/TSRM.c:294)
==165== at  0x8038e6709: ts_resource_ex (php-5.3.25/TSRM/TSRM.c:361)
==165== at  0x8039e29f1: php_handler (php-
5.3.25/sapi/apache2handler/sapi_apache2.c:548)

I am using PHP 5.3.25 version. I looked for the patch release after this
one 
that might have a fix for it, but I couldn't find one.
I would appreciate if you can throw some light on this memory leak to help
me 
fix it. I cannot upgrade to new PHP version due to some inhouse roadblocks.

However I can patch it to fix this memory leak.

Thanks in advance.

Actual result:
--
==165== at  0x80395a890: __zend_realloc (php-5.3.25/Zend/zend_alloc.h:112)
==165== at  0x80395c7ef: _zend_hash_quick_add_or_update (php-
5.3.25/Zend/zend_hash.c:337)
==165== at  0x80395cb71: zend_hash_copy (php-5.3.25/Zend/zend_hash.c:788)
==165== at  0x80394c269: compiler_globals_ctor
(php-5.3.25/Zend/zend.c:506)
==165== at  0x8038e65ca: allocate_new_resource
(php-5.3.25/TSRM/TSRM.c:294)
==165== at  0x8038e6709: ts_resource_ex (php-5.3.25/TSRM/TSRM.c:361)
==165== at  0x8039e29f1: php_handler (php-
5.3.25/sapi/apache2handler/sapi_apache2.c:548)


-- 
Edit bug report at https://bugs.php.net/bug.php?id=65395&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=65395&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=65395&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=65395&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=65395&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=65395&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65395&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=65395&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=65395&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65395&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=65395&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65395&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65395&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=65395&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65395&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=65395&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=65395&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65395&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65395&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65395&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=65395&r=mysqlcfg

Bug #65367 [Csd->ReO]: Segmentation fault when mixing =& and =

2013-08-05 Thread mbeccati

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

 ID: 65367
 Updated by: mbecc...@php.net
 Reported by:mbecc...@php.net
 Summary:Segmentation fault when mixing =& and =
-Status: Closed
+Status: Re-Opened
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Any
 PHP Version:5.5.1
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

I have upgraded PHP 5.4 to latest-git on a new machine. With the patch applied 
I now see many test runs consistently fail with a segafult. Reverting to 5.4.17 
fixes the segfault.

Backtrace is:

#0  0x009beb33 in zend_std_object_get_class (object=0x7fffef535cd0) at 
/root/compile/php-src/Zend/zend_object_handlers.c:1500
zobj = 0x7fff0021
#1  0x0098dd98 in zend_get_class_entry (zobject=0x7fffef535cd0) at 
/root/compile/php-src/Zend/zend_API.c:238
No locals.
#2  0x00a17121 in ZEND_INIT_METHOD_CALL_SPEC_CV_CONST_HANDLER 
(execute_data=0x77fa1ea0)
at /root/compile/php-src/Zend/zend_vm_execute.h:29282
opline = 0x70a34228
function_name = 0x70a35058
function_name_strval = 0x77f97d50 "setFileNameProtection"
function_name_strlen = 21
#3  0x009c6513 in execute (op_array=0x1446f00) at 
/root/compile/php-src/Zend/zend_vm_execute.h:410
ret = 0
execute_data = 0x77fa1ea0
nested = 1 '\001'
original_in_execution = 0 '\000'
#4  0x0098ca9f in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /root/compile/php-src/Zend/zend.c:1315
files = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 
0x7fffae40, reg_save_area = 0x7fffad80}}
i = 1
file_handle = 0x7fffd1e0
orig_op_array = 0x0
orig_retval_ptr_ptr = 0x0
orig_interactive = 0
#5  0x00902ff4 in php_execute_script (primary_file=0x7fffd1e0) at 
/root/compile/php-src/main/main.c:2497
realfile = 
"/home/atlassian/bamboo/xml-data/build-dir/AP-RET-P53P/tests/run.php\000\000\000\000\000\021",
 '\000' , 
"P\301\377\377\377\177\000\000\336U\225\000\000\000\000\000\234\066\336\367\377\177\000\000\000\020$\001\000\000\000\000\016\000\000\000\000\000\000\000\260\302\377\377\377\177\000\000-\000\000\000\000\000\000\000fII\"\000\000\000\000\240>\336\367\377\177\000\000\000\000\000\000\000\000\000\000&\000\000\000\000\000\000\000%%\211\000\000\000\000\000\030\255\231\365\377\177\000\000\214\236\231\365\377\177\000\000"...
__orig_bailout = 0x7fffd2f0
__bailout = {{__jmpbuf = {0, -26362260470167, 4380576, 
140737488348720, 0, 0, -263622602725482883, 263621642691976829},
__mask_was_saved = 0, __saved_mask = {__val = {0, 0, 
140737314399616, 140737488343184, 0, 140737488343200, 4380576, 140737488348720, 
0, 0,
9431409, 140737488344000, 140737488349319, 19186208, 
287762808856, 21253568
prepend_file_p = 0x0
append_file_p = 0x0
prepend_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0, 
opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0,
  isatty = 0, mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0, 
old_handle = 0x0, old_closer = 0x0}, reader = 0x0, fsizer = 0x0,
  closer = 0x0}}, free_filename = 0 '\000'}
append_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0, opened_path 
= 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, isatty = 0,
  mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0, old_handle = 0x0, 
old_closer = 0x0}, reader = 0x0, fsizer = 0x0, closer = 0x0}},
  free_filename = 0 '\000'}
old_cwd = 0x7fffae60 ""
use_heap = 0 '\000'
retval = 0


Previous Comments:

[2013-08-02 16:24:26] larue...@php.net

fixed in http://git.php.net/?p=php-
src.git;a=commitdiff;h=ce9169e360701ea3b1ab2366171c24d4de5e78e3


[2013-08-02 07:29:59] mbecc...@php.net

Yes, the patch fixes the issue as far as I can tell. Well done!


[2013-08-02 02:00:15] larue...@php.net

could you please verify the fix I attached at #65372?
thanks


[2013-08-02 01:11:26] larue...@php.net

Seems similar to #65372


[2013-07-31 11:13:15] mbecc...@php.net

I forgot to mention that you can easily install the necessary PEAR libraries in 
the current dir without polluting the global PEAR installation with:

pear install -R . MDB2 MDB2#pgsql




The remainder of the comments for this report are too long. To view
th

Bug #43372 [Com]: FILTER_VALIDATE_INT returns null for numbers with leading zero(s)

2013-08-05 Thread kodafixed at gmail dot com

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

 ID: 43372
 Comment by: kodafixed at gmail dot com
 Reported by:gbml at bravogroup dot org
 Summary:FILTER_VALIDATE_INT returns null for numbers with
 leading zero(s)
 Status: Not a bug
 Type:   Bug
 Package:Filter related
 Operating System:   linux
 PHP Version:5.2.5
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

FILTER_FLAG_ALLOW_OCTAL is not a feasible workaround for this issue.

echo filter_var('08', FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_OCTAL) ? "OKAY" : 
"NOT OKAY";
// RESULT: "NOT OKAY"

FILTER_FLAG_ALLOW_OCTAL completely invalidates tests where the value has a 
leading 0 and includes an 8 or 9.


Previous Comments:

[2007-11-22 11:13:09] paj...@php.net

See FILTER_FLAG_ALLOW_OCTAL.


[2007-11-22 10:54:54] gbml at bravogroup dot org

Description:

Filtering input numbers with leading zero(s) and filter FILTER_VALIDATE_INT 
does not produce number


Reproduce code:
---
// $_POST ["size"] has value "002"

filter_input (INPUT_POST, "size", FILTER_VALIDATE_INT)



Expected result:

2

Actual result:
--
null






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

[PHP-BUG] Bug #65393 [NEW]: SIGSEGV

2013-08-05 Thread lukyrys at gmail dot com

From: lukyrys at gmail dot com
Operating system: Debian 7.1
PHP version:  5.4.17
Package:  PCRE related
Bug Type: Bug
Bug description:SIGSEGV

Description:

Hello, i have a problem with php when i use pcre regexp ((?]*?)\?img_id=(\d+)"\s*>((?https://bugs.php.net/bug.php?id=65393&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=65393&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=65393&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=65393&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=65393&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=65393&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65393&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=65393&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=65393&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65393&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=65393&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65393&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65393&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=65393&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65393&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=65393&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=65393&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65393&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65393&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65393&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=65393&r=mysqlcfg

Sec Bug->Bug #62978 [Csd]: pg_select() and similar are vulnerable to SQL injection via identifier

2013-08-05 Thread yohgaki

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

 ID: 62978
 Updated by: yohg...@php.net
 Reported by:slokunshialgo at gmail dot com
 Summary:pg_select() and similar are vulnerable to SQL
 injection via identifier
 Status: Closed
-Type:   Security
+Type:   Bug
 Package:PostgreSQL related
 Operating System:   *
 PHP Version:5.3 - master
 Assigned To:yohgaki
 Block user comment: N
 Private report: Y

 New Comment:

This fix is treated as security enhancement, so 5.3 branch won't be fixed.


Previous Comments:

[2013-08-05 10:01:11] yohg...@php.net

Fixed. 

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


[2013-06-30 21:30:40] yohg...@php.net

I've made patch against PHP-5.3

https://github.com/yohgaki/php-src/compare/PHP-5.3-pg_select_fix

It passes tests with PostgreSQL 9.2, but it should be tested with 8.4 or less.
This patch supposed to be able to merge upto master, but not tested yet.


[2013-06-29 20:49:22] yohg...@php.net

Changed Summary to descriptive one.


[2013-06-29 20:39:23] yohg...@php.net

I think this problem existed from the beginning. So any version which have 
pg_select()/etc are affected.


[2013-06-29 20:36:10] yohg...@php.net

This is the way it is supposed to use. pg_select() and similar functions should 
automatically escape string vars, and they do. 

pg_select($db, 't1',['str'=>"It's a string"]);
produces
LOG:  æ: SELECT * FROM t1 WHERE str='It''s a string';
Note that string is properly escaped.

However, they don't escape identifier. This should be fixed.




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


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

[PHP-BUG] Bug #65392 [NEW]: Warning for a success message with ftp_chdir

2013-08-05 Thread Laurent dot Lyaudet at gmail dot com

From: Laurent dot Lyaudet at gmail dot com
Operating system: Debian Linux
PHP version:  5.4.17
Package:  FTP related
Bug Type: Bug
Bug description:Warning for a success message with ftp_chdir

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 bug report at https://bugs.php.net/bug.php?id=65392&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=65392&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=65392&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=65392&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=65392&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=65392&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65392&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=65392&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=65392&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65392&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=65392&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65392&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65392&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=65392&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65392&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=65392&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=65392&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65392&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65392&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65392&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=65392&r=mysqlcfg

Bug #49155 [Com]: SoapServer passes parameters as null if one has special wsdl definition

2013-08-05 Thread jeroen at asystance dot nl

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

 ID: 49155
 Comment by: jeroen at asystance dot nl
 Reported by:jeroen at asystance dot nl
 Summary:SoapServer passes parameters as null if one has
 special wsdl definition
 Status: Feedback
 Type:   Bug
 Package:SOAP related
 Operating System:   linux
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

I just tested 5.5.2-dev as well: fails.


Previous Comments:

[2013-08-02 15:04:11] jeroen at asystance dot nl

Still not fixed in PHP 5.4.19-dev


[2013-08-02 04:26:54] yohg...@php.net

Please try using this snapshot:

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

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

I see several fixes in soap module. Could you try 5.4?


[2012-04-26 08:30:22] nicolodien at gmx dot de

Hi everybody

I just want to confirm that this is still an issue! I've spent more than 3 
hours debugging until I finally found this bug description giving me a 
solution. 

Please DO fix this problem...
Thanks


[2011-02-11 12:25:22] jeroen at asystance dot nl

Just wanted to verify that this bug is still present in 5.3.3


[2009-08-05 12:22:29] jeroen at asystance dot nl

Sorry for posting yet another comment, but it gets even weirder:


  
  

This will not work, because in the first part, the name==element

However,

  
  

_will_ work! Notice that now both parts are specified with name==element!


My conclusion so far is that either _all_ of the parts need to be specified 
with the name==element pattern, or _none_. If one of the parts uses the 
pattern, the rest needs to conform, or else the SoapServer passes them as null.

I sure hope this helps! I've been struggling with this for a while now.




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


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

Bug #65391 [Ver]: Unable to send vary header user-agent when ob_start('ob_gzhandler') is called

[PHP-BUG] Bug #65398 [NEW]: Race condition between SIGCHLD and child stdout/stderr event leads to segfault

Req #48016 [Opn->Csd]: stdClass::__setState is not defined although var_export() uses it

Bug #65367 [ReO]: Segmentation fault when mixing =& and =

Bug #65393 [Fbk->Nab]: SIGSEGV

Bug #65391 [Fbk->Ver]: Unable to send vary header user-agent when ob_start('ob_gzhandler') is called

Bug #65391 [Opn->Fbk]: Unable to send vary header user-agent when ob_start('ob_gzhandler') is called

Bug #65391 [Opn]: Unable to send vary header user-agent when ob_start('ob_gzhandler') is called

Bug #65391 [Opn]: Unable to send vary header user-agent when ob_start('ob_gzhandler') is called

[PHP-BUG] Bug #65397 [NEW]: Mysql_* functions hide their warning

Bug #65393 [Fbk]: SIGSEGV

Bug #65393 [Opn->Fbk]: SIGSEGV

Bug #64977 [Com]: ob_start() fails when passed default parameters

Bug #65367 [ReO]: Segmentation fault when mixing =& and =

Bug #64699 [Com]: is_dir() is inaccurate result on Windows with japanese locale.

Bug #61268 [Csd]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d

[PHP-BUG] Bug #65396 [NEW]: Separators at the beginning of string are also exploded

Bug #61268 [Asn->Csd]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d

Bug #65088 [Com]: Generated configure script is malformed on OpenBSD

Bug #43372 [Nab]: FILTER_VALIDATE_INT returns null for numbers with leading zero(s)

Bug #43372 [Com]: FILTER_VALIDATE_INT returns null for numbers with leading zero(s)

Bug #61268 [Asn]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d

Bug #43372 [Nab]: FILTER_VALIDATE_INT returns null for numbers with leading zero(s)

[PHP-BUG] Bug #65395 [NEW]: Memory leak in TSRM.c

Bug #65367 [Csd->ReO]: Segmentation fault when mixing =& and =

Bug #43372 [Com]: FILTER_VALIDATE_INT returns null for numbers with leading zero(s)

[PHP-BUG] Bug #65393 [NEW]: SIGSEGV

Sec Bug->Bug #62978 [Csd]: pg_select() and similar are vulnerable to SQL injection via identifier

[PHP-BUG] Bug #65392 [NEW]: Warning for a success message with ftp_chdir

Bug #49155 [Com]: SoapServer passes parameters as null if one has special wsdl definition

30 matches

Site Navigation

Mail list logo

Footer information