<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Wed, 22 May 2013 22:16:08 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Derick Rethans' Blog: Valgrinding shared modules]]></title>
      <guid>http://www.phpdeveloper.org/news/16689</guid>
      <link>http://www.phpdeveloper.org/news/16689</link>
      <description><![CDATA[<p>
In the process of some development he's been doing on various shared modules for PHP, <i>Derick Rethans</i> <a href="http://derickrethans.nl/valgrinding-shared-modules.html">stumbled across an issue</a> with using <a href="http://valgrind.org/">Valgrind</a> to test his code:
</p>
<blockquote>
While testing whether I correctly free all memory with <a href="http://valgrind.org/">Valgrind</a>, I ran into the issue where I couldn't see the stack frames of where the memory leaks occurred in the extensions, and once I even ran into a <a href="https://bugs.kde.org/show_bug.cgi?id=277045">Valgrind bug</a>. The reason why Valgrind could not show the function names belonging to the stack frames is because PHP had already unloaded the shared extensions from memory.
</blockquote>
<p>
A work-around he found was compiling the modules, but he wanted something "more correct" and less of a hassle. As a result he added a check for the ZEND_DONT_UNLOAD_MODULES environment flag to the PHP core to handles this case specifically. He includes a snippet of example code showing the Valgrind results with and without the flag.
</p>]]></description>
      <pubDate>Mon, 08 Aug 2011 14:35:20 -0500</pubDate>
    </item>
  </channel>
</rss>
