Bug #61936 [Opn->Nab]: GDB ____executor_globals fails when EG/CG symbol may not visible in some module

[laruence]

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

 ID: 61936
 Updated by: larue...@php.net
 Reported by:reeze dot xia at gmail dot com
 Summary:GDB executor_globals fails when EG/CG symbol may
 not visible in some module
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   *Nix
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

it's not a bug, more about wrong usage (discussed with the report via the pull 
request)


Previous Comments:

[2012-05-04 04:13:55] reeze dot xia at gmail dot com

sorry I missed " in non-ZTS build " after "affected，since executor_globals 
always 
available)."

It's: "Only ZTS build affected，since executor_globals/compiler_globals always 
available in non-ZTS build"


[2012-05-04 04:03:46] reeze dot xia at gmail dot com

Hi, 
  I've sent a pull request. open this bug ticket just for record.

see https://github.com/php/php-src/pull/74/

Thanks.


[2012-05-04 03:57:14] reeze dot xia at gmail dot com

Description:

when debug using GDB, sometime executor_globals failed to execute 
because in some module eg:zend_gc.c did have zend_executor_global exposed(Only 
ZTS 
model affected，since executor_globals always available).

Test script:
---
(gdb) b gc_zval_possible_root
Breakpoint 1 at 0x1005aa7d0: file zend_gc.c, line 132.
(gdb) r circle.php 
Starting program: /Users/reeze/Opensource/php-src/sapi/cli/php circle.php
Reading symbols for shared libraries ++.. done

Breakpoint 1, gc_zval_possible_root (zv=0x100dcbb58, tsrm_ls=0x100e009b0) at 
zend_gc.c:132
warning: Source file is more recent than executable.
132 if (UNEXPECTED(GC_G(free_list) != NULL &&
(gdb) printzv zv
No symbol "zend_executor_globals" in current context.

Expected result:

print zval correctly

Actual result:
--
No symbol "zend_executor_globals" in current context.






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

Bug #61970 [Opn]: Restraining __construct() access level in subclass gives a fatal error

[cataphract]

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

 ID: 61970
 Updated by: cataphr...@php.net
 Reported by:postmaster at greg0ire dot fr
 Summary:Restraining __construct() access level in subclass
 gives a fatal error
 Status: Open
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux
 PHP Version:5.3.12
 Block user comment: N
 Private report: N

 New Comment:

It's true that PHP's behavior doesn't make a lot of sense from a theoretical 
perspective. However, there are some practical reasons why a different behavior 
would be -- arguably -- less desirable.

Namely, in PHP the constructor can be called from every instance method, even 
after construction. This makes it a necessity that the constructor act like 
regular instance methods. Consider:

a = new stdclass; }
function reset() { $this->__construct(); }
}
class B extends A {
private function __construct() { } //what of reset() now?
}

Plus, PHP allows enforcing constructor signatures via interfaces. This means 
you have to enforce that signature throughout the hierarchy, and this includes 
not allows changing the visibility of the constructor.

Similarly, there's no principled reason to be unable to reduce the visibility 
in static methods. But PHP also prohibits such a pattern, like Java does, even 
though there's no overriding (the method in the superclass is said to be 
hidden). But PHP, like Java, allows calling static methods through an instance 
and through the subclass name. Then if you call the reduced visibility static 
method with the subclass name or a subclass instance, what would you do? Would 
it depend on the access of the caller has to the subclass method?


Previous Comments:

[2012-05-07 18:47:00] postmaster at greg0ire dot fr

fixed the title


[2012-05-07 18:40:56] postmaster at greg0ire dot fr

Description:

Restraining the __construct() method un a subtype gives a Fatal error.
As stated in the following resources, the LSP should not apply here.


- https://bugs.php.net/bug.php?id=40880
- 
http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle
- 
http://ralphschindler.com/2012/03/09/php-constructor-best-practices-and-the-prototype-pattern

Test script:
---
 PHP Fatal error:  Access level to Bar::__construct() must be public (as in 
> class Foo) in /tmp/bug.php on line 9

> Fatal error: Access level to Bar::__construct() must be public (as in class 
> Foo) in /tmp/bug.php on line 9






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

Bug #39179 [Com]: Abstract types not handled by SoapClient in WSDL mode

[marius dot orcsik at avangate dot com]

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

 ID: 39179
 Comment by: marius dot orcsik at avangate dot com
 Reported by:jchernia at netsuite dot com
 Summary:Abstract types not handled by SoapClient in WSDL
 mode
 Status: No Feedback
 Type:   Bug
 Package:SOAP related
 Operating System:   Windows XP
 PHP Version:5.1.6
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

This problem is still present in PHP 5.3.12.


Previous Comments:

[2009-08-05 17:54:50] styx31 at gmail dot com

This bug is still present in the last version.

SoapClient does not honor polymorphism correctly, with or without abstract types

Sample WSDL :


  

  


  

  
  

  


Operation contract :


 
  
 


The operation CheckPerson accepts both Person and PersonIdentity.

Despite the fact that you can create a class which correponds in PHP :

class PersonIdentity {
  public $Id;
}

class Person extends PersonIdentity {
  public $Name;
  public $FirstName;
}

If you use a Person instance when you call CheckPerson() :
- the Person will be serialized as a PersonIdentity,
- no i:type="Person" attribute will be added to the  element,
- the properties belonging to the Person class will be dropped


[2009-06-16 06:07:08] dasteph+forum at gmail dot com

Hi,

I have pretty the same problem.
Reproducing code: http://castex.de/stuff/php-bug.txt

expected result (in error log)
--
[15-Jun-2009 16:47:29] client
[15-Jun-2009 16:47:29] server
[15-Jun-2009 16:47:29] TestAbstractRequest Object
(
[element] => Child Object
(
[name] => test
)

)

actual result
-
[15-Jun-2009 16:47:29] client
[15-Jun-2009 16:47:29] server
[15-Jun-2009 16:47:29] TestAbstractRequest Object
(
[element] => Father Object
(
[name] => test
[number] => 5
)

)


Regards

Stephan


[2009-02-20 04:40:46] jchernia at netsuite dot com

Full WSDL - 

https://webservices.netsuite.com/wsdl/v2008_2_0/netsuite.wsdl

The code that Stu submitted will cause the problem. When making the 
get() request you will get

 
instead of 


where internalId and type are properties of the subclass (RecordRef) 
and not of BaseRef.

-John


[2008-09-30 07:47:51] stuart at stuartherbert dot com

Looks like jchernia is trying to access Netsuite's web service (Netsuite is a 
popular hosted ERP solution).  You can't access their SOAP service w/out a 
valid account, but if you had such an account, the following code triggers the 
error:

email='';
$user->password='';
$user->account='';
$user->role=new RecordRef;
$user->role->internalId=;

$loginRequest = new LoginRequest;
$loginRequest->passport = $user;

$soapClient = new 
SoapClient('https://webservices.netsuite.com/wsdl/v2008_1_0/netsuite.wsdl', 
array('trace' => 1));
$result = $soapClient->login($loginRequest);

$requestRef = new RecordRef;
$requestRef->externalId = 200;
$requestRef->type = 'issue';

try
{
$issue = $soapClient->get(array('recordRef' => $requestRef));
var_dump($issue);
}
catch (Exception $e)
{
var_dump($e);
var_dump($soapClient->__getLastRequest());
var_dump($soapClient->__getLastResponse());
}

?>

__getLastRequest() reports:

http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:ns1="urn:messages_2008_2.platform.webservices.netsuite.com">

and __getLastResponse() reports:


http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
  

  soapenv:Server.userException
  org.xml.sax.SAXException: 
{urn:core_2008_2.platform.webservices.netsuite.com}BaseRef is an abstract type 
and cannot be instantiated
  
http://xml.apache.org/axis/";>partners-java001.svale.netledger.com
  

  


Note the empty  in the request.  baseRef is an abstract type, in 
this case extended the recordRef.  The correct SOAP request is listed by the 
original poster.

Hope that helps.  If you need a Netsuite account for testing purposes, contact 
me privately and I'll sort one out for you.

Best regards,
Stu
--


[2006-10-31 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

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

[felipe]

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

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



Previous Comments:

[2012-05-08 04:35:50] mike at harschsystems dot com

I've seen the same failing behavior on 5.4.1 as well.  It's worth noting that 
gmake exhibits this failure mode while regular (non-GNU) make works fine.  So, 
the 
2 workarounds are:

1.) run gmake with the '-r' option
or
2.) run non-GNU make instead of gmake


[2012-04-22 13:13:01] alasdairrr at gmail dot com

I can confirm I'm seeing this problem too on both Solaris 10 and SmartOS.


[2012-03-03 20:19:39] mike at harschsystems dot com

Description:

5.4.0 bundle configured with only one option: --enable-dtrace

The configure script runs fine and the build finishes without error.  However, 
the next invocation of 
make (probably from trying to run 'make install') fails with the following 
error:


[jack@fjpe6maa ~/php-5.4.0]$ make install
gcc   /home/jack/php-5.4.0/Zend/zend_dtrace.d.o   -o /home/jack/php-
5.4.0/Zend/zend_dtrace.d
Undefined   first referenced
 symbol in file
