Re: [PHP-DEV] Cast trap with INI entries compiling C++ extension
I finally managed to submit the patch... I used iceweasel 6.0.2
instead of Google Chrome 14.0.835.186... or maybe the captcha was just
in a better mood!
The link to the bug report: https://bugs.php.net/bug.php?id=55835
Yours,
--
Olivier Favre
Software engineer
Yakaz
www.yakaz.com
2011/9/30 Olivier Favre oliv...@yakaz.com
I keep on having the following error:
ERROR:
⋅ Incorrect Captcha
while trying to file a bug on the following page:
https://bugs.php.net/report.php
(Debian sid, Google Chrome 14.0.835.186)
I tried flushing my cookies.
There are two opened bug reports about that:
- https://bugs.php.net/bug.php?id=54380
- https://bugs.php.net/bug.php?id=53255
And I would have liked to file another... if only I could!
Anyway, if someone else is luckier, here what I'd have liked to file:
PHP version: 5.3.8
Package affected: Compile issues/Compilation warning
Bug type: Feature/Change request
OS: All (seen under Linux)
Summary: char* field should be const char* to avoid C++ warning
Description:
http://news.php.net/php.internals/55662
I'm writing a C++ extension to PHP.
When declaring a INI entry I get the following warning, multiple times:
warning: deprecated conversion from string constant to 'char*'
[-Wwrite-strings]
This only arises when compiling with a C++ compiler.
The right and easy fix seems to set some fields to const char *.
Some may even be set to const char * const (but this alternative seems
to be used
nowhere).
The proposed patch is against the php5-dev-5.3.8-2 package of debian sid:
PHP 5.3.8-2 with Suhosin-Patch (cli) (built: Sep 12 2011 07:28:26)
- - -
Test script:
Write a C++ extension:
config.m4 should contain PHP_REQUIRE_CXX().
Declare your module:
zend_module_entry quezako_module_entry = {
STANDARD_MODULE_HEADER,
YourExtensionName, // (1 warning here)
[...],
0.42, // (1 warning here)
[...],
STANDARD_MODULE_PROPERTIES_EX
};
Declare an INI entry:
PHP_INI_BEGIN()
STD_PHP_INI_ENTRY(
extensionName.variable, // (1 warning here)
default value, // (1 warning here)
[...]
)
PHP_INI_END()
- - -
Patch name: field_constness_cpp_compilation_warning_fix.patch
Patch file: (see attached file)
Expected result:
No compilation warning.
- - -
Actual result:
Multiple of the following warning:
warning: deprecated conversion from string constant to 'char*'
[-Wwrite-strings]
Using the very common fix of prepending (char*) to the string constant is
especially harmful here, because of ZEND_INI_ENTRY3_EX using sizeof() on in:
it
returns 4/8 (32/64bits platform).
Using a cast to char[] solves the problem, but the above fix is a very very
common mistake.
If the target fields were const char*, no compilation warning would be rose.
- - -
Solve the problem 17 + 23 = ?: 40 (I even checked the answer using a
calculator)
Submit: Send bug report (I'm going mad, really...)
--
Olivier Favre
Software engineer
Yakaz
www.yakaz.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cast trap with INI entries compiling C++ extension
there was a problem with bugs.php.net, so the captcha error was on our end. thanks for the report On Mon, Oct 3, 2011 at 10:01 AM, Olivier Favre oliv...@yakaz.com wrote: I finally managed to submit the patch... I used iceweasel 6.0.2 instead of Google Chrome 14.0.835.186... or maybe the captcha was just in a better mood! -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about ABI compatibility for an ext/xsl patch and an API question for the implementation
On 27.09.11 07:03, Christian Stocker wrote:
Hi again
I just had the idea for a 4th option. Won't be less controversy, but
it's backwards and forwards compatible.
4) use a php ini setting in PHP 5.3
So, here's a patch for PHP_5_3 with this approach
https://gist.github.com/1259520
can anyone confirm, that this is ok to be put in PHP_5_3 branch?
(regarding ABI change and maybe similar issues I was not thinking about)
chregu
I know, we try to avoid that as much as possible. BUT
* It will only be in 5.3, not even committed to 5.4
* If you don't have the ini setting, your XSLT can't write files, the
error will be pretty obvious. If you just read and transform, nothing
will or has to change
* Only a very very very small fraction will need to set this ini setting
The code for enable writing again, which would work in 5.0 - 5.4+ looks
like this. With my first proposal, I'd need much more if/else to make my
code work on 5.3.8-/5.3.9+/5.4+
***
$xsl = new XSLTProcessor();
//if you want to write from within the XSLT
$oldvalini = ini_set(xsl_security_prefs,XSL_SECPREFS_NONE);
if (version_compare(PHP_VERSION,'5.4',=)) {
$oldval = $xsl-setSecurityPreferences(XSL_SECPREFS_NONE);
}
$xsl-transformToXml(...);
//go back to the old setting. Better safe than sorry
ini_set(xsl_security_prefs,$oldvalini);
if (version_compare(PHP_VERSION,'5.4',=)) {
$xsl-setSecurityPreferences($oldval);
}
***
chregu
On 26.09.11 19:59, Christian Stocker wrote:
Hi
Some weeks ago I wrote a patch to disable writing from within XSLT
templates. That patch is now in 5.4 but wasn't accepted in PHP 5.3 since
it changed a struct in the header file.
I have now I new patch which doesn't need that changing in the struct,
but I need a new .h file from libxslt.
https://gist.github.com/3d3d3c3418236f748118 (unfinished patch, just a
proof of concept, but the basics are there)
Can anybody tell me, if that still breaks binary compatibility for
extensions or if that would be ok?
Then a more general question:
There are now 2 ways to enable write access again (in 5.4). Via an
additional optional parameter to the transform methods (this works with
the patch above in 5.3 also) or via the new 5.4 only method
-setSecurityPrefs(). The former is from a clean API point of view not
nice, adding more and more optional parameters to methods is the ticket
to hell usually. But I can't come up with a better solution for 5.3
without breaking the ABI. And since it's somehow a security issue, I
would sleep better a lot, if we have a proper patch for 5.3 as well.
To keep BC, I can't just delete the optional parameter again for 5.4,
that would make portable code a pain. OTOH, the way I did it know, it
breaks BC with PHP 5.3.9, if you want to enable write access in xslt
templates in PHP 5.3.9+. If you don't need that, which is maybe 99.9% of
all cases, BC is kept for since PHP 5.0 until much after PHP 5.4 :)
So there are 3 options
1) leave it like it is currently. No write protection in 5.3, only in 5.4
2) Have 2 ways to enable write access from 5.3.9+ and 5.4.
3) Remove the -setSecurityPrefs() in 5.4, so there's only one way to
enable write access again, but it's the nasty one from a clean API POV.
For 2) and 3), code with those new options won't work anymore in 5.3.8-
(but you can check it in PHP user land and treat it differently), but
you get write protection automatically
Again, all this will only affect a very small fraction of users, those
who legitimately wrote files from within XSLT.
Any opinions? Me personally would like to have it in PHP 5.3 (or at
least offer a proper patch).
chregu
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] zend memory managment null pointer dereference
Hi,
I have recently seen httpd core dump on my system. After looking into this
issue it is the php module which is actually core dumping more specifically the
zend memory management part of php.
#0 0x0115d224 in zend_mm_remove_from_free_list (heap=0x99596e8,
p=value optimized out)
at
/scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_alloc.c:837
The following line is failing in zend_mm_remove_from_fee_list which is in
zend_alloc.c
#if ZEND_MM_SAFE_UNLINKING
if (UNEXPECTED(prev-next_free_block != mm_block) ||
UNEXPECTED(next-prev_free_block != mm_block)) {
zend_mm_panic(zend_mm_heap corrupted);
}
#endif
The core file tells me that next pointer is null so this is crashing when
trying to dereference a null pointer. My first question is next ever expected
to be null? After looking through the code, it seems that if there is only one
element in the list that next prev will be both equal to mm_block, is this a
true assumption?
I am not sure what has gotten my system into this state the only hints I have
is that there were a fair amount of objects created and an init 6 was sent and
during the shut down of the php module this issue was seen.
I have done some investigation into this issue and came across a fairly long
bug report https://bugs.php.net/bug.php?id=40479. However I am not sure if
this is the same issue since I never see the zend_mm_heap corrupted message
since the code fails due to the null pointer dereference before outputting this
error message however this may be related in the fact that my heap is being
corrupted.
Since I do not have a solid reproducer or know why my heap is in this state. I
was wondering if I could get some information to help me debug this. Do you
have any hunches on what could be setting next to null? What does it mean when
next is null is this because the list is at the end or is this a dangling
pointer and next should never be null? Do you have any hints on a possible
reproducer using just php which would put me into the state where next is null?
Also during my research on similar issues I have read that cache may have a
role in causing the heap to be corrupted. How could the cache be corrupting
the heap? Is that possible?
My current version of php is:
PHP 5.2.17 (cli) (built: Aug 2 2011 13:33:29)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans
I am running centos 5.6 and this issue has been seen on both 32 bit and 64 bit.
Also this issue has been seen only after upgrading from php 5.2.6 to 5.2.17.
Do you know of a change made between these releases that could have an affect
on the memory management?
Thread 1 (Thread 30656):
#0 0x0115d224 in zend_mm_remove_from_free_list (heap=0x99596e8,
p=value optimized out)
at
/scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_alloc.c:837
#1 _zend_mm_free_int (heap=0x99596e8, p=value optimized out)
at
/scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_alloc.c:1979
#2 0x0117965a in _zval_dtor_func (zvalue=0x9a2e300)
at
/scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_variables.c:43
#3 0x0116c388 in _zval_dtor (zval_ptr=0x9d60ae0)
at
/scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_variables.h:35
#4 _zval_ptr_dtor (zval_ptr=0x9d60ae0)
at
/scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_execute_API.c:414
#5 0x01184d77 in zend_hash_destroy (ht=0x9d5ecfc)
at
/scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_hash.c:526
#6 0x0117050d in destroy_zend_class (pce=0x9eaf7b4)
at
/scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_opcode.c:185
#7 0x01184d77 in zend_hash_destroy (ht=0x99599b0)
at
/scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_hash.c:526
#8 0x0117a09e in zend_shutdown ()
at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend.c:736
#9 0x01131f35 in php_module_shutdown ()
at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/main/main.c:1918
#10 0x01131ff7 in php_module_shutdown_wrapper (sapi_globals=0x12849e0)
at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/main/main.c:1889
#11 0x01202211 in php_apache_child_shutdown (tmp=0x0)
at
/scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/sapi/apache2handler/sapi_apache2.c:369
#12 0x00cdbe8d in ?? () from /usr/lib/libapr-1.so.0
#13 0x00cdc63d in apr_pool_destroy () from /usr/lib/libapr-1.so.0
#14 0x003909e5 in ?? ()
#15 0x00390a0d in ?? ()
#16 signal handler called
#17 zend_hash_destroy (ht=0xa42b9a8)
at
/scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_hash.c:522
Thanks,
Alan
Re: [PHP-DEV] zend memory managment null pointer dereference
On 10/03/2011 11:42 PM, Chester, Alan wrote: Hi, I have recently seen httpd core dump on my system. After looking into this issue it is the php module which is actually core dumping more specifically the zend memory management part of php. #0 0x0115d224 in zend_mm_remove_from_free_list (heap=0x99596e8, p=value optimized out) at /scratchpad/workdirs/ssilva/build/RPM/BUILD/php-5.2.17/Zend/zend_alloc.c:837 This is the worst kind of segfault since GDB backtrace doesn't carry any useful information in this case, it just tells us that the crash has happened at the request shutdown. But the real problem that caused the crash has occurred somewhere during the request and there's no way to know when where basing on the backtrace only. I'd suggest to try reproducing this problem with Valgrind: https://bugs.php.net/bugs-getting-valgrind-log.php, this would give us a lot more info. -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend memory managment null pointer dereference
On 10/04/2011 12:06 AM, Chester, Alan wrote: Antony, Thank you for the quick response. I will work towards finding a reproducer and using valgrind to gather more information. Since I have been trying for to find a reproducer but have had no luck so far, do you think reducing the cache size would help in finding a reproducer? If so how is this done? Or does cache/cache size have nothing to do with this area of code? Reducing the cache size will not help for sure, but disabling the cache entirely will help us to understand whether this problem is caused by your cache or not. Btw, you didn't specify which kind of cache is that. Also would you like to me open a bug ticket to track this issue? It depends on the kind of cache you're using (there are several caches on the market that aren't part of PHP project) and whether the cache is guilty or not. -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug with static property access
Hello,
I noticed the following odd behavior earlier today, there is
definitely a bug here in my opinion, the bug is either the error
message or the behavior. I think the behavior is possibly expected.
I'll let some others comment.
The reason I think the error is odd is because it is very misleading
in a much larger code base (what I was debugging) you go to the line
it is complaining about and are perplexed because you are not
attempting to access the mentioned constant. I'm sure the engine does
some kind of lazy/runtime determination that causes this, that area
may need a look at?
Example:
?php
abstract class ClassA {
static protected $_cache = Array();
public $version = self::VERSION;
final static public function MethodOne() {
return __METHOD__;
}
final static public function MethodTwo() {
self::$_cache;
return __METHOD__;
}
}
abstract class ClassB extends ClassA {
const VERSION = 1;
}
var_dump(ClassB::MethodOne());
var_dump(ClassB::MethodTwo());
?
// prints
string(17) ClassA::MethodOne
Fatal error: Undefined class constant 'self::VERSION' in
SNIP/testbug.php on line 14
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
