Segmentation Fault

[dhotson]

I get a seg fault when trying to run the following script on the command line after installing php-zmq (I'm on commit b24cfaebd9250f983701a6112eed2d52240e14c6).

I'm on Ubuntu Lucid (PHP 5.3.2-1ubuntu4.2) with the latest ZeroMQ code from http://github.com/zeromq/zeromq2

Script to reproduce:

<?php
$c = new ZMQContext();
$s = $c->getSocket(ZMQ::SOCKET_UPSTREAM);
$s->connect("tcp://127.0.0.1:9997");

GDB Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00007fffee579862 in ?? () from /lib/libuuid.so.1
(gdb) bt
-0  0x00007fffee579862 in ?? () from /lib/libuuid.so.1
-1  0x00007fffee57a769 in uuid_generate () from /lib/libuuid.so.1
-2  0x00007fffec66cb89 in uuid_t (this=0x7ffff7fe5020) at uuid.cpp:84
-3  0x00007fffec66794e in zmq::socket_base_t::attach_pipes (this=0x117a270, inpipe_=0x117a650, outpipe_=0x0, peer_identity_=<value optimised out>)
    at socket_base.cpp:184
-4  0x00007fffec667f4b in zmq::socket_base_t::connect (this=0x117a270, addr_=<value optimised out>) at socket_base.cpp:414
-5  0x00007fffec885533 in zim_zmqsocket_connect (ht=<value optimised out>, return_value=0x1066cb8, return_value_ptr=<value optimised out>, 
    this_ptr=0x10667b8, return_value_used=<value optimised out>) at /home/dhotson/dev/php-zmq/zmq.c:581
-6  0x00007ffff4061f2a in xdebug_execute_internal (current_execute_data=0x7ffff7e8a068, return_value_used=0)
    at /build/buildd/xdebug-2.0.5/build-php5/xdebug.c:1631
-7  0x00000000006e5f36 in ?? ()
-8  0x00000000006bd400 in execute ()
-9  0x00007ffff4061b9e in xdebug_execute (op_array=0x1065590) at /build/buildd/xdebug-2.0.5/build-php5/xdebug.c:1562
-10 0x000000000069512d in zend_execute_scripts ()
-11 0x0000000000640d98 in php_execute_script ()
-12 0x0000000000726236 in ?? ()
-13 0x00007ffff52a8c4d in __libc_start_main () from /lib/libc.so.6
-14 0x000000000042c639 in _start ()

Any ideas?

[mkoppanen]

Have you got PHP's uuid extension loaded?

[dhotson]

Thanks, I just tried it again with the uuid extension loaded and got the same result.

Also, not sure if this is helpful.. but here's the output from valgrind:

==15229== Memcheck, a memory error detector
==15229== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==15229== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==15229== Command: php test.php
==15229== 
==15229== Invalid write of size 2
==15229==    at 0xE892862: ??? (in /lib/libuuid.so.1.3.0)
==15229==    by 0xE893768: uuid_generate (in /lib/libuuid.so.1.3.0)
==15229==    by 0x10BD1B88: zmq::uuid_t::uuid_t() (uuid.cpp:84)
==15229==    by 0x10BCC94D: zmq::socket_base_t::attach_pipes(zmq::reader_t*, zmq::writer_t*, std::basic_string<unsigned char, std::char_traits<unsigned char>, std::allocator<unsigned char> > const&) (socket_base.cpp:184)
==15229==    by 0x10BCCF4A: zmq::socket_base_t::connect(char const*) (socket_base.cpp:414)
==15229==    by 0x1099A286: zim_zmqsocket_connect (zmq.c:581)
==15229==    by 0x8D8CF29: xdebug_execute_internal (xdebug.c:1631)
==15229==    by 0x6E7755: ??? (in /usr/bin/php5)
==15229==    by 0x6BEC1F: execute (in /usr/bin/php5)
==15229==    by 0x8D8CB9D: xdebug_execute (xdebug.c:1562)
==15229==    by 0x69694C: zend_execute_scripts (in /usr/bin/php5)
==15229==    by 0x642597: php_execute_script (in /usr/bin/php5)
==15229==  Address 0x44 is not stack'd, malloc'd or (recently) free'd
==15229== 
==15229== 
==15229== Process terminating with default action of signal 11 (SIGSEGV)
==15229==  Access not within mapped region at address 0x44
==15229==    at 0xE892862: ??? (in /lib/libuuid.so.1.3.0)
==15229==    by 0xE893768: uuid_generate (in /lib/libuuid.so.1.3.0)
==15229==    by 0x10BD1B88: zmq::uuid_t::uuid_t() (uuid.cpp:84)
==15229==    by 0x10BCC94D: zmq::socket_base_t::attach_pipes(zmq::reader_t*, zmq::writer_t*, std::basic_string<unsigned char, std::char_traits<unsigned char>, std::allocator<unsigned char> > const&) (socket_base.cpp:184)
==15229==    by 0x10BCCF4A: zmq::socket_base_t::connect(char const*) (socket_base.cpp:414)
==15229==    by 0x1099A286: zim_zmqsocket_connect (zmq.c:581)
==15229==    by 0x8D8CF29: xdebug_execute_internal (xdebug.c:1631)
==15229==    by 0x6E7755: ??? (in /usr/bin/php5)
==15229==    by 0x6BEC1F: execute (in /usr/bin/php5)
==15229==    by 0x8D8CB9D: xdebug_execute (xdebug.c:1562)
==15229==    by 0x69694C: zend_execute_scripts (in /usr/bin/php5)
==15229==    by 0x642597: php_execute_script (in /usr/bin/php5)
==15229==  If you believe this happened as a result of a stack
==15229==  overflow in your program's main thread (unlikely but
==15229==  possible), you can try to increase the size of the
==15229==  main thread stack using the --main-stacksize= flag.
==15229==  The main thread stack size used in this run was 8388608.
==15229== 
==15229== HEAP SUMMARY:
==15229==     in use at exit: 4,464,134 bytes in 32,920 blocks
==15229==   total heap usage: 36,103 allocs, 3,183 frees, 5,102,700 bytes allocated
==15229== 
==15229== LEAK SUMMARY:
==15229==    definitely lost: 0 bytes in 0 blocks
==15229==    indirectly lost: 0 bytes in 0 blocks
==15229==      possibly lost: 263,486 bytes in 27 blocks
==15229==    still reachable: 4,200,648 bytes in 32,893 blocks
==15229==         suppressed: 0 bytes in 0 blocks
==15229== Rerun with --leak-check=full to see details of leaked memory
==15229== 
==15229== For counts of detected and suppressed errors, rerun with: -v
==15229== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 31 from 10)
Killed

