Re: PHP 7 : Cannot use stream wrappers during MINIT
| From: | François Laupretre | Date: | Sat, 21 Nov 2015 01:10:48 +0000 |
| Subject: | Re: PHP 7 : Cannot use stream wrappers during MINIT | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-89286@lists.php.net to get a copy of this message | ||
Le 09/11/2015 16:41, Dan Ackroyd a écrit :
On 6 November 2015 at 00:08, François Laupretre <francois@php.net> wrote:Your method works for dynamically allocated data but, in my case, the uninitialized HashTable is EG(regular_list), which is not dynamically allocated in non-ZTS mode. For data coming from the data or bss sections of the executable, I think that valgrind cannot detect anything (not sure for bss, not tested). The problem with uninitialized hash struct is that, for various reasons, the issue may remain unnoticed during a long time before the final crash and, because of this delay, it is quite hard to go back to the primary cause. That's why I propose to add an assert. This is not perfect but, in many cases, this will avoid the program to return happily from a failed operation on an uninitialized hash. Regards FrançoisHi, An uninitialized HashTable generally is filled with 0s. Today, using an uninitialized HashTable goes undetected, even in debug mode (because HT_OK == 0), and is very hard to track.Uninitialized variables should be pretty easy to check by settingexport USE_ZEND_ALLOC=0to make allocs go straight through to malloc and then running the program through valgrind. That should report all uninitialized data. Additionally using the --malloc-fill=255 (or appropriate value) should make the code blow up pretty quickly. I'd be interested to know if that's doesn't report the issues for you - as that's the backup to check that I haven't forgotten to initialize anything, and if that's not reliable....I might need to check some stuff. cheers Dan