main/usr/lib/crt1.o
php_request_startup /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
dtrace_execute_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
dtrace_execute  /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
php_request_shutdown/home/jack/php-5.4.0/Zend/zend_dtrace.d.o
zend_throw_exception_internal   /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
dtrace_compile_file /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
$dtrace185178.ZEND_CATCH_SPEC_CONST_CV_HANDLER /home/jack/php-
5.4.0/Zend/zend_dtrace.d.o
zend_error_noreturn /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
ld: fatal: symbol referencing errors. No output written to /home/jack/php-
5.4.0/Zend/zend_dtrace.d
collect2: ld returned 1 exit status
make: *** [/home/jack/php-5.4.0/Zend/zend_dtrace.d] Error 1

What's happening here is that make has determined that the file 
Zend/zend_dtrace.d is out of date and 
must be rebuilt.  It matches a built-in implicit rule that ends up running:
gcc   /home/jack/php-5.4.0/Zend/zend_dtrace.d.o   -o /home/jack/php-
5.4.0/Zend/zend_dtrace.d

This command fails with the error that you see, but it also clobbers 
zend_dtrace.d

Here's a bit more detail from 'make -d':
 
 Prerequisite `/home/jack/php-5.4.0/Zend/zend_dtrace.d.o' is newer 
than target 
`/home/jack/php-5.4.0/Zend/zend_dtrace.d'.
Must remake target `/home/jack/php-5.4.0/Zend/zend_dtrace.d'.
Invoking builtin recipe to update target `/home/jack/php-
5.4.0/Zend/zend_dtrace.d'.
gcc   /home/jack/php-5.4.0/Zend/zend_dtrace.d.o   -o /home/jack/php-
5.4.0/Zend/zend_dtrace.d
Putting child 80bdaa0 (/home/jack/php-5.4.0/Zend/zend_dtrace.d) PID 5104 on the 
chain.
Live child 80bdaa0 (/home/jack/php-5.4.0/Zend/zend_dtrace.d) PID 5104
Undefined   first referenced
 symbol in file
main/usr/lib/crt1.o
php_request_startup /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
dtrace_execute_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
dtrace_execute  /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
$dtrace187054.ZEND_CATCH_SPEC_CONST_CV_HANDLER /home/jack/php-
5.4.0/Zend/zend_dtrace.d.o
php_request_shutdown/home/jack/php-5.4.0/Zend/zend_dtrace.d.o
zend_throw_exception_internal   /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
dtrace_compile_file /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
zend_error_noreturn /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
ld: fatal: symbol referencing errors. No output written to /home/jack/php-
5.4.0/Zend/zend_dtrace.d
collect2: ld returned 1 exit status
Reaping losing child 80bdaa0 PID 5104
make: *** [/home/jack/php-5.4.0/Zend/zend_dtrace.d] Error 1


I was able to work-around this issue by disabling built-in implicit rules with 
'make -r'.  Obviously, I 
had to recover the clobbered file before this worked.

The offending Makefile may be seen here: http://harschsystems.com/bugs/php-
54_sol_dtrace/Makefile.txt

For reference:
On solaris (and solaris-derived) systems, the compilation of USDT dtrace 

Bug #61970 [Com]: Restraining __construct() access level in subclass gives a fatal error

[postmaster at greg0ire dot fr]

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

 ID: 61970
 Comment by: postmaster at greg0ire dot fr
 Reported by:postmaster at greg0ire dot fr
 Summary:Restraining __construct() access level in subclass
 gives a fatal error
 Status: Open
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux
 PHP Version:5.3.12
 Block user comment: N
 Private report: N

 New Comment:

Thanks for the detailed answer, it is very informative, especially the first 
bit, which even shows the LSP could be applied in this case.


Previous Comments:

[2012-05-08 10:46:42] cataphr...@php.net

It's true that PHP's behavior doesn't make a lot of sense from a theoretical 
perspective. However, there are some practical reasons why a different behavior 
would be -- arguably -- less desirable.

Namely, in PHP the constructor can be called from every instance method, even 
after construction. This makes it a necessity that the constructor act like 
regular instance methods. Consider:

a = new stdclass; }
function reset() { $this->__construct(); }
}
class B extends A {
private function __construct() { } //what of reset() now?
}

Plus, PHP allows enforcing constructor signatures via interfaces. This means 
you have to enforce that signature throughout the hierarchy, and this includes 
not allows changing the visibility of the constructor.

Similarly, there's no principled reason to be unable to reduce the visibility 
in static methods. But PHP also prohibits such a pattern, like Java does, even 
though there's no overriding (the method in the superclass is said to be 
hidden). But PHP, like Java, allows calling static methods through an instance 
and through the subclass name. Then if you call the reduced visibility static 
method with the subclass name or a subclass instance, what would you do? Would 
it depend on the access of the caller has to the subclass method?


[2012-05-07 18:47:00] postmaster at greg0ire dot fr

fixed the title


[2012-05-07 18:40:56] postmaster at greg0ire dot fr

Description:

Restraining the __construct() method un a subtype gives a Fatal error.
As stated in the following resources, the LSP should not apply here.


- https://bugs.php.net/bug.php?id=40880
- 
http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle
- 
http://ralphschindler.com/2012/03/09/php-constructor-best-practices-and-the-prototype-pattern

Test script:
---
 PHP Fatal error:  Access level to Bar::__construct() must be public (as in 
> class Foo) in /tmp/bug.php on line 9

> Fatal error: Access level to Bar::__construct() must be public (as in class 
> Foo) in /tmp/bug.php on line 9






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

Bug #48795 [Com]: Building intl 64-bit fails on OS X

[k...@php.net]

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

 ID: 48795
 Comment by: k...@php.net
 Reported by:gwy...@php.net
 Summary:Building intl 64-bit fails on OS X
 Status: Verified
 Type:   Bug
 Package:Compile Failure
 Operating System:   OS X 10.5 & 10.6; Linux
 PHP Version:5.3 SVN; 5.4.0RC1
 Block user comment: N
 Private report: N

 New Comment:

Also happens again with PHP 5.3.12 on Ubuntu 12.04 -- stas fix confirmed. A 
generic solution would be nice, indeed.


Previous Comments:

[2012-03-13 15:46:33] dan at cdchase dot com

It would be helpful if the build system imported any already set CFLAGS. As 
I've experienced this issue before, so I've set the appropriate CFLAGS in my 
default environment. But, the automated install routine does not honor these. I 
have to manually install for them to be honored.


[2011-11-14 16:54:00] weierophin...@php.net

I can confirm Stas's suggestion (s/CC/CXX/ in BUILD_* vars) works with 5.4.0RC1 
on linux 64-bit.


[2011-11-11 11:30:21] ahar...@php.net

tl;dr: Debian Testing and Ubuntu 11.10 have the same problem with
./configure --enable-intl --with-curl.


Effectively the same issue (required C++ linkage not occurring) is now
happening on Ubuntu 11.10 (x86-64) and Debian Testing (armv7l) with
PHP 5.3 SVN and PHP 5.4.0RC1 when compiling with both intl and curl
enabled (note that a compile with just --enable-intl succeeds). It's
notable that both these distributions feature the new Debian
"multiarch" support. Both libcurl and libicu are the normal packaged
versions.

With ./configure --enable-intl --with-curl, the result of
the compile (on the Ubuntu box, although the Debian errors are
effectively the same, just with different architecture-specific paths)
is this:

/usr/bin/ld: ext/intl/msgformat/msgformat_helpers.o: undefined reference to 
symbol '__gxx_personality_v0@@CXXABI_1.3'
/usr/bin/ld: note: '__gxx_personality_v0@@CXXABI_1.3' is defined in DSO 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6 so try adding it to the linker command 
line
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: could not read symbols: Invalid 
operation
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1

Diffing the Makefile produced by --enable-intl alone with the
"--enable-intl --with-curl" combination produces the following
(excluding rules directly related to compiling objects within
ext/curl):

@@ -75,9 +76,9 @@
 CXXFLAGS_CLEAN = -g -O2
 DEBUG_CFLAGS =
 EXTENSION_DIR = /usr/local/lib/php/extensions/no-debug-non-zts-20100525
-EXTRA_LDFLAGS =
-EXTRA_LDFLAGS_PROGRAM =
-EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lxml2 -lxml2 
-ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio -lxml2 -lcrypt -lxml2 
-lxml2 -lxml2 -lcrypt
+EXTRA_LDFLAGS = -L/usr/lib/x86_64-linux-gnu
+EXTRA_LDFLAGS_PROGRAM = -L/usr/lib/x86_64-linux-gnu
+EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lcurl -lrt -lm -ldl -lnsl -lxml2 
-lcurl -lxml2 -ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio -lxml2 
-lcrypt -lxml2 -lxml2 -lxml2 -lcrypt
 ZEND_EXTRA_LIBS =
 INCLUDES = -I/tmp/php-5.4.0RC1/ext/date/lib -I/tmp/php-5.4.0RC1/ext/ereg/regex 
-I/usr/include/libxml2 -I/tmp/php-5.4.0RC1/ext/sqlite3/libsqlite 
-I$(top_builddir)/TSRM -I$(top_builddir)/Zend
 EXTRA_INCLUDES =
@@ -86,13 +87,13 @@
 LFLAGS =
 LIBTOOL = $(SHELL) $(top_builddir)/libtool --silent --preserve-dup-deps
 LN_S = ln -s
-NATIVE_RPATHS =
+NATIVE_RPATHS = -Wl,-rpath,/usr/lib/x86_64-linux-gnu
 PEAR_INSTALLDIR = ${exec_prefix}/lib/php
 PHP_BUILD_DATE = 2011-11-11
