Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89286
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
To: Dan Ackroyd <danack@basereality.com>
References: <563BEF66.4050202@php.net>
 <CA+kxMuRJKthkHL9_cXb5ioZSjU1rcOKW-5NbmUGtHtNJApGkmw@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>, Dmitry Stogov <dmitry@zend.com>
Message-ID: <564FC498.2040300@php.net>
Date: Sat, 21 Nov 2015 02:10:48 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CA+kxMuRJKthkHL9_cXb5ioZSjU1rcOKW-5NbmUGtHtNJApGkmw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] PHP 7 : Cannot use stream wrappers during MINIT
From: francois@php.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=)



Le 09/11/2015 16:41, Dan Ackroyd a écrit :
> On 6 November 2015 at 00:08, François Laupretre <francois@php.net> wrote:
>> Hi,
>>
>> 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 setting
> `export USE_ZEND_ALLOC=0` to 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

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çois