[mkoppanen]

And the same thing happens even when you disable Xdebug? uuid extension is not needed for the operation but I've seen a segfault in the past related to uuid extension and external shared library linking with libuuid

[dhotson]

Unfortunately yes. It still happens when I disable xdebug.

Let me know if there's anything I can do to help debug this. Thanks again. :-)

[mkoppanen]

Have you got another Lucid box? Is this a reproducible issue?

[dhotson]

I'll try it on another Lucid machine when I get to work tomorrow. But yes, I can reproduce it reliably.

[dhotson]

Sorry to bug you again. I'm just curious, what platform are you using to develop php-zmq on? What platform would you say has the best support?

[mkoppanen]

I'm developing on Debian but all platforms that I have access to should be equally supported. Is this issue still happening?

[mkoppanen]

Hello,

I cannot reproduce this using:

$ php -v
PHP 5.3.2-1ubuntu4.5 with Suhosin-Patch (cli) (built: Sep 17 2010 13:49:46)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

Linux ubuntu 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 05:14:15 UTC 2010 x86_64 GNU/Linux
Ubuntu 10.04.1 LTS

[dhotson]

Ok, I think I've got it figured out. The problem only happens when I have the imagick PHP extension loaded.

I disabled the imagick extension and it's working fine now.

I wonder why that would cause the problem?

[pda]

I've tested this on another Ubuntu Lucid install.

I get the same seg fault with imagick 2.3.0 installed from PECL, and with php5-imagick 2.1.1RC1-1build3 installed from apt. Building the PECL version depends on libmagickwand-dev 7:6.5.7.8-1ubuntu1 from apt.

No seg fault when the imagick PHP extension isn't installed.

Cheers,
Paul

[alister]