-PHP_LDFLAGS =
+PHP_LDFLAGS = -L/usr/lib/x86_64-linux-gnu
 PHP_LIBS =
 OVERALL_TARGET =
-PHP_RPATHS =
+PHP_RPATHS = -R /usr/lib/x86_64-linux-gnu
 PHP_SAPI = none
 PHP_VERSION = 5.4.0RC1
 PHP_VERSION_ID = 50400

Stas's suggestion of replacing the $(BUILD_CGI) and $(BUILD_CLI)
instances of $(CC) in the generated Makefile with $(CXX) fixes the
build.

I'm not familiar enough with our build system to know how to fix this,
but we should probably do something if we can for 5.4.0 final: intl
and curl doesn't seem like it would be an unusual combination. Can we
hack the build system to use the C++ compiler preferentially if
ext/intl and ext/curl are enabled, if it can't be fixed "properly"
(whatever form that takes -- it may even up being an upstream issue)?


[2011-11-06 19:11:09] luke at cywh dot com

Is there going to be a proper fix for this any time soon? I'm having a lot of 
trouble getting 5.3.8 to compile on OS X 10.6.8.


[2011-07-01 16:23:27] harald dot lapp at gmail dot com

just setting the EXTRA_LIBS did not work for 

Bug #61704 [Asn->Csd]: Crash apache, phpinfo() threading issue

[johannes]

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

 ID: 61704
 Updated by: johan...@php.net
 Reported by:ricardo dot nuno dot rodrigues at hotmail dot com
-Summary:Crash apache
+Summary:Crash apache, phpinfo() threading issue
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:MySQLi related
 Operating System:   Windows 7 64bit
 PHP Version:5.4.0
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

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




Previous Comments:

[2012-05-08 15:33:03] johan...@php.net

Automatic comment on behalf of johannes
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=e8e661128a4dcee9d2f35ed3443d567ba2ad7870
Log: Fix #61704 (Crash apache, phpinfo() threading issue)


[2012-05-07 16:35:03] johan...@php.net

This comes from using zend_hash_apply() on the plugin table on multiple 
threads. A fix using a mutex is on 
http://schlueters.de/~johannes/php/bug61704.diff

I'll switch to manual iteration however so the lock isn't needed.


[2012-05-04 23:46:20] ricardo dot nuno dot rodrigues at hotmail dot com

change to MySQL


[2012-04-28 08:44:05] ricardo dot nuno dot rodrigues at hotmail dot com

Update -- PHP 5.4.1 stills
Update -- without ANY extension stills

Update - mysqlnd

I made another test:
 1) no extensions
 2) run a large number ab -n 1 -c 20 http://127.0.0.1/phpinfo.php
 3) run on the browser on SAME TIME to see what happens

Output 
(interesting part & repeated to see if happen on the same point and it does & 
results not change with ALL other extensions loaded):

mysqlnd

Fatal error: Nesting level too deep - recursive dependency? in 
C:\\phpinfo.php on line 3
mysqlnd enabled
Version mysqlnd 5.0.10 - 20111026 - $Id: 
b0b3b15c693b7f6aeb3aa66b646fee339f175e39 $
Compression supported
SSL supported
Command buffer size 8192
Read buffer size32768
Read timeout31536000
Collecting statistics   No
Collecting memory statisticsNo
Tracing 0


[2012-04-26 14:43:26] ricardo dot nuno dot rodrigues at hotmail dot com

xdebug excluded as mentioned earlier 
the error doesn't change with or without xdebug




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


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

Bug #61713 [Com]: ext\standard\tests\strings\htmlentities10.phpt fails

[a...@php.net]

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

 ID: 61713
 Comment by: a...@php.net
 Reported by:a...@php.net
 Summary:ext\standard\tests\strings\htmlentities10.phpt fails
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   windows
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Consider the following lines in ext\standard\html.c

== BEGIN ===
ZVAL_STRING(&nm_mb_internal_encoding, "mb_internal_encoding", 0);

if (call_user_function_ex(CG(function_table), NULL, 
&nm_mb_internal_encoding, &uf_result, 0, NULL, 1, NULL TSRMLS_CC) != FAILURE) {

charset_hint = Z_STRVAL_P(uf_result);
len = Z_STRLEN_P(uf_result);

if (len == 4) { /* sizeof(none|auto|pass)-1 */
if (!memcmp("pass", charset_hint, sizeof("pass") - 1) ||
!memcmp("auto", charset_hint, sizeof("auto") - 1) ||
!memcmp("none", charset_hint, sizeof("none") - 1)) {

charset_hint = NULL;
len = 0;
}
}
goto det_charset;
}
}
#endif
#endif

charset_hint = SG(default_charset);
if (charset_hint != NULL && (len=strlen(charset_hint)) != 0) {
goto det_charset;
}
== END ===

As you can see, mbstring.internal_encoding having pass resets charset_hint and 
jumps to det_charset ommiting sapi globals check ... this results iso-8859-1 
being choosed. This all happens only with mbstring compiled as shared.

Fix follows.


Previous Comments:

[2012-04-13 17:25:06] a...@php.net

no, the previous was wrong ... default_charset gets read ... hm, looking next )


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

Currently the php manual says some wrong things in 
http://de2.php.net/htmlentities about charset:

An empty string activates detection from script encoding (Zend multibyte), 
default_charset and current locale (see nl_langinfo() and setlocale()), in this 
order.

I can see only the following in the code of htmlentities:

* detection of the passed charset
* detection of the mbstring.internal_encoding
* detection of the current locales

The test relies on the default_charset value, which never affects htmlentities. 
This is the reason for bug 61714 and bug 61715 as well.


[2012-04-13 09:01:16] a...@php.net

Description:

Test diff:

002+ string(4) ",+TY"
003+ string(27) "?¢£¤¥"
002- string(28) "‚†™Ÿ"
003- string(32) "€¢£¤¥"

Expected result:

test pass

Actual result:
--
test fail






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

Bug #38104 [Com]: session_start()/session_write_close() creates multiple session cookies headers

[andries dot malan at gmail dot com]

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

 ID: 38104
 Comment by: andries dot malan at gmail dot com
 Reported by:m dot v dot veluw dot smscity at gmail dot com
 Summary:session_start()/session_write_close() creates
 multiple session cookies headers
 Status: Not a bug
 Type:   Bug
 Package:Session related
 Operating System:   any
 PHP Version:5.1.4
 Block user comment: N
 Private report: N

 New Comment:

I believe the problem is a missing PHP capability for session handling,without 
which no efficient solution is possible for this problem.

In addition to session_start() and session_write_close(), PHP should have a 
session_write_reopen() function.

This would solve several problems cleanly.

It will allow for those that want fine-grained control over the transaction 
handling/demarcation when accessing session variables, without imposing any 
additional complications on those that just want the default session handling 
behavior.

for example:

at the top of all pages you start your session with:
session_start(); session_write_close(); //no further blocking

//.. rest of long running script execution

