Valgrind is a suite of tools including a memory usage error checker and a performance measurement tool. It's also a very convenient way of getting a stack trace for when programs segfault.
The simplest use for valgrind is to generate a stack trace.
Running a test PHP script through valgrind with the command valgrind php segfault_example.php gives this output:
==63== Process terminating with default action of signal 11 (SIGSEGV)
==63== at 0x6B5E317: kill (syscall-template.S:84)
==63== by 0x12376C32: ??? (in /usr/lib/php/20190902/posix.so)
==63== by 0xA8A143C: xdebug_execute_internal (base.c:883)
==63== by 0x1EBF83: ??? (in /usr/bin/php7.4)
==63== by 0x424AAF: execute_ex (in /usr/bin/php7.4)
==63== by 0xA8A0BE6: xdebug_execute_ex (base.c:765)
==63== by 0x1EBF1D: ??? (in /usr/bin/php7.4)
==63== by 0x424AAF: execute_ex (in /usr/bin/php7.4)
==63== by 0xA8A0BE6: xdebug_execute_ex (base.c:765)
==63== by 0x42B862: zend_execute (in /usr/bin/php7.4)
==63== by 0x39D2B2: zend_execute_scripts (in /usr/bin/php7.4)
==63== by 0x339A4F: php_execute_script (in /usr/bin/php7.4)
==63==
Valgrind detects many types of errors related to memory allocation or usage that are common bugs in C/C++ programs.
This is really useful when developing PHP extensions as it can help track down bugs in your code.
==13745== Conditional jump or move depends on uninitialised value(s)
==13745== at 0x4F14676: DistortImage (quantum.h:92)
==13745== by 0x5589D47: MogrifyImage (mogrify.c:1428)
==13745== by 0x558D22A: MogrifyImages (mogrify.c:8848)
==13745== by 0x550FCBB: ConvertImageCommand (convert.c:3239)
==13745== by 0x55B2BDF: MagickCommandGenesis (mogrify.c:168)
==13745== by 0x400984: main (convert.c:81)
This error message is telling us that a bit of code is reading from a memory location that has been allocated, but not written to. Which means the value read will be a random piece of data.
One of the common problems with PHP extension is forgetting to free memory. The memcheck part of valgrind will
==19200== 1 bytes in 1 blocks are still reachable in loss record 1 of 90
==19200== at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
==19200== by 0x6CE8091: strdup (strdup.c:43)
==19200== by 0x54AF652: el_init (in /usr/lib/x86_64-linux-gnu/libedit.so.2.11)
==19200== by 0x54A2C8C: rl_initialize (in /usr/lib/x86_64-linux-gnu/libedit.so.2.11)
==19200== by 0x72F468: zm_startup_readline (in /usr/bin/php5)
==19200== by 0x69919D: zend_startup_module_ex (in /usr/bin/php5)
==19200== by 0x6A5253: zend_hash_apply (in /usr/bin/php5)
==19200== by 0x69CE99: zend_startup_modules (in /usr/bin/php5)
==19200== by 0x64530F: php_module_startup (in /usr/bin/php5)
==19200== by 0x72F72C: php_cli_startup (in /usr/bin/php5)
==19200== by 0x42B217: main (in /usr/bin/php5)
==19200==
==19200== 1 bytes in 1 blocks are still reachable in loss record 2 of 90
==19200== at 0x4C279F2: calloc (vg_replace_malloc.c:467)
==19200== by 0x54A2AF5: rl_initialize (in /usr/lib/x86_64-linux-gnu/libedit.so.2.11)
==19200== by 0x72F468: zm_startup_readline (in /usr/bin/php5)
==19200== by 0x69919D: zend_startup_module_ex (in /usr/bin/php5)
==19200== by 0x6A5253: zend_hash_apply (in /usr/bin/php5)
==19200== by 0x69CE99: zend_startup_modules (in /usr/bin/php5)
==19200== by 0x64530F: php_module_startup (in /usr/bin/php5)
==19200== by 0x72F72C: php_cli_startup (in /usr/bin/php5)
==19200== by 0x42B217: main (in /usr/bin/php5)
The full capabilities of memcheck are quite complex. Reading the fine valgrind manual is recommended.
The PHP test suite can use php runtests.php -m
https://bugs.php.net/bugs-getting-valgrind-log.php
The full detail
--track-origins=yes
Valgrind can be used to measure the number of instructions run by a program. Note, this is not strictly an accurate measurement of performance, but is usually a good indicator of whether a change will be slower or faster.
For example, for the Closure::fromCallable RFC I made two scrips that use either Closure or callable as the parameter type.
# valgrind --tool=callgrind php perf_callable.php
==47== Callgrind, a call-graph generating cache profiler
==47== Copyright (C) 2002-2015, and GNU GPL'd, by Josef Weidendorfer et al.
==47== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==47== Command: php perf_callable.php
==47==
==47== For interactive control, run 'callgrind_control -h'.
OK==47==
==47== Events : Ir
==47== Collected : 116136383
==47==
==47== I refs: 116,136,383
# valgrind --tool=callgrind php perf_closure.php
==48== Callgrind, a call-graph generating cache profiler
==48== Copyright (C) 2002-2015, and GNU GPL'd, by Josef Weidendorfer et al.
==48== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==48== Command: php perf_closure.php
==48==
==48== For interactive control, run 'callgrind_control -h'.
OK==48==
==48== Events : Ir
==48== Collected : 96614788
==48==
==48== I refs: 96,614,788
| Measurement | Instructions |
|---|---|
| Callable | 116,136,383 |
| Closure | 96,614,788 |
| Difference | 19,521,595 |
i.e. using callgrind we can see that using callable as the parameter type instead of Closure is about 20% slower.
Note, callgrind measurements should probably be done without Xdebug enabled, as it seems to drastically increase the number of instructions that are run for the same PHP script.
zend_string_equal_val ?If you run valgrind on most PHP programs, you will almost certainly see something like:
==227== Conditional jump or move depends on uninitialised value(s)
==227== at 0x3C6D12: zend_string_equal_val (in /usr/bin/php7.4)
==227== by 0x3C7026: ??? (in /usr/bin/php7.4)
==227== by 0x3A264F: ??? (in /usr/bin/php7.4)
==227== by 0x13E9F4E4: ??? (in /usr/lib/php/20190902/xmlreader.so)
==227== by 0x3A0744: zend_startup_module_ex (in /usr/bin/php7.4)
==227== by 0x3A07CB: ??? (in /usr/bin/php7.4)
==227== by 0x3ADD11: zend_hash_apply (in /usr/bin/php7.4)
==227== by 0x3A0A89: zend_startup_modules (in /usr/bin/php7.4)
==227== by 0x338FCA: php_module_startup (in /usr/bin/php7.4)
==227== by 0x42C58C: ??? (in /usr/bin/php7.4)
==227== by 0x1F4843: ??? (in /usr/bin/php7.4)
==227== by 0x6B4B2E0: (below main) (libc-start.c:291)
repeated many times in the output. This apparently is a false positive.
It should be possible to avoid this false detection, by compiling PHP on a system where valgrind is available, and maybe forcing --with-valgrind to ensure it is detected, which then does some magic.
An easier way of suppressing valgrind errors is to tell valgrind to suppress them. There is an example suppression file in this project, and a script that wraps invocation of valgrind, which are setup in the debug PHP container for this project.
However it may also be convenient to add valgrind suppressions to CI tools, in which case generating a suppression file like this:
- echo "{" >> $HOME/default.supp
- echo "String_Equality_Intentionally_Reads_Uninit_Memory" >> $HOME/default.supp
- echo "Memcheck:Cond" >> $HOME/default.supp
- echo "fun:zend_string_equal_val" >> $HOME/default.supp
- echo "}"
And wrapping calls to valgrind with something like this:
- echo "#!/bin/bash" > $HOME/bin/valgrind
- echo "/usr/bin/valgrind --suppressions=$HOME/default.supp \$@" >> $HOME/bin/valgrind
- chmod +x $HOME/bin/valgrind
May be useful.