zeromq/php-zmq

Segfault in php_zmq_pollset_poll w/PHP 7

Torben-SB opened this issue · 5 comments

Hi there,

Recently upgraded to PHP 7 and now I'm getting segfaults using our polling code. It traces back to this section (this is using the zmq-beta 1.1.3 PECL installation, freshly reinstalled and compiled).

$read = $write = [];
$poll = new \ZMQPoll();
$poll->add($socket, \ZMQ::POLL_IN);
$events = $poll->poll($read, $write, $this->sock_timeout);

I'm happy to provide a more complete example if you need it, but it looks like the problem has something to do with the cleanup of the $read and $write arrays, so hopefully this is enough.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff407a2d0 in _zval_ptr_dtor () from /usr/lib/apache2/modules/libphp7.0.so
(gdb) bt
#0  0x00007ffff407a2d0 in _zval_ptr_dtor () from /usr/lib/apache2/modules/libphp7.0.so
#1  0x00007ffff409997d in zend_hash_clean () from /usr/lib/apache2/modules/libphp7.0.so
#2  0x00007fffe854bd80 in php_zmq_pollset_poll (set=0x7ffff19f03c0, timeout=500, r_array=0x7ffff18778d8, w_array=0x7ffff18778f0) at /tmp/pear/temp/zmq/zmq_pollset.c:312
#3  0x00007fffe8548108 in zim_zmqpoll_poll (execute_data=<optimized out>, return_value=0x7ffff1813370) at /tmp/pear/temp/zmq/zmq.c:1440
#4  0x00007ffff407a12b in dtrace_execute_internal () from /usr/lib/apache2/modules/libphp7.0.so
. . . etc . . .

Again, happy to provide more information if needed.

Thanks!

We have the same problem. For now, we worked it around using non-blocking receive and usleep, which is ugly, but less ugly than segfaults.

Hi,
we had the same issue with PHP7. It crashed in built-in PHP server as well as Apache with mod_php. Apache backtrace from gdb:

Thread 1 "php7.0" received signal SIGSEGV, Segmentation fault.
0x00005555557a5150 in _zval_ptr_dtor ()
(gdb) backtrace
#0  0x00005555557a5150 in _zval_ptr_dtor ()
#1  0x00005555557c6675 in zend_hash_clean ()
#2  0x00007fffe1ee6d09 in php_zmq_pollset_poll ()
   from /usr/lib/php/20151012/zmq.so
#3  0x00007fffe1ee2f73 in zim_zmqpoll_poll () from /usr/lib/php/20151012/zmq.so
#4  0x00005555557a4f2a in dtrace_execute_internal ()
#5  0x000055555583a790 in ?? ()
#6  0x00005555557f59eb in execute_ex ()
#7  0x00005555557a4ec8 in dtrace_execute_ex ()
#8  0x000055555583a8cd in ?? ()
#9  0x00005555557f59eb in execute_ex ()
#10 0x00005555557a4ec8 in dtrace_execute_ex ()
#11 0x000055555583a8cd in ?? ()
#12 0x00005555557f59eb in execute_ex ()
#13 0x00005555557a4ec8 in dtrace_execute_ex ()
#14 0x000055555583a8cd in ?? ()
#15 0x00005555557f59eb in execute_ex ()
#16 0x00005555557a4ec8 in dtrace_execute_ex ()
#17 0x00005555557a6a9f in zend_call_function ()
#18 0x00005555556a4809 in zim_reflection_method_invokeArgs ()
#19 0x00005555557a4f2a in dtrace_execute_internal ()
#20 0x000055555583a790 in ?? ()
#21 0x00005555557f59eb in execute_ex ()

@Torben-SB

I have the similar problem,I found that opcache was the cause of the problem.
so my solution to the problem is to add opcache.blacklist_filename to the opcahe config ,let opcache to ignore all zmq code

Thanks for the answer @tom916. I tried to only blacklist zmq, but was still getting segfaults (albeit in a slightly different place, top of the stack was zend_objects_store_del instead of _zval_ptr_dtor). However, disabling opcache entirely fixed it for me.

Looks like someone forked it and solved it here: gabrielperezs@e9942b8

@mkoppanen is there any chance of getting a fix for this soon?