//now we only block for tiny fraction of time while manipulating session vars
startSessionTransaction();
$x = $_SESSION['x'];
$x++;
$_SESSION['x] = $x;
endSessionTransaction();
//now we stop block

//... script can continue running tedious operations without blocking others on 
session access 
//...


and the user would then implement these

function startSessionTransaction()
{
  session_write_reopen();
}

function endSessionTransaction()
{
  session_write_close();
}


Now you can only let your session handling part of your script block for the 
tiny parts when a session variable is manipulated, without 
having to completely restart sessions, because restarting sessions later in 
your 
script creates several additional problems as noted - such as creating 
duplicate 
session cookies, and just as annoying, force you to turn on output buffering 
for 
your entire script, since you cannot start (or restart) session's once any 
output has been sent to the browser.

This is the solution required. This is what is missing in PHP session 
functionality. IMNSHO


Previous Comments:

[2011-11-20 05:22:52] danielc at analysisandsolutions dot com

See also https://bugs.php.net/bug.php?id=31455


[2011-11-09 18:34:52] rfunk at funknet dot net

I just ran into this bug in PHP 5.3.5 when working with a script that does lots 
 
of 
session_start()/session_write_close() in a long-running task, so that separate 
requests can still access the 
session during that long task. (Specifically those separate requests are 
checking the progress of the long 
task.)

The resulting absurdly redundant Set-Cookie header caused Firefox 7 to lock up 
for a few seconds, and caused IE8 
to give its infamously useless "Internet Explorer cannot display the webpage" 
page. So this bug is not "Bogus" s 
it claims.

I do have a workaround, however. I'm already doing an ob_start() at the top of 
the script, and now before the 
ending ob_end_flush() I replace the Set-Cookie header with a new one:

  if (SID) header('Set-Cookie: '.SID.'; path=/', true);

After adding this, I no longer have the above problems in Firefox and IE.


[2011-02-04 17:00:58] vdklah at hotmail dot com

I can not tell how much I disagree on this. Calling session_start() followed by 
session_write_close() is a very valid way to avoid blocking multiple processes. 
(See also here http://konrness.com/php5/how-to-prevent-blocking-php-requests/.) 
This problem is huge since we are facing fatal crashing clients due to zillions 
of duplicate PHPSESSID entries in one cookie. Our server is big and complicated 
and so we are not willing to change anything in this area while all is already 
taken in production. Totally stuck on this and I'm not happy. This is a very 
obvious PHP bug that can be proven in 4 lines of code without any client 
intervention.


[2006-07-14 20:46:11] il...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Session is created every time you call session_start(). If you 
want to avoid multiple cookie, write better code. Multiple 
session_start() especially for the same names in the same 
script seems like a really bad idea.


[2006-07-14 10:23:58] m dot v dot veluw dot smscity at gmail dot com

Bug #61713 [Opn->Csd]: ext\standard\tests\strings\htmlentities10.phpt fails

[ab]

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

 ID: 61713
 Updated by: a...@php.net
 Reported by:a...@php.net
 Summary:ext\standard\tests\strings\htmlentities10.phpt fails
-Status: Open
+Status: Closed
 Type:   Bug
 Package:*General Issues
 Operating System:   windows
 PHP Version:5.3.10
-Assigned To:
+Assigned To:ab
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

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




Previous Comments:

[2012-05-08 16:19:39] a...@php.net

Automatic comment on behalf of ab
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=3a4a25358fe3f389c434f68e59bfd70b25b93b29
Log: Fix bug #61713 ext\standard\tests\strings\htmlentities10.phpt fails


[2012-05-08 15:37:59] a...@php.net

Consider the following lines in ext\standard\html.c

== BEGIN ===
ZVAL_STRING(&nm_mb_internal_encoding, "mb_internal_encoding", 0);

if (call_user_function_ex(CG(function_table), NULL, 
&nm_mb_internal_encoding, &uf_result, 0, NULL, 1, NULL TSRMLS_CC) != FAILURE) {

charset_hint = Z_STRVAL_P(uf_result);
len = Z_STRLEN_P(uf_result);

if (len == 4) { /* sizeof(none|auto|pass)-1 */
if (!memcmp("pass", charset_hint, sizeof("pass") - 1) ||
!memcmp("auto", charset_hint, sizeof("auto") - 1) ||
!memcmp("none", charset_hint, sizeof("none") - 1)) {

charset_hint = NULL;
len = 0;
}
}
goto det_charset;
}
}
#endif
#endif

charset_hint = SG(default_charset);
if (charset_hint != NULL && (len=strlen(charset_hint)) != 0) {
goto det_charset;
}
== END ===

As you can see, mbstring.internal_encoding having pass resets charset_hint and 
jumps to det_charset ommiting sapi globals check ... this results iso-8859-1 
being choosed. This all happens only with mbstring compiled as shared.

Fix follows.


[2012-04-13 17:25:06] a...@php.net

no, the previous was wrong ... default_charset gets read ... hm, looking next )


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

Currently the php manual says some wrong things in 
http://de2.php.net/htmlentities about charset:

An empty string activates detection from script encoding (Zend multibyte), 
default_charset and current locale (see nl_langinfo() and setlocale()), in this 
order.

I can see only the following in the code of htmlentities:

* detection of the passed charset
* detection of the mbstring.internal_encoding
* detection of the current locales

The test relies on the default_charset value, which never affects htmlentities. 
This is the reason for bug 61714 and bug 61715 as well.


[2012-04-13 09:01:16] a...@php.net

Description:

Test diff:

002+ string(4) ",+TY"
003+ string(27) "?¢£¤¥"
002- string(28) "‚†™Ÿ"
003- string(32) "€¢£¤¥"

Expected result:

test pass

Actual result:
--
test fail






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

Bug #61714 [Opn->Csd]: ext\standard\tests\strings\htmlentities11.phpt fails

[ab]

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

 ID: 61714
 Updated by: a...@php.net
 Reported by:a...@php.net
 Summary:ext\standard\tests\strings\htmlentities11.phpt fails
-Status: Open
+Status: Closed
 Type:   Bug
 Package:*General Issues
 Operating System:   windows
 PHP Version:5.3.10
-Assigned To:
+Assigned To:ab
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

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

see bug 61713


Previous Comments:

[2012-04-13 09:13:37] a...@php.net

Description:

Test diff:

002+ string(24) "¼½¾"
002- string(20) "ŒœŸ"

Expected result:

test pass

Actual result:
--
test fail






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

Bug #61715 [Opn->Csd]: ext\standard\tests\strings\htmlentities13.phpt fails

[ab]

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

 ID: 61715
 Updated by: a...@php.net
 Reported by:a...@php.net
 Summary:ext\standard\tests\strings\htmlentities13.phpt fails
-Status: Open
+Status: Closed
 Type:   Bug
 Package:*General Issues
 Operating System:   windows
 PHP Version:5.3.10
-Assigned To:
+Assigned To:ab
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

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

see bug 61713


Previous Comments:

[2012-04-13 09:16:02] a...@php.net

Description:

Test diff:

002+ string(42) "¡¢¡£¡¤"
002- string(6) "¡¢¡£¡☼"

Expected result:

test pass

Actual result:
--
test fail






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

[PHP-BUG] Bug #61976 [NEW]: 5.3.13 reports version as 5.3.12

[hajo at csphere dot eu]

From: 
Operating system: Windows
PHP version:  5.3.13
Package:  *General Issues
Bug Type: Bug
Bug description:5.3.13 reports version as 5.3.12

Description:

the constant PHP_RELEASE_VERSION is 12 but should be 13. other constants
like PHP_VERSION could also be affected.

Test script:
---
echo PHP_RELEASE_VERSION;

Expected result:

13

Actual result:
--
12

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

Bug #61976 [Opn]: 5.3.13 reports version as 5.3.12

[hajo at csphere dot eu]

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

 ID: 61976
 User updated by:hajo at csphere dot eu
 Reported by:hajo at csphere dot eu
 Summary:5.3.13 reports version as 5.3.12
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.3.13
 Block user comment: N
 Private report: N

 New Comment:

PHP_VERSION seems to work as expected as it returns 5.3.13


Previous Comments:

[2012-05-08 19:35:33] hajo at csphere dot eu

Description:

the constant PHP_RELEASE_VERSION is 12 but should be 13. other constants like 
PHP_VERSION could also be affected.

Test script:
---
echo PHP_RELEASE_VERSION;

Expected result:

13

Actual result:
--
12






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

[PHP-BUG] Bug #61977 [NEW]: Need CLI web-server support for files with .htm extension

[s...@php.net]

From: sixd
Operating system: All
PHP version:  5.4.3
Package:  Built-in web server
Bug Type: Bug
Bug description:Need CLI web-server support for files with .htm extension

Description:

>From user notes at
http://php.net/manual/en/features.commandline.webserver.php
there should be a MIME type for files with .htm extensions.


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

Bug #61977 [PATCH]: Need CLI web-server support for files with .htm extension

[s...@php.net]

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

 ID: 61977
 Patch added by: s...@php.net
 Reported by:s...@php.net
 Summary:Need CLI web-server support for files with .htm
 extension
 Status: Open
 Type:   Bug
 Package:Built-in web server
 Operating System:   All
 PHP Version:5.4.3
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: php_cli_server.c.patch
Revision:   1336510806
URL:
https://bugs.php.net/patch-display.php?bug=61977&patch=php_cli_server.c.patch&revision=1336510806


Previous Comments:

[2012-05-08 20:51:06] s...@php.net

Description:

>From user notes at http://php.net/manual/en/features.commandline.webserver.php
there should be a MIME type for files with .htm extensions.







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

Bug #61977 [Opn]: Need CLI web-server support for files with .htm & svg extensions

[sixd]

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

 ID: 61977
 Updated by: s...@php.net
 Reported by:s...@php.net
 Summary:Need CLI web-server support for files with .htm &
 svg extensions
 Status: Open
 Type:   Bug
 Package:Built-in web server
 Operating System:   All
 PHP Version:5.4.3
 Block user comment: N
 Private report: N

 New Comment:

Updated patch to include svg too


Previous Comments:

[2012-05-08 21:00:06] s...@php.net

The following patch has been added/updated:

Patch Name: php_cli_server.c.patch
Revision:   1336510806
URL:
https://bugs.php.net/patch-display.php?bug=61977&patch=php_cli_server.c.patch&revision=1336510806


[2012-05-08 20:51:06] s...@php.net

Description:

>From user notes at http://php.net/manual/en/features.commandline.webserver.php
there should be a MIME type for files with .htm extensions.







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

Bug #60977 [Com]: number_format behavior changed when passing \0 for 4th parameter.

[dslgjkdg at hotmail dot com]

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

 ID: 60977
 Comment by: dslgjkdg at hotmail dot com
 Reported by:chobie...@php.net
 Summary:number_format behavior changed when passing \0 for
 4th parameter.
 Status: Assigned
 Type:   Bug
 Package:Math related
 Operating System:   OSX
 PHP Version:5.4.0RC7
 Assigned To:aharvey
 Block user comment: N
 Private report: N

 New Comment:

3 months later, any news on the fix? This bug makes phpredis zadd useless:
https://github.com/nicolasff/phpredis/issues/113


Previous Comments:

[2012-02-06 00:46:14] ahar...@php.net

Ouch, this one's my fault, as it came in with the fix for request #53457 in 
revision 305937. (char) 0 was previously used to signal no separator, whereas 
now the lack of a separator actually signals no separator. Unfortunately, I 
didn't take into account that _php_math_number_format() returns a C string, and 
is hence null-terminated as a result.

