<?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>Sat, 18 May 2013 14:31:41 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Lars Strojny's Blog: PHP Segfaulting with PECL/UUID and PECL/IMAGICK]]></title>
      <guid>http://www.phpdeveloper.org/news/15098</guid>
      <link>http://www.phpdeveloper.org/news/15098</link>
      <description><![CDATA[<p>
If you've been using (or will be using) the <a href="http://usrportage.de/archives/pecl/uuid">uuid</a> and <a href="http://usrportage.de/archives/pecl/imagick">imagick</a> extensions for PHP, you might be able to save yourself a lot of headache by reading <a href="http://usrportage.de/archives/922-PHP-segfaulting-with-pecluuid-and-peclimagick.html">this new post</a> from <i>Lars Strojny</i> about his segfault woes.
</p>
<blockquote>
Ran into a bug yesterday, where <a href="http://usrportage.de/archives/pecl/uuid">http://pecl.php.net/uuid</a> in combination with <a href="http://usrportage.de/archives/pecl/imagick">http://pecl.php.net/imagick</a> yielded a segfault when using uuid_create().
</blockquote>
<p>
After trying to trace it down with a backtrace and cachegrind results, he (and <a href="http://valokuva.org/">Mikko</a> & <a href="http://blog.thepimp.net/">Pierre</a>) found that both extensions were built against the libuuid.so.1 file. While that wasn't the issue directly, they did find a work-around that helped the issue - renaming some ini files so uuid was loaded first.
</p>]]></description>
      <pubDate>Wed, 08 Sep 2010 14:17:13 -0500</pubDate>
    </item>
  </channel>
</rss>