(tldr; load uuid before imagick & zmq in the php .ini's)
I've come across this one myself - and have also just found: http://usrportage.de/archives/922-PHP-segfaulting-with-pecluuid-and-peclimagick.html

I've just confirmed it where a zmq connect segfaulted, but renaming /etc/php5/cli/conf.d/uuid.ini to 00-uuid.ini allows the connect to succeed. The zmq-bind wasn't affected.

[ifavo]

I just stumbled on the same problem with the same server configuration.

I renamed the imagick.ini to zz-imagick.ini and everything works now.

[bitmanzhou]

I met this issue also on ubuntu 10.10 x86_64. I have a deep debug. Here is the gdb stack trace:

(gdb) r examples/client.php
... ...
(gdb) p jrand_seed
Cannot access memory at address 0x44
(gdb) c
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff15be6c2 in get_random_fd () at gen_uuid.c:156
156 jrand_seed[0] = getpid() ^ (tv.tv_sec & 0xFFFF);
(gdb) bt
#0 0x00007ffff15be6c2 in get_random_fd () at gen_uuid.c:156
#1 0x00007ffff15bf5c9 in uuid_generate (out=0x7ffff7fdc030 "\002") at gen_uuid.c:674
#2 0x00007fffe94d7639 in zmq::uuid_t::uuid_t (this=0x7ffff7fdc030) at uuid.cpp:80
#3 0x00007fffe94d28f9 in zmq::socket_base_t::attach_pipes (this=0x112eea0, inpipe_=0x112f420, outpipe_=0x112f5c0, peer_identity_=) at socket_base.cpp:224
#4 0x00007fffe94d310a in zmq::socket_base_t::connect (this=0x112eea0, addr_=) at socket_base.cpp:456
#5 0x00007fffe97548d3 in zim_zmqsocket_connect (ht=, return_value=0x1106468, return_value_ptr=, this_ptr=0x1106508,
return_value_used=) at /home/archipel/Downloads/php-zmq/zmq.c:775
#6 0x00000000006ea6fa in ?? ()
#7 0x00000000006c17a0 in execute ()
#8 0x0000000000698f9d in zend_execute_scripts ()
#9 0x00000000006448a8 in php_execute_script ()
#10 0x000000000072aa26 in ?? ()
#11 0x00007ffff54a9d8e in __libc_start_main () from /lib/libc.so.6
#12 0x0000000000428249 in _start ()
(gdb)

Here jrand_seed[] is a thread local storage :

#ifdef HAVE_TLS
#define THREAD_LOCAL static __thread
#else
#define THREAD_LOCAL static
#endif

#if defined(linux) && defined(__NR_gettid) && defined(HAVE_JRAND48)
#define DO_JRAND_MIX
THREAD_LOCAL unsigned short jrand_seed[3];
#endif

I don't know how to fix it yet. Rename imagick.ini doesn't work for me. My zeromq and php-zmq are built by myself.

[bitmanzhou]

Just rename imagick.ini doesn't work. I have to comment out "extension=imagick.so" in it. The reason is that imagick.so also requires libuuid.so and so libuuid.so is loaded before zmq.so/libzmq.so. Unfortunately TLS variable jrand_seed[] is not alloced due to unknown reason.
Here is another workaround. Rename zmq.ini to 0mq.ini so that zmq.so/libzmq.so get loaded first and then everything just works.

[mkoppanen]

I really don't know what's going on with this issue. I'll try to debug this issue further during the weekend.

[torkve]

mkoppanen, haven't you looked at this issue yet?
I get this segfault (but only not in gdb!) on debian squeeze with latest php5-zmq installed, even with latest master version.
Renaming zmq.ini to 0mq.ini helps, but I'm aware that imagick would segfault now.

[mkoppanen]

Hi,

this looks like to be an issue with ImageMagick rather than zmq. See http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=18801. As a work-around you can LD_PRELOAD libuuid.so library for now before real solution is found.

[mkoppanen]

Hi,

can someone test compiling ImageMagick with --disable-openmp and see if this helps?

[sp3c73r2038]

Hi, after ImageMagick 6.7.1.0 with --disable-openmp and php imagick extension recompiling, I won't get segfault now.

also, extension uuid disabled.

Here's my php version info.

PHP 5.3.8-pl0-gentoo (cli) (built: Sep 6 2011 11:12:49) (DEBUG)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

[ioquatix]

Apparently this is a problem with libc6 since 2005, but it appears that with recent libraries being compiled for multiple threads it has become more of an issue recently. The latest Debian unstable eglibc6 packages apparently solve this problem, but I haven't tried that yet.

I just filed a bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647896