The right fix here (which I'll work up and commit to trunk) is to change 
_php_math_number_format() and _php_math_number_format_ex() to return a zval, or 
at least have some other way of signalling the string length to the caller. 
Unfortunately, as this would break the ABI, about the best I can do for 5.4 is 
to emulate the old behaviour when the decimal point or thousands separator 
includes a null byte (which is to ignore it altogether: the 5.3 output doesn't 
actually include any nulls).

I don't think this is going to be considered serious enough to be included in 
5.4.0, given we're in code freeze, but I'll put together a patch and attach it 
here before committing it post-5.4.0.


[2012-02-04 16:58:37] php-dev at zerocue dot com

This is interesting, I would think that the 5_4 functionality is more correct, 
because you're adding a null character as the thousands separator so the string 
is 
becoming: 
1\0328\0370\0011.7238

Internally a null character terminates a C style string.  I would think the 
appropriate fix would be to limit the fourth parameter to displayable 
characters.

This probably changed as a result of a bugfix somewhere.


[2012-02-04 15:58:09] chobie...@php.net

Description:

when I run the test code on php5.3. php returns `1328370011.7238`.
but in php5.4 that returns `1`.

i don't know which behavior is correct. i think it should be returns same 
result.

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

Bug #61976 [Opn->Wfx]: 5.3.13 reports version as 5.3.12

[johannes]

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

 ID: 61976
 Updated by: johan...@php.net
 Reported by:hajo at csphere dot eu
 Summary:5.3.13 reports version as 5.3.12
-Status: Open
+Status: Wont fix
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.3.13
 Block user comment: N
 Private report: N

 New Comment:

This only affects Windows builds and only  PHP_RELEASE_VERSION. PHP_VERSION and 
PHP_VERSION_ID are correct. Unix builds will also pickup the correct version. 
Added this to my release checklist for double checking in future. But we can't 
change released packages easily - unless we make this 5.3.14 ;-)


Previous Comments:

[2012-05-08 19:37:36] hajo at csphere dot eu

PHP_VERSION seems to work as expected as it returns 5.3.13


[2012-05-08 19:35:33] hajo at csphere dot eu

Description:

the constant PHP_RELEASE_VERSION is 12 but should be 13. other constants like 
PHP_VERSION could also be affected.

Test script:
---
echo PHP_RELEASE_VERSION;

Expected result:

13

Actual result:
--
12






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

Bug #60977 [Com]: number_format behavior changed when passing \0 for 4th parameter.

[clowns at hotmail dot com]

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

 ID: 60977
 Comment by: clowns at hotmail dot com
 Reported by:chobie...@php.net
 Summary:number_format behavior changed when passing \0 for
 4th parameter.
 Status: Assigned
 Type:   Bug
 Package:Math related
 Operating System:   OSX
 PHP Version:5.4.0RC7
 Assigned To:aharvey
 Block user comment: N
 Private report: N

 New Comment:

"I don't think this is going to be considered serious enough"

You mean making PHP thinks 100 equals to 1 is not a serious bug? Do you 
know how many extensions/plugins uses number_format on number larger than 999?

What a joke.


Previous Comments:

[2012-05-08 21:35:05] dslgjkdg at hotmail dot com

3 months later, any news on the fix? This bug makes phpredis zadd useless:
https://github.com/nicolasff/phpredis/issues/113


[2012-02-06 00:46:14] ahar...@php.net

Ouch, this one's my fault, as it came in with the fix for request #53457 in 
revision 305937. (char) 0 was previously used to signal no separator, whereas 
now the lack of a separator actually signals no separator. Unfortunately, I 
didn't take into account that _php_math_number_format() returns a C string, and 
is hence null-terminated as a result.

The right fix here (which I'll work up and commit to trunk) is to change 
_php_math_number_format() and _php_math_number_format_ex() to return a zval, or 
at least have some other way of signalling the string length to the caller. 
Unfortunately, as this would break the ABI, about the best I can do for 5.4 is 
to emulate the old behaviour when the decimal point or thousands separator 
includes a null byte (which is to ignore it altogether: the 5.3 output doesn't 
actually include any nulls).

I don't think this is going to be considered serious enough to be included in 
5.4.0, given we're in code freeze, but I'll put together a patch and attach it 
here before committing it post-5.4.0.


[2012-02-04 16:58:37] php-dev at zerocue dot com

This is interesting, I would think that the 5_4 functionality is more correct, 
because you're adding a null character as the thousands separator so the string 
is 
becoming: 
1\0328\0370\0011.7238

Internally a null character terminates a C style string.  I would think the 
appropriate fix would be to limit the fourth parameter to displayable 
characters.

This probably changed as a result of a bugfix somewhere.


[2012-02-04 15:58:09] chobie...@php.net

Description:

when I run the test code on php5.3. php returns `1328370011.7238`.
but in php5.4 that returns `1`.

i don't know which behavior is correct. i think it should be returns same 
result.

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

Bug #61704 [Csd]: Crash apache, phpinfo() threading issue

[ricardo dot nuno dot rodrigues at hotmail dot com]

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

 ID: 61704
 User updated by:ricardo dot nuno dot rodrigues at hotmail dot com
 Reported by:ricardo dot nuno dot rodrigues at hotmail dot com
 Summary:Crash apache, phpinfo() threading issue
 Status: Closed
 Type:   Bug
 Package:MySQLi related
 Operating System:   Windows 7 64bit
 PHP Version:5.4.0
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

trunk version not working
--

Function Arg 1 Arg 2 Arg 3   Source 
php5ts!deflateEnd+f 01bc 0234b7c4 5d7197bd
php5ts!php_version_compare+bf6a 25c3da78 25c3da78 
php5ts!php_request_shutdown+27b 0fd3ff6c  56433230
php5ts!php_request_shutdown+93 26e26bb0 26e26b90 0004
libapr_1!apr_pstrdup+39   




PHP5TS!DEFLATEEND+FWARNING - DebugDiag was not able to locate debug symbols for 
php5ts.dll, so the information below may be incomplete.



In 
httpd__PID__9208__Date__05_08_2012__Time_11_13_15PM__269__Second_Chance_Exceptio
n_C005.dmp the assembly instruction at php5ts!deflateEnd+f in 
C:\AppServ\php5\php5ts.dll from The PHP Group has caused an access violation 
exception (0xC005) when trying to read from memory location 0x01d8 on 
thread 42



Function Arg 1 Arg 2 Arg 3   Source 
php5ts!shmget+17a 0001  
php_shmop_rsr!get_module+1a2 0c7d5398 0eb220d0 0c7d5398
php5ts!zval_add_ref+17b5 0504fe10 0504fb64 
php5ts!execute+1fd 0eb3f458 0c7d5301 0c7d5398
php5ts!zend_execute_scripts+119 0001 0eb3f4e9 0504fb80
user32!PostThreadMessageA+e1 0504ff6c  56433230
php5ts!php_execute_script+a7 764d1194 027c 
KERNELBASE!WaitForSingleObjectEx+cb 0020 609dc7f4 609f2cc6
php5ts!xmlGetGlobalState+11 00888968  014c1738
libhttpd!ap_regexec+d6 00ba9690 014927e7 0504fe30
mod_rewrite+6387 014911d8  014911d8
libhttpd!ap_run_handler+25 014911d8 014911d8 014911d8
libhttpd!ap_invoke_handler+a2  01485330 0504fefc
libhttpd!ap_die+26e 014911d8  00bd4918
libhttpd!ap_psignature+15b2 01485330 0018 01485330
libhttpd!ap_run_process_connection+25 01485330 00c397c8 0504ff44
libhttpd!ap_process_connection+33 01485330 014851b8 
libhttpd!ap_regkey_value_remove+fe7 01485328 9f1b9813 
msvcr100!_endthreadex+3f  0504ff94 764d339a
msvcr100!_endthreadex+ce 01444ce0 0504ffd4 76ef9ef2
kernel32!BaseThreadInitThunk+e 01444ce0 7b64113e 
ntdll!__RtlUserThreadStart+70 730bc59c 01444ce0 
ntdll!_RtlUserThreadStart+1b 730bc59c 01444ce0 




PHP5TS!SHMGET+17AWARNING - DebugDiag was not able to locate debug symbols for 
php5ts.dll, so the information below may be incomplete.



In 
httpd__PID__7336__Date__05_05_2012__Time_12_15_19AM__621__Second_Chance_Exceptio
n_C005.dmp the assembly instruction at php5ts!shmget+17a in 
C:\AppServ\php5\php5ts.dll from The PHP Group has caused an access violation 
exception (0xC005) when trying to read from memory location 0x on 
thread 27


Function Arg 1 Arg 2 Arg 3   Source 
php5ts!zend_register_internal_class_ex+c6d 1fa8ca48 1fa8ca48 

php5ts!php_request_shutdown+27b 0adaff6c  56433230
php5ts!php_request_shutdown+93 13906680 13906660 0004
libapr_1!apr_pstrdup+39   




PHP5TS!ZEND_REGISTER_INTERNAL_CLASS_EX+C6DWARNING - DebugDiag was not able to 
locate debug symbols for php5ts.dll, so the information below may be incomplete.



In 
httpd__PID__7980__Date__05_08_2012__Time_11_15_36PM__79__Second_Chance_Exception
_C005.dmp the assembly instruction at 
php5ts!zend_register_internal_class_ex+c6d in C:\AppServ\php5\php5ts.dll from 
The PHP Group has caused an access violation exception (0xC005) when trying 
to read from memory location 0x6b6abc8d on thread 215


Previous Comments:

[2012-05-08 15:33:21] johan...@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/.

 For Windows:

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




[2012-05-08 15:33:03] johan...@php.net

Autom

Bug #61704 [Csd]: Crash apache, phpinfo() threading issue

[johannes]

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

 ID: 61704
 Updated by: johan...@php.net
 Reported by:ricardo dot nuno dot rodrigues at hotmail dot com
 Summary:Crash apache, phpinfo() threading issue
 Status: Closed
 Type:   Bug
 Package:MySQLi related
 Operating System:   Windows 7 64bit
 PHP Version:5.4.0
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

This is a different issue or you're using a build which is older than my fix. 
If it is a different issue it should get a new bug ID. I don't have Windows at 
hand to test php.net builds right now ... when testing please go from a setup 
without extra extensions and add them till the issue pops up. Thanks.


Previous Comments:

[2012-05-08 22:19:12] ricardo dot nuno dot rodrigues at hotmail dot com

trunk version not working
--

Function Arg 1 Arg 2 Arg 3   Source 
php5ts!deflateEnd+f 01bc 0234b7c4 5d7197bd
php5ts!php_version_compare+bf6a 25c3da78 25c3da78 
php5ts!php_request_shutdown+27b 0fd3ff6c  56433230
php5ts!php_request_shutdown+93 26e26bb0 26e26b90 0004
libapr_1!apr_pstrdup+39   




PHP5TS!DEFLATEEND+FWARNING - DebugDiag was not able to locate debug symbols for 
php5ts.dll, so the information below may be incomplete.



In 
httpd__PID__9208__Date__05_08_2012__Time_11_13_15PM__269__Second_Chance_Exceptio
n_C005.dmp the assembly instruction at php5ts!deflateEnd+f in 
C:\AppServ\php5\php5ts.dll from The PHP Group has caused an access violation 
exception (0xC005) when trying to read from memory location 0x01d8 on 
thread 42



Function Arg 1 Arg 2 Arg 3   Source 
php5ts!shmget+17a 0001  
php_shmop_rsr!get_module+1a2 0c7d5398 0eb220d0 0c7d5398
php5ts!zval_add_ref+17b5 0504fe10 0504fb64 
php5ts!execute+1fd 0eb3f458 0c7d5301 0c7d5398
php5ts!zend_execute_scripts+119 0001 0eb3f4e9 0504fb80
user32!PostThreadMessageA+e1 0504ff6c  56433230
php5ts!php_execute_script+a7 764d1194 027c 
KERNELBASE!WaitForSingleObjectEx+cb 0020 609dc7f4 609f2cc6
php5ts!xmlGetGlobalState+11 00888968  014c1738
libhttpd!ap_regexec+d6 00ba9690 014927e7 0504fe30
mod_rewrite+6387 014911d8  014911d8
libhttpd!ap_run_handler+25 014911d8 014911d8 014911d8
libhttpd!ap_invoke_handler+a2  01485330 0504fefc
libhttpd!ap_die+26e 014911d8  00bd4918
libhttpd!ap_psignature+15b2 01485330 0018 01485330
libhttpd!ap_run_process_connection+25 01485330 00c397c8 0504ff44
libhttpd!ap_process_connection+33 01485330 014851b8 
libhttpd!ap_regkey_value_remove+fe7 01485328 9f1b9813 
msvcr100!_endthreadex+3f  0504ff94 764d339a
msvcr100!_endthreadex+ce 01444ce0 0504ffd4 76ef9ef2
kernel32!BaseThreadInitThunk+e 01444ce0 7b64113e 
ntdll!__RtlUserThreadStart+70 730bc59c 01444ce0 
ntdll!_RtlUserThreadStart+1b 730bc59c 01444ce0 




PHP5TS!SHMGET+17AWARNING - DebugDiag was not able to locate debug symbols for 
php5ts.dll, so the information below may be incomplete.



In 
httpd__PID__7336__Date__05_05_2012__Time_12_15_19AM__621__Second_Chance_Exceptio
n_C005.dmp the assembly instruction at php5ts!shmget+17a in 
C:\AppServ\php5\php5ts.dll from The PHP Group has caused an access violation 
exception (0xC005) when trying to read from memory location 0x on 
thread 27


Function Arg 1 Arg 2 Arg 3   Source 
php5ts!zend_register_internal_class_ex+c6d 1fa8ca48 1fa8ca48 

php5ts!php_request_shutdown+27b 0adaff6c  56433230
php5ts!php_request_shutdown+93 13906680 13906660 0004
libapr_1!apr_pstrdup+39   




PHP5TS!ZEND_REGISTER_INTERNAL_CLASS_EX+C6DWARNING - DebugDiag was not able to 
locate debug symbols for php5ts.dll, so the information below may be incomplete.



In 
httpd__PID__7980__Date__05_08_2012__Time_11_15_36PM__79__Second_Chance_Exception
_C005.dmp the assembly instruction at 
php5ts!zend_register_internal_class_ex+c6d in C:\AppServ\php5\php5ts.dll from 
The PHP Group has caused an access violation exception (0xC005) when trying 
to read from memory location 0x6b6abc8d on thread 215


[2012-05-08 15:33:21] johan...@php.ne

Req #61954 [Opn]: Multi-CASE line for SWITCH

[johannes]

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

 ID: 61954
 Updated by: johan...@php.net
 Reported by:dm at dmillerweb dot com
 Summary:Multi-CASE line for SWITCH
 Status: Open
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   N/A
 PHP Version:5.4.2
 Block user comment: N
 Private report: N

 New Comment:

As said in a comment:

switch ($color) {
   case "blue":
   case "green":
   case "aqua":
  /* ...*/
}

Exists. As a case statement allows arbitrary expressions linking options 
without extra case would be painful. We won't change the language there.


Previous Comments:

[2012-05-06 13:21:48] phristen at yahoo dot com

Or... you could just use an if() ;)


