Le 09/11/2015 16:41, Dan Ackroyd a écrit :
On 6 November 2015 at 00:08, François Laupretre <franc...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
