Description:
------------
Discovered this while checking for leaks in my own changes. It always happens, even with an empty script.

90 bytes are definitely lost, plus 7+ kbytes still reachable that I'm not reporting here (overlong list).

Reproduce code:
---------------
# valgrind --tool=memcheck --num-callers=30 --leak-check=full sapi/cli/php < /dev/null

Expected result:
----------------
No leaks

Actual result:
--------------
==18400== HEAP SUMMARY:
==18400==     in use at exit: 7,750 bytes in 33 blocks
==18400==   total heap usage: 36,914 allocs, 36,881 frees, 4,687,551 bytes allocated
==18400== 
==18400== 90 bytes in 2 blocks are definitely lost in loss record 28 of 32
==18400==    at 0x4C2524D: realloc (vg_replace_malloc.c:476)
==18400==    by 0x721D10: OnUpdateUTF8String (zend_ini.c:694)
==18400==    by 0x722AAA: zend_register_ini_entries (zend_ini.c:215)
==18400==    by 0x5937B9: zm_startup_session (session.c:2006)
==18400==    by 0x70CC08: zend_startup_module_ex (zend_API.c:1929)
==18400==    by 0x71525B: zend_hash_apply (zend_hash.c:873)
==18400==    by 0x70CA1B: zend_startup_modules (zend_API.c:1978)
==18400==    by 0x69EBC9: php_module_startup (main.c:2157)
==18400==    by 0x7A37EC: php_cli_startup (php_cli.c:407)
==18400==    by 0x7A412A: main (php_cli.c:781)
==18400== 
==18400== LEAK SUMMARY:
==18400==    definitely lost: 90 bytes in 2 blocks
==18400==    indirectly lost: 0 bytes in 0 blocks
==18400==      possibly lost: 0 bytes in 0 blocks
==18400==    still reachable: 7,660 bytes in 31 blocks
==18400==         suppressed: 0 bytes in 0 blocks