[2012-05-05 22:08:44] anon at anon dot anon

Several other languages do support fancier rules in their switch statements, 
though. One variant of the B language (B being the language which first devised 
the current syntax for the switch statement) allowed ranges such as "case 1 :: 
10" and comparisons such as "case >= 5". Most BASICs allow ranges ("CASE 1 TO 
10"), comparisons ("CASE IS < 5"), and comma-separated values ("CASE 2, 4, 6"). 
Ruby allows comma separated values ("when 2, 4, 6") and ranges ("when 1..10").

It would be useful if PHP supported some of those features.


[2012-05-05 21:45:02] anon at anon dot anon

The standard way to accept multiple case values (in all C-like languages, 
including PHP) is to put multiple case labels. It's not quite as succinct as 
your example, but it does fulfill the purpose of allowing you to only write the 
handlers once:

switch ($color) {
   case "blue":
   case "green":
   case "aqua":
  echo $color . " is a cool color.";
  break;
   case "red": case "orange": case "brown":
  echo $color . " is a warm color.";
  break;
}

Adding { } around those sections is actually already valid syntax, though in 
PHP it does nothing because PHP doesn't have block scope 
(https://en.wikipedia.org/wiki/Scope_%28computer_science%29#Block_scope_within_a_function).
 In some similar languages, that syntax delimits a scope but doesn't imply a 
"break;", so PHP could only add that new logic if it's willing to confuse 
people. It would also break backwards compatibility with any odd code that 
already has extra { } in its switch handlers.


[2012-05-05 20:23:47] dm at dmillerweb dot com

Description:

---
>From manual page: http://www.php.net/control-structures.switch
---
I did not see this capability on the manual page, so please forgive me if such 
an improvement is already in the works.

I believe it would be a great help to upgrade the SWITCH -> CASE statements so 
they accept multiple values. This would allow us to write only one block of 
code-to-be-executed even for multiple values.

Here's an example:

switch ($color) {
   case: "blue", "green", "aqua"
  echo $color . " is a cool color."
  break;
   case: "red", "orange", "brown"
  echo $color . " is a warm color."
}

Also, we could eliminate the need for the BREAK statement by allowing code 
after the CASE statement to be enclosed in braces; the closing brace for that 
code would indicate an automatic BREAK.

Hope this helps.

David Miller








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

Req #61954 [Opn->Nab]: Multi-CASE line for SWITCH

[johannes]

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

 ID: 61954
 Updated by: johan...@php.net
 Reported by:dm at dmillerweb dot com
 Summary:Multi-CASE line for SWITCH
-Status: Open
+Status: Not a bug
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   N/A
 PHP Version:5.4.2
 Block user comment: N
 Private report: N

 New Comment:

.


Previous Comments:

[2012-05-08 23:41:19] johan...@php.net

As said in a comment:

switch ($color) {
   case "blue":
   case "green":
   case "aqua":
  /* ...*/
}

Exists. As a case statement allows arbitrary expressions linking options 
without extra case would be painful. We won't change the language there.


[2012-05-06 13:21:48] phristen at yahoo dot com

Or... you could just use an if() ;)


[2012-05-05 22:08:44] anon at anon dot anon

Several other languages do support fancier rules in their switch statements, 
though. One variant of the B language (B being the language which first devised 
the current syntax for the switch statement) allowed ranges such as "case 1 :: 
10" and comparisons such as "case >= 5". Most BASICs allow ranges ("CASE 1 TO 
10"), comparisons ("CASE IS < 5"), and comma-separated values ("CASE 2, 4, 6"). 
Ruby allows comma separated values ("when 2, 4, 6") and ranges ("when 1..10").

