>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #2522966. --> Reported by: [das-peter](https://www.drupal.org/user/762870) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>I just update to the latest redis code which uses the new EVAL functionality. Unfortunately after the update the whole site was broken.<br> All I got was: <code>Segmentation fault (core dumped)</code><br> So I debugged the core with <a href="http://sysadmin.carlusgg.com/?p=197">gdb</a>:</p> <pre>[Thread debugging using libthread_db enabled]<br>Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".<br>Core was generated by `/usr/bin/php -d magic_quotes_gpc=Off -d magic_quotes_runtime=Off -d magic_quote'.<br>Program terminated with signal SIGSEGV, Segmentation fault.<br>#0&nbsp; _zend_mm_free_int (heap=0x2c7bf90, p=0x7f38cb620058) at /build/php5-RvVZKb/php5-5.6.10+dfsg/Zend/zend_alloc.c:2104<br>2104&nbsp;&nbsp;&nbsp; /build/php5-RvVZKb/php5-5.6.10+dfsg/Zend/zend_alloc.c: No such file or directory.</pre><p> This didn't say to much, but executing <code>where</code> delivered this backtrace:</p> <pre>#0&nbsp; _zend_mm_free_int (heap=0x2c7bf90, p=0x7f38cb620058) at /build/php5-RvVZKb/php5-5.6.10+dfsg/Zend/zend_alloc.c:2104<br>#1&nbsp; 0x00007f38be799b33 in zim_Redis_hMset () from /usr/lib/php5/20131226/redis.so<br>#2&nbsp; 0x00000000006cb35b in dtrace_execute_internal (execute_data_ptr=&lt;optimized out&gt;, fci=&lt;optimized out&gt;, return_value_used=&lt;optimized out&gt;) at /build/php5-RvVZKb/php5-5.6.10+dfsg/Zend/zend_dtrace.c:97<br>#3&nbsp; 0x0000000000781328 in zend_do_fcall_common_helper_SPEC (execute_data=&lt;optimized out&gt;) at /build/php5-RvVZKb/php5-5.6.10+dfsg/Zend/zend_vm_execute.h:560<br>#4&nbsp; 0x0000000000716838 in execute_ex (execute_data=0x7f38cb728050) at /build/php5-RvVZKb/php5-5.6.10+dfsg/Zend/zend_vm_execute.h:363<br>....</pre><p> So it was clearly related to redis, exactly to redis and the command <code>hMset()</code>.<br> Only thing that changed there was the new <code>volatile</code> flag.<br> Fiddling with this showed that everything worked fine without the <code>volatile</code> item in the array.<br> Further investigation showed that the <code>volatile</code> value in the <code>$hash</code> was a boolean, which was suspect because there's a type cast <code>(int)</code> but it seems only to cast <code>CACHE_TEMPORARY</code>, which is a constant and an integer anyway...<br> Wrapping the comparison in parenthesis and casting the returned bool to int worked then.</p> <p>All this is not nice but it's not this modules fault that this leads to a segfault (the php extension should take care of such things), so I checked the issue queue of <a href="https://github.com/phpredis/phpredis">phpredis</a> and there are hints that this I indeed a problem but maybe is just the case for php 5.6 &amp; phpredis &lt; 2.2.7:</p> <ul> <li><a href="https://github.com/phpredis/phpredis/issues/603">Cause core-dump when using hMset() and attributes including null (php5.6 + fpm)</a></li> <li><a href="https://github.com/phpredis/phpredis/issues/524">phpredis segfaults for NULL values on PHP 5.6.2 (worked on 5.5)</a></li> </ul> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Wrap the comparison to set the <code>volatile</code> flag in <code>Redis_Cache_Predis::set()</code> / <code>Redis_Cache_PhpRedis::set()</code> in parenthesis. That way we keep the module phpredis version independent.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <p>Reviews needed.</p> <h3 id="summary-ui-changes">User interface changes</h3> <p>None.</p> <h3 id="summary-api-changes">API changes</h3> <p>None.</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>None.</p> >>> [!note] Pre-migration files - [redis-avoid-segfault-by-propery-type-casting.patch](https://www.drupal.org/files/issues/redis-avoid-segfault-by-propery-type-casting.patch) >>>