It would be useful if PHP supported some of those features.


[2012-05-05 21:45:02] anon at anon dot anon

The standard way to accept multiple case values (in all C-like languages, 
including PHP) is to put multiple case labels. It's not quite as succinct as 
your example, but it does fulfill the purpose of allowing you to only write the 
handlers once:

switch ($color) {
   case "blue":
   case "green":
   case "aqua":
  echo $color . " is a cool color.";
  break;
   case "red": case "orange": case "brown":
  echo $color . " is a warm color.";
  break;
}

Adding { } around those sections is actually already valid syntax, though in 
PHP it does nothing because PHP doesn't have block scope 
(https://en.wikipedia.org/wiki/Scope_%28computer_science%29#Block_scope_within_a_function).
 In some similar languages, that syntax delimits a scope but doesn't imply a 
"break;", so PHP could only add that new logic if it's willing to confuse 
people. It would also break backwards compatibility with any odd code that 
already has extra { } in its switch handlers.


[2012-05-05 20:23:47] dm at dmillerweb dot com

Description:

---
>From manual page: http://www.php.net/control-structures.switch
---
I did not see this capability on the manual page, so please forgive me if such 
an improvement is already in the works.

I believe it would be a great help to upgrade the SWITCH -> CASE statements so 
they accept multiple values. This would allow us to write only one block of 
code-to-be-executed even for multiple values.

Here's an example:

switch ($color) {
   case: "blue", "green", "aqua"
  echo $color . " is a cool color."
  break;
   case: "red", "orange", "brown"
  echo $color . " is a warm color."
}

Also, we could eliminate the need for the BREAK statement by allowing code 
after the CASE statement to be enclosed in braces; the closing brace for that 
code would indicate an automatic BREAK.

Hope this helps.

David Miller








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

Req #61953 [Opn->Nab]: A function for getting class instances

[johannes]

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

 ID: 61953
 Updated by: johan...@php.net
 Reported by:dev at pp3345 dot de
 Summary:A function for getting class instances
-Status: Open
+Status: Not a bug
 Type:   Feature/Change Request
 Package:Class/Object related
 PHP Version:5.4.2
 Block user comment: N
 Private report: N

 New Comment:

This information is not easily available from the engine and tracking it would 
be quite expensive. If you need it, you can do it using something like this: 
(untested)

$tracked_objects = array(); // Global

class TrackedClass {
public function __construct() {
   $GLOBAL['tracked_objects'][spl_object_hash($this)] = array(
   'class' => get_class($this),
   'stack' => debug_backtrace()
   );
}
public function __destruct() {
   unset($GLOBAL['tracked_objects'][spl_object_hash($this)]);
}
}

Any class you want to track can than be extended from such a class (or use 5.4 
and traits) andyou can inspect $tracked_objects.


Previous Comments:

[2012-05-05 18:36:05] dev at pp3345 dot de

Description:

I'd like to have a function that returns all instances of a given class with 
information about where it was instantiated and referenced. This could really 
help in debugging. A possible implementation could be

get_instances(string $class_name);

or

ReflectionClass::getInstances(string $class_name);







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

Bug #60977 [Asn->Opn]: number_format behavior changed when passing \0 for 4th parameter.

[aharvey]

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

 ID: 60977
 Updated by: ahar...@php.net
 Reported by:chobie...@php.net
 Summary:number_format behavior changed when passing \0 for
 4th parameter.
-Status: Assigned
+Status: Open
 Type:   Bug
 Package:Math related
 Operating System:   OSX
 PHP Version:5.4.0RC7
-Assigned To:aharvey
+Assigned To:
 Block user comment: N
 Private report: N

 New Comment:

I'm sorry, I don't have any time for PHP work for the forseeable future. 
Unassigning myself.

@clowns: Presumably you don't understand the concept of a code freeze.


Previous Comments:

[2012-05-08 21:42:07] clowns at hotmail dot com

"I don't think this is going to be considered serious enough"

You mean making PHP thinks 100 equals to 1 is not a serious bug? Do you 
know how many extensions/plugins uses number_format on number larger than 999?

What a joke.


[2012-05-08 21:35:05] dslgjkdg at hotmail dot com

3 months later, any news on the fix? This bug makes phpredis zadd useless:
https://github.com/nicolasff/phpredis/issues/113


[2012-02-06 00:46:14] ahar...@php.net

Ouch, this one's my fault, as it came in with the fix for request #53457 in 
revision 305937. (char) 0 was previously used to signal no separator, whereas 
now the lack of a separator actually signals no separator. Unfortunately, I 
didn't take into account that _php_math_number_format() returns a C string, and 
is hence null-terminated as a result.

The right fix here (which I'll work up and commit to trunk) is to change 
_php_math_number_format() and _php_math_number_format_ex() to return a zval, or 
at least have some other way of signalling the string length to the caller. 
Unfortunately, as this would break the ABI, about the best I can do for 5.4 is 
to emulate the old behaviour when the decimal point or thousands separator 
includes a null byte (which is to ignore it altogether: the 5.3 output doesn't 
actually include any nulls).

I don't think this is going to be considered serious enough to be included in 
5.4.0, given we're in code freeze, but I'll put together a patch and attach it 
here before committing it post-5.4.0.


[2012-02-04 16:58:37] php-dev at zerocue dot com

This is interesting, I would think that the 5_4 functionality is more correct, 
because you're adding a null character as the thousands separator so the string 
is 
becoming: 
1\0328\0370\0011.7238

Internally a null character terminates a C style string.  I would think the 
appropriate fix would be to limit the fourth parameter to displayable 
characters.

This probably changed as a result of a bugfix somewhere.


[2012-02-04 15:58:09] chobie...@php.net

Description:

when I run the test code on php5.3. php returns `1328370011.7238`.
but in php5.4 that returns `1`.

i don't know which behavior is correct. i think it should be returns same 
result.

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

Bug #61977 [Opn->Csd]: Need CLI web-server support for files with .htm & svg extensions

[laruence]

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

 ID: 61977
 Updated by: larue...@php.net
 Reported by:s...@php.net
 Summary:Need CLI web-server support for files with .htm &
 svg extensions
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Built-in web server
 Operating System:   All
 PHP Version:5.4.3
-Assigned To:
+Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

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




Previous Comments:

[2012-05-08 21:01:03] s...@php.net

Updated patch to include svg too


[2012-05-08 21:00:06] s...@php.net

The following patch has been added/updated:

Patch Name: php_cli_server.c.patch
Revision:   1336510806
URL:
https://bugs.php.net/patch-display.php?bug=61977&patch=php_cli_server.c.patch&revision=1336510806


[2012-05-08 20:51:06] s...@php.net

Description:

>From user notes at http://php.net/manual/en/features.commandline.webserver.php
there should be a MIME type for files with .htm extensions.







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

Bug #38934 [Csd]: move_uploaded_file() cannot read uploaded file outside of open_basedir

[hn dot 58gmso dot jvbhxz36 at gmail dot com]

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

 ID: 38934
 User updated by:hn dot 58gmso dot jvbhxz36 at gmail dot com
 Reported by:hn dot 58gmso dot jvbhxz36 at gmail dot com
 Summary:move_uploaded_file() cannot read uploaded file
 outside of open_basedir
 Status: Closed
 Type:   Bug
-Package:Safe Mode/open_basedir
+Package:*General Issues
 Operating System:   Ubuntu Linux
 PHP Version:5.1.6
 Block user comment: N
 Private report: N

 New Comment:

Go to the exceptional of CHANEL Market, visiting Fashion & Accessories, Chanel 
bags & Chanel pouch, Watches & Fine Jewelry, their latest creations.Full 
information and uncage shipping! 
http://www.shopchanel2012.com/>シャネル  
http://www.shopchanel2012.com/>グッチ バッグ  
http://www.shopchanel2012.com/>シャネル 財布  
シャネル 財布 : http://www.shopchanel2012.com/


Previous Comments:

[2006-10-13 09:50:20] phpbugs at thequod dot de

It seems to have been fixed in CVS for PHP_5_2 and HEAD 
(but not PHP_5_1).
Seems like iliaa has just used the wrong text snippet when 
closing the bug.

Thank you!


[2006-10-13 01:44:46] il...@php.net

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.




[2006-10-03 11:54:20] youza at post dot cz

See this bug -  http://bugs.php.net/bug.php?id=37236
not any response from PHP :-)))


[2006-10-02 20:03:38] phpbugs at thequod dot de

Since when? As far as I understood, you have expected it 
to work like this (when trying to reproduce it).

Also, from older bug reports, it had been fixed to work 
like this again.

Additionally, from a security perspective, it would open 
up the upload_tmp_dir for all processes sharing the same 
php.ini/upload_tmp_dir and you would have to manually set 
it for every vhost where you use open_basedir for to an 
own directory.

If it's supposed to stay a documentation problem, please 
emphasize it in the NEWS/upgrade docs, because as it is 
now (e.g. failing since 5.1.6), it will break all upload 
scripts for hosts that use open_basedir.

IMHO it should work just like expected: PHP should 
internally allow the temporary uploaded file to get stored 
in upload_tmp_dir and should allow move_uploaded_file() to 
move it - PHP should know that it has to make an exception 
here to the regular open_basedir restriction (and it 
seemed to have done so before).


[2006-10-02 09:28:17] tony2...@php.net

Reclassified as docu problem.
upload_tmp_dir must be in open_basedir() to be readable/writable.




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


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

Bug #38934 [Csd]: move_uploaded_file() cannot read uploaded file outside of open_basedir

[z6ax dot iy144ciokg07 at gmail dot com]

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

 ID: 38934
 User updated by:z6ax dot iy144ciokg07 at gmail dot com
 Reported by:z6ax dot iy144ciokg07 at gmail dot com
 Summary:move_uploaded_file() cannot read uploaded file
 outside of open_basedir
 Status: Closed
 Type:   Bug
 Package:*General Issues
 Operating System:   Ubuntu Linux
 PHP Version:5.1.6
 Block user comment: N
 Private report: N

 New Comment:

Prada is it suddenly became popular in the sketch out to skirt the 
era.Delivered to every heyday products of Prada! Prada prize satiated,and Men's 
Prada and Prada overnight bag,you be struck by to touch the bounteousness of 
products from the fashionable outlet.Free shipping purchase,appraisal sale. 
http://www.pradapursejp.com/>プラダ 
http://www.pradapursejp.com/>財布　プラダ 
http://www.pradapursejp.com/>プラダ　バッグ 
 
プラダ　バッグ : http://www.pradapursejp.com/


Previous Comments:

[2012-05-09 04:10:00] hn dot 58gmso dot jvbhxz36 at gmail dot com

Go to the exceptional of CHANEL Market, visiting Fashion & Accessories, Chanel 
bags & Chanel pouch, Watches & Fine Jewelry, their latest creations.Full 
information and uncage shipping! 
http://www.shopchanel2012.com/>シャネル  
http://www.shopchanel2012.com/>グッチ バッグ  
http://www.shopchanel2012.com/>シャネル 財布  
シャネル 財布 : http://www.shopchanel2012.com/


[2006-10-13 09:50:20] phpbugs at thequod dot de

It seems to have been fixed in CVS for PHP_5_2 and HEAD 
(but not PHP_5_1).
Seems like iliaa has just used the wrong text snippet when 
closing the bug.

Thank you!


[2006-10-13 01:44:46] il...@php.net

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.




[2006-10-03 11:54:20] youza at post dot cz

See this bug -  http://bugs.php.net/bug.php?id=37236
not any response from PHP :-)))


[2006-10-02 20:03:38] phpbugs at thequod dot de

Since when? As far as I understood, you have expected it 
to work like this (when trying to reproduce it).

Also, from older bug reports, it had been fixed to work 
like this again.

Additionally, from a security perspective, it would open 
up the upload_tmp_dir for all processes sharing the same 
php.ini/upload_tmp_dir and you would have to manually set 
it for every vhost where you use open_basedir for to an 
own directory.

If it's supposed to stay a documentation problem, please 
emphasize it in the NEWS/upgrade docs, because as it is 
now (e.g. failing since 5.1.6), it will break all upload 
scripts for hosts that use open_basedir.

IMHO it should work just like expected: PHP should 
internally allow the temporary uploaded file to get stored 
in upload_tmp_dir and should allow move_uploaded_file() to 
move it - PHP should know that it has to make an exception 
here to the regular open_basedir restriction (and it 
seemed to have done so before).




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


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

Bug #38934 [Csd]: move_uploaded_file() cannot read uploaded file outside of open_basedir

[xc dot vzxnvnqw9tiuerwefsh29fosdf at gmail dot com]

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

 ID: 38934
 User updated by:xc dot vzxnvnqw9tiuerwefsh29fosdf at gmail dot com
 Reported by:xc dot vzxnvnqw9tiuerwefsh29fosdf at gmail dot com
 Summary:move_uploaded_file() cannot read uploaded file
 outside of open_basedir
 Status: Closed
 Type:   Bug
 Package:*General Issues
 Operating System:   Ubuntu Linux
 PHP Version:5.1.6
 Block user comment: N
 Private report: N

 New Comment:

Our Train Bags Amass Proposal You Piercing Quality Tutor Handbags At The 
Encouraging Price.Up To 88% Off! Coach Poppy Is The One Of The Most 
artistically Designed Series Of Mentor Bag.You Can Buy Cheap High-class Mark 
Bags At The Motor coach Discharge Store. We Promise Exorbitant 
Quality,Unwavering Release!Free Shopping! 
http://www.coachpopoutletjp.com/> コーチ バッグ   
  
http://www.coachpopoutletjp.com/>コーチ ポピー
 
http://www.coachpopoutletjp.com/>コーチ 
コーチ : http://www.coachpopoutletjp.com/


Previous Comments:

[2012-05-09 05:12:41] z6ax dot iy144ciokg07 at gmail dot com

Prada is it suddenly became popular in the sketch out to skirt the 
era.Delivered to every heyday products of Prada! Prada prize satiated,and Men's 
Prada and Prada overnight bag,you be struck by to touch the bounteousness of 
products from the fashionable outlet.Free shipping purchase,appraisal sale. 
http://www.pradapursejp.com/>プラダ 
http://www.pradapursejp.com/>財布　プラダ 
http://www.pradapursejp.com/>プラダ　バッグ 
 
プラダ　バッグ : http://www.pradapursejp.com/


[2012-05-09 04:10:00] hn dot 58gmso dot jvbhxz36 at gmail dot com

Go to the exceptional of CHANEL Market, visiting Fashion & Accessories, Chanel 
bags & Chanel pouch, Watches & Fine Jewelry, their latest creations.Full 
information and uncage shipping! 
http://www.shopchanel2012.com/>シャネル  
http://www.shopchanel2012.com/>グッチ バッグ  
http://www.shopchanel2012.com/>シャネル 財布  
シャネル 財布 : http://www.shopchanel2012.com/


[2006-10-13 09:50:20] phpbugs at thequod dot de

It seems to have been fixed in CVS for PHP_5_2 and HEAD 
(but not PHP_5_1).
Seems like iliaa has just used the wrong text snippet when 
closing the bug.

Thank you!


[2006-10-13 01:44:46] il...@php.net

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.




[2006-10-03 11:54:20] youza at post dot cz

See this bug -  http://bugs.php.net/bug.php?id=37236
not any response from PHP :-)))




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


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

Bug #38934 [Csd]: move_uploaded_file() cannot read uploaded file outside of open_basedir

[ofawc5j0lhd9uab dot 8 at gmail dot com]

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

 ID: 38934
 User updated by:ofawc5j0lhd9uab dot 8 at gmail dot com
 Reported by:ofawc5j0lhd9uab dot 8 at gmail dot com
 Summary:move_uploaded_file() cannot read uploaded file
 outside of open_basedir
 Status: Closed
 Type:   Bug
 Package:*General Issues
 Operating System:   Ubuntu Linux
 PHP Version:5.1.6
 Block user comment: N
 Private report: N

 New Comment:

Conventional Celine Gear offers lower off. Celine Case and Cheap Celine Online 
bid a not on target order of bags. Sought-after Celine products are in the 
trading figure and with at no cost shipping! 
http://www.celinebagstorejp.com/>セリーヌ ラゲージ 
http://www.celinebagstorejp.com/>Celine バッグ 
http://www.celinebagstorejp.com/>バッグ セリーヌ 
バッグ セリーヌ : http://www.celinebagstorejp.com/


Previous Comments:

[2012-05-09 05:26:14] xc dot vzxnvnqw9tiuerwefsh29fosdf at gmail dot com

Our Train Bags Amass Proposal You Piercing Quality Tutor Handbags At The 
Encouraging Price.Up To 88% Off! Coach Poppy Is The One Of The Most 
artistically Designed Series Of Mentor Bag.You Can Buy Cheap High-class Mark 
Bags At The Motor coach Discharge Store. We Promise Exorbitant 
Quality,Unwavering Release!Free Shopping! 
http://www.coachpopoutletjp.com/> コーチ バッグ   
  
http://www.coachpopoutletjp.com/>コーチ ポピー
 
http://www.coachpopoutletjp.com/>コーチ 
コーチ : http://www.coachpopoutletjp.com/


[2012-05-09 05:12:41] z6ax dot iy144ciokg07 at gmail dot com

Prada is it suddenly became popular in the sketch out to skirt the 
era.Delivered to every heyday products of Prada! Prada prize satiated,and Men's 
Prada and Prada overnight bag,you be struck by to touch the bounteousness of 
products from the fashionable outlet.Free shipping purchase,appraisal sale. 
http://www.pradapursejp.com/>プラダ 
http://www.pradapursejp.com/>財布　プラダ 
http://www.pradapursejp.com/>プラダ　バッグ 
 
プラダ　バッグ : http://www.pradapursejp.com/


[2012-05-09 04:10:00] hn dot 58gmso dot jvbhxz36 at gmail dot com

Go to the exceptional of CHANEL Market, visiting Fashion & Accessories, Chanel 
bags & Chanel pouch, Watches & Fine Jewelry, their latest creations.Full 
information and uncage shipping! 
http://www.shopchanel2012.com/>シャネル  
http://www.shopchanel2012.com/>グッチ バッグ  
http://www.shopchanel2012.com/>シャネル 財布  
シャネル 財布 : http://www.shopchanel2012.com/


[2006-10-13 09:50:20] phpbugs at thequod dot de

It seems to have been fixed in CVS for PHP_5_2 and HEAD 
(but not PHP_5_1).
Seems like iliaa has just used the wrong text snippet when 
closing the bug.

Thank you!


[2006-10-13 01:44:46] il...@php.net

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.






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


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