Re: PHP 7.2: SIGSEGV in OpenSSL
Hi. I installed more extensions and noticed that ldap.so, indeed must follow openssl to avoid Segmentation Fault. mod_php73-7.3.4 php73-7.3.4 php73-bcmath-7.3.4 php73-bz2-7.3.4 php73-ctype-7.3.4 php73-curl-7.3.4 php73-dom-7.3.4 php73-exif-7.3.4 php73-extensions-1.0 php73-fileinfo-7.3.4 php73-filter-7.3.4 php73-gd-7.3.4 php73-gettext-7.3.4 php73-hash-7.3.4 php73-iconv-7.3.4 php73-intl-7.3.4 php73-json-7.3.4 php73-ldap-7.3.4 php73-mbstring-7.3.4 php73-opcache-7.3.4 php73-openssl-7.3.4 php73-pdo-7.3.4 php73-pdo_mysql-7.3.4 php73-pdo_sqlite-7.3.4 php73-phar-7.3.4 php73-posix-7.3.4 php73-session-7.3.4 php73-simplexml-7.3.4 php73-soap-7.3.4 php73-sockets-7.3.4 php73-sqlite3-7.3.4 php73-tokenizer-7.3.4 php73-xml-7.3.4 php73-xmlreader-7.3.4 php73-xmlwriter-7.3.4 php73-zip-7.3.4 php73-zlib-7.3.4 extension=session.so extension=fileinfo.so extension=simplexml.so extension=ctype.so extension=mbstring.so extension=tokenizer.so extension=filter.so extension=xmlwriter.so extension=gd.so extension=gettext.so extension=iconv.so extension=exif.so extension=zlib.so extension=bz2.so extension=openssl.so ; LDAP and CURL must be loaded after openssl extension=ldap.so extension=curl.so extension=dom.so extension=hash.so extension=xmlreader.so extension=bcmath.so extension=soap.so extension=pdo.so extension=pdo_mysql.so extension=pdo_sqlite.so extension=sockets.so extension=xml.so ; additional extension(s) not known by fixphpextorder.sh extension=intl.so extension=json.so extension=posix.so extension=sqlite3.so extension=zip.so extension=phar.so On Thu, 25 Apr 2019 at 17:07, Marcel Bonnet wrote: > > > On Wed, 24 Apr 2019 at 18:03, Stefan Bethke wrote: > >> Am 24.04.2019 um 22:50 schrieb Mathieu Arnold : >> >> On Wed, Apr 24, 2019 at 06:34:06PM +0200, Stefan Bethke wrote: >> >> Am 23.04.2019 um 18:01 schrieb Kurt Jaeger : >> >> Hi! >> >> Did you find a solution? Please let me know. >> >> >> There's a well-known problem in the sequence in which php modules >> are loaded. I don't know if this is the case here as well, >> but that's what we do: >> >> fetch -o fixphpextorder \ >> https://people.freebsd.org/~ohauer/scripts/fixphpextorder.sh >> chmod 755 fixphpextorder >> >> cd /usr/local/etc/php >> cat ext-*ini > extensions.ini >> fixphpextorder >> mv extensions.ini.new extensions.ini >> rm ext-*ini >> >> Please test and report if it fixes the problem. >> >> >> Thanks Kurt, it appears to fix (or at least work around) the problem. >> >> Why is the default load order broken? Why does it not affect everyone? >> >> I moved all the individual inis into a bak subdir, and now only have an >> extensions.ini. >> >> If I understand correctly, mod_php/PHP reads the individual inis in >> order. Why aren’t they in the right order? Can this be fixed in the ports >> for the PHP modules? >> >> >> Could you give the order that works for you, so that we can try to >> figure out which module is making it break ? >> >> Because there is no "right" order, there is an order that can work for >> most people, and from time to time, two libs have conflicting symbols, >> but it is not possible to detect that. So I made up an order that >> should be ok, but some time is not. >> >> >> This is the order I’m actively using now: >> $ cat extensions.ini >> extension=session.so >> extension=fileinfo.so >> extension=ldap.so >> extension=simplexml.so >> extension=ctype.so >> extension=mbstring.so >> extension=tokenizer.so >> extension=filter.so >> extension=pgsql.so >> extension=mcrypt.so >> extension=gd.so >> extension=gettext.so >> extension=iconv.so >> extension=zlib.so >> extension=curl.so >> extension=xmlrpc.so >> extension=bz2.so >> extension=openssl.so >> extension=dom.so >> extension=hash.so >> extension=wddx.so >> extension=memcache.so >> extension=soap.so >> extension=pdo.so >> extension=pdo_mysql.so >> extension=mysqli.so >> extension=sockets.so >> extension=xml.so >> ; additional extension(s) not known by fixphpextorder.sh >> extension=intl.so >> extension=json.so >> extension=sqlite3.so >> extension=zip.so >> extension=memcached.so >> extension=pdo_pgsql.so >> extension=phar.so >> >> This is the order as installed by the ports (at least I think that’s the >> order PHP will read the files): >> $ cat $(echo bak/*.ini|sort) >> zend_extension=opcache.so >> extension=session.so >> extension=bz2.so >> extension=ctype.so >> extension=curl.so >> extension=dom.so >> extension=fileinfo.so >> extension=filter.so >> extension=gd.so >> extension=gettext.so >> extension=hash.so >> extension=iconv.so >> extension=intl.so >> extension=json.so >> extension=ldap.so >> extension=mbstring.so >> extension=mcrypt.so >> extension=mysqli.so >> extension=openssl.so >> extension=pdo.so >> extension=pgsql.so >> extension=simplexml.so >> extension=soap.so >> extension=sockets.so >> extension=sqlite3.so >> extension=tokenizer.so >> extension=xml.so >> extension=zip.so >> extension=zlib.so >>
Re: PHP 7.2: SIGSEGV in OpenSSL
On Wed, 24 Apr 2019 at 18:03, Stefan Bethke wrote: > Am 24.04.2019 um 22:50 schrieb Mathieu Arnold : > > On Wed, Apr 24, 2019 at 06:34:06PM +0200, Stefan Bethke wrote: > > Am 23.04.2019 um 18:01 schrieb Kurt Jaeger : > > Hi! > > Did you find a solution? Please let me know. > > > There's a well-known problem in the sequence in which php modules > are loaded. I don't know if this is the case here as well, > but that's what we do: > > fetch -o fixphpextorder \ > https://people.freebsd.org/~ohauer/scripts/fixphpextorder.sh > chmod 755 fixphpextorder > > cd /usr/local/etc/php > cat ext-*ini > extensions.ini > fixphpextorder > mv extensions.ini.new extensions.ini > rm ext-*ini > > Please test and report if it fixes the problem. > > > Thanks Kurt, it appears to fix (or at least work around) the problem. > > Why is the default load order broken? Why does it not affect everyone? > > I moved all the individual inis into a bak subdir, and now only have an > extensions.ini. > > If I understand correctly, mod_php/PHP reads the individual inis in order. > Why aren’t they in the right order? Can this be fixed in the ports for the > PHP modules? > > > Could you give the order that works for you, so that we can try to > figure out which module is making it break ? > > Because there is no "right" order, there is an order that can work for > most people, and from time to time, two libs have conflicting symbols, > but it is not possible to detect that. So I made up an order that > should be ok, but some time is not. > > > This is the order I’m actively using now: > $ cat extensions.ini > extension=session.so > extension=fileinfo.so > extension=ldap.so > extension=simplexml.so > extension=ctype.so > extension=mbstring.so > extension=tokenizer.so > extension=filter.so > extension=pgsql.so > extension=mcrypt.so > extension=gd.so > extension=gettext.so > extension=iconv.so > extension=zlib.so > extension=curl.so > extension=xmlrpc.so > extension=bz2.so > extension=openssl.so > extension=dom.so > extension=hash.so > extension=wddx.so > extension=memcache.so > extension=soap.so > extension=pdo.so > extension=pdo_mysql.so > extension=mysqli.so > extension=sockets.so > extension=xml.so > ; additional extension(s) not known by fixphpextorder.sh > extension=intl.so > extension=json.so > extension=sqlite3.so > extension=zip.so > extension=memcached.so > extension=pdo_pgsql.so > extension=phar.so > > This is the order as installed by the ports (at least I think that’s the > order PHP will read the files): > $ cat $(echo bak/*.ini|sort) > zend_extension=opcache.so > extension=session.so > extension=bz2.so > extension=ctype.so > extension=curl.so > extension=dom.so > extension=fileinfo.so > extension=filter.so > extension=gd.so > extension=gettext.so > extension=hash.so > extension=iconv.so > extension=intl.so > extension=json.so > extension=ldap.so > extension=mbstring.so > extension=mcrypt.so > extension=mysqli.so > extension=openssl.so > extension=pdo.so > extension=pgsql.so > extension=simplexml.so > extension=soap.so > extension=sockets.so > extension=sqlite3.so > extension=tokenizer.so > extension=xml.so > extension=zip.so > extension=zlib.so > extension=memcache.so > extension=memcached.so > extension=pdo_mysql.so > extension=pdo_pgsql.so > extension=phar.so > extension=wddx.so > extension=xmlrpc.so > > This is the contents of bak (the former contents of /usr/local/etc/php): > $ ls bak > ext-10-opcache.ini ext-20-intl.ini ext-20-sqlite3.ini > ext-18-session.ini ext-20-json.ini ext-20-tokenizer.ini > ext-20-bz2.ini ext-20-ldap.ini ext-20-xml.ini > ext-20-ctype.ini ext-20-mbstring.ini ext-20-zip.ini > ext-20-curl.ini ext-20-mcrypt.ini ext-20-zlib.ini > ext-20-dom.ini ext-20-mysqli.ini ext-30-memcache.ini > ext-20-fileinfo.ini ext-20-openssl.ini ext-30-memcached.ini > ext-20-filter.ini ext-20-pdo.ini ext-30-pdo_mysql.ini > ext-20-gd.ini ext-20-pgsql.ini ext-30-pdo_pgsql.ini > ext-20-gettext.ini ext-20-simplexml.ini ext-30-phar.ini > ext-20-hash.ini ext-20-soap.ini ext-30-wddx.ini > ext-20-iconv.ini ext-20-sockets.ini ext-30-xmlrpc.ini > > > These are the PHP packages I have installed, minus the web apps: > $ pkg info -r php72 > php72-7.2.17_2: > php72-xml-7.2.17_2 > php72-hash-7.2.17_2 > php72-session-7.2.17_2 > php72-openssl-7.2.17_2 > php72-xmlrpc-7.2.17_2 > php72-mysqli-7.2.17_2 > php72-mbstring-7.2.17_2 > php72-phar-7.2.17_2 > php72-ctype-7.2.17_2 > php72-tokenizer-7.2.17_2 > php72-json-7.2.17_2 > php72-filter-7.2.17_2 > php72-gd-7.2.17_2 > php72-zlib-7.2.17_2 > php72-zip-7.2.17_2 > php72-bz2-7.2.17_2 > php72-iconv-7.2.17_2 > php72-fileinfo-7.2.17_2 > php72-pgsql-7.2.17_2 > php72-opcache-7.2.17_2 > php72-wddx-7.2.17_2 > php72-simplexml-7.2.17_2 > php72-dom-7.2.17_2 > php72-pecl-mcrypt-1.0.2 > php72-soap-7.2.17_2 > php72-ldap-7.2.17_2 > php72-curl-7.2.17_2 > php72-sqlite3-7.2.17_2 > php72-pdo-7.2.17_2 > php72-memcache-4.0.3 > php72-pecl-memcached-3.1.3 > php72-sockets-7.2.17_2 > php72-intl-7.2.17_2 > php72-gettext-7.2.17_2
Re: PHP 7.2: SIGSEGV in OpenSSL
> Am 24.04.2019 um 22:50 schrieb Mathieu Arnold : > > On Wed, Apr 24, 2019 at 06:34:06PM +0200, Stefan Bethke wrote: >>> Am 23.04.2019 um 18:01 schrieb Kurt Jaeger : >>> >>> Hi! >>> Did you find a solution? Please let me know. >>> >>> There's a well-known problem in the sequence in which php modules >>> are loaded. I don't know if this is the case here as well, >>> but that's what we do: >>> >>> fetch -o fixphpextorder \ >>> https://people.freebsd.org/~ohauer/scripts/fixphpextorder.sh >>> chmod 755 fixphpextorder >>> >>> cd /usr/local/etc/php >>> cat ext-*ini > extensions.ini >>> fixphpextorder >>> mv extensions.ini.new extensions.ini >>> rm ext-*ini >>> >>> Please test and report if it fixes the problem. >> >> Thanks Kurt, it appears to fix (or at least work around) the problem. >> >> Why is the default load order broken? Why does it not affect everyone? >> >> I moved all the individual inis into a bak subdir, and now only have an >> extensions.ini. >> >> If I understand correctly, mod_php/PHP reads the individual inis in order. >> Why aren’t they in the right order? Can this be fixed in the ports for the >> PHP modules? > > Could you give the order that works for you, so that we can try to > figure out which module is making it break ? > > Because there is no "right" order, there is an order that can work for > most people, and from time to time, two libs have conflicting symbols, > but it is not possible to detect that. So I made up an order that > should be ok, but some time is not. This is the order I’m actively using now: $ cat extensions.ini extension=session.so extension=fileinfo.so extension=ldap.so extension=simplexml.so extension=ctype.so extension=mbstring.so extension=tokenizer.so extension=filter.so extension=pgsql.so extension=mcrypt.so extension=gd.so extension=gettext.so extension=iconv.so extension=zlib.so extension=curl.so extension=xmlrpc.so extension=bz2.so extension=openssl.so extension=dom.so extension=hash.so extension=wddx.so extension=memcache.so extension=soap.so extension=pdo.so extension=pdo_mysql.so extension=mysqli.so extension=sockets.so extension=xml.so ; additional extension(s) not known by fixphpextorder.sh extension=intl.so extension=json.so extension=sqlite3.so extension=zip.so extension=memcached.so extension=pdo_pgsql.so extension=phar.so This is the order as installed by the ports (at least I think that’s the order PHP will read the files): $ cat $(echo bak/*.ini|sort) zend_extension=opcache.so extension=session.so extension=bz2.so extension=ctype.so extension=curl.so extension=dom.so extension=fileinfo.so extension=filter.so extension=gd.so extension=gettext.so extension=hash.so extension=iconv.so extension=intl.so extension=json.so extension=ldap.so extension=mbstring.so extension=mcrypt.so extension=mysqli.so extension=openssl.so extension=pdo.so extension=pgsql.so extension=simplexml.so extension=soap.so extension=sockets.so extension=sqlite3.so extension=tokenizer.so extension=xml.so extension=zip.so extension=zlib.so extension=memcache.so extension=memcached.so extension=pdo_mysql.so extension=pdo_pgsql.so extension=phar.so extension=wddx.so extension=xmlrpc.so This is the contents of bak (the former contents of /usr/local/etc/php): $ ls bak ext-10-opcache.ini ext-20-intl.ini ext-20-sqlite3.ini ext-18-session.ini ext-20-json.ini ext-20-tokenizer.ini ext-20-bz2.ini ext-20-ldap.ini ext-20-xml.ini ext-20-ctype.iniext-20-mbstring.ini ext-20-zip.ini ext-20-curl.ini ext-20-mcrypt.ini ext-20-zlib.ini ext-20-dom.ini ext-20-mysqli.ini ext-30-memcache.ini ext-20-fileinfo.ini ext-20-openssl.ini ext-30-memcached.ini ext-20-filter.ini ext-20-pdo.ini ext-30-pdo_mysql.ini ext-20-gd.ini ext-20-pgsql.iniext-30-pdo_pgsql.ini ext-20-gettext.ini ext-20-simplexml.iniext-30-phar.ini ext-20-hash.ini ext-20-soap.ini ext-30-wddx.ini ext-20-iconv.iniext-20-sockets.ini ext-30-xmlrpc.ini These are the PHP packages I have installed, minus the web apps: $ pkg info -r php72 php72-7.2.17_2: php72-xml-7.2.17_2 php72-hash-7.2.17_2 php72-session-7.2.17_2 php72-openssl-7.2.17_2 php72-xmlrpc-7.2.17_2 php72-mysqli-7.2.17_2 php72-mbstring-7.2.17_2 php72-phar-7.2.17_2 php72-ctype-7.2.17_2 php72-tokenizer-7.2.17_2 php72-json-7.2.17_2 php72-filter-7.2.17_2 php72-gd-7.2.17_2 php72-zlib-7.2.17_2 php72-zip-7.2.17_2 php72-bz2-7.2.17_2 php72-iconv-7.2.17_2 php72-fileinfo-7.2.17_2 php72-pgsql-7.2.17_2 php72-opcache-7.2.17_2 php72-wddx-7.2.17_2 php72-simplexml-7.2.17_2 php72-dom-7.2.17_2 php72-pecl-mcrypt-1.0.2 php72-soap-7.2.17_2 php72-ldap-7.2.17_2 php72-curl-7.2.17_2 php72-sqlite3-7.2.17_2
Re: PHP 7.2: SIGSEGV in OpenSSL
On Wed, Apr 24, 2019 at 06:34:06PM +0200, Stefan Bethke wrote: > > Am 23.04.2019 um 18:01 schrieb Kurt Jaeger : > > > > Hi! > > > >> Did you find a solution? Please let me know. > > > > There's a well-known problem in the sequence in which php modules > > are loaded. I don't know if this is the case here as well, > > but that's what we do: > > > > fetch -o fixphpextorder \ > >https://people.freebsd.org/~ohauer/scripts/fixphpextorder.sh > > chmod 755 fixphpextorder > > > > cd /usr/local/etc/php > > cat ext-*ini > extensions.ini > > fixphpextorder > > mv extensions.ini.new extensions.ini > > rm ext-*ini > > > > Please test and report if it fixes the problem. > > Thanks Kurt, it appears to fix (or at least work around) the problem. > > Why is the default load order broken? Why does it not affect everyone? > > I moved all the individual inis into a bak subdir, and now only have an > extensions.ini. > > If I understand correctly, mod_php/PHP reads the individual inis in order. > Why aren’t they in the right order? Can this be fixed in the ports for the > PHP modules? Could you give the order that works for you, so that we can try to figure out which module is making it break ? Because there is no "right" order, there is an order that can work for most people, and from time to time, two libs have conflicting symbols, but it is not possible to detect that. So I made up an order that should be ok, but some time is not. -- Mathieu Arnold signature.asc Description: PGP signature
Re: PHP 7.2: SIGSEGV in OpenSSL
Hi! > >> Did you find a solution? Please let me know. > > There's a well-known problem in the sequence in which php modules > > are loaded. I don't know if this is the case here as well, > > but that's what we do: > Thanks Kurt, it appears to fix (or at least work around) the problem. > > Why is the default load order broken? Why does it not affect everyone? We don't know. In fact, I found a PR from 2015, and re-opened it: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203741 > If I understand correctly, mod_php/PHP reads the individual inis > in order. Why aren't they in the right order? Can this be fixed in > the ports for the PHP modules? It's in that shape since approx. 2007, so it's nasty and needs someone with enough curiosity to find the root cause. -- p...@freebsd.org +49 171 3101372 One year to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 7.2: SIGSEGV in OpenSSL
> Am 23.04.2019 um 18:01 schrieb Kurt Jaeger : > > Hi! > >> Did you find a solution? Please let me know. > > There's a well-known problem in the sequence in which php modules > are loaded. I don't know if this is the case here as well, > but that's what we do: > > fetch -o fixphpextorder \ >https://people.freebsd.org/~ohauer/scripts/fixphpextorder.sh > chmod 755 fixphpextorder > > cd /usr/local/etc/php > cat ext-*ini > extensions.ini > fixphpextorder > mv extensions.ini.new extensions.ini > rm ext-*ini > > Please test and report if it fixes the problem. Thanks Kurt, it appears to fix (or at least work around) the problem. Why is the default load order broken? Why does it not affect everyone? I moved all the individual inis into a bak subdir, and now only have an extensions.ini. If I understand correctly, mod_php/PHP reads the individual inis in order. Why aren’t they in the right order? Can this be fixed in the ports for the PHP modules? Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 7.2: SIGSEGV in OpenSSL
Hi! > Did you find a solution? Please let me know. There's a well-known problem in the sequence in which php modules are loaded. I don't know if this is the case here as well, but that's what we do: fetch -o fixphpextorder \ https://people.freebsd.org/~ohauer/scripts/fixphpextorder.sh chmod 755 fixphpextorder cd /usr/local/etc/php cat ext-*ini > extensions.ini fixphpextorder mv extensions.ini.new extensions.ini rm ext-*ini Please test and report if it fixes the problem. -- p...@opsec.eu+49 171 3101372One year to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 7.2: SIGSEGV in OpenSSL
Hi. Did you find a solution? Please let me know. A simple command, like below, is enought to cause a segmentation fault. but it depends on which extensions are enabled (php73-ldap or php73-curl ; probably any using openssl) $ php -r "phpinfo();" $ uname -a FreeBSD machine.STUDIO 12.0-STABLE FreeBSD 12.0-STABLE #2 r344331M: Fri Mar 8 08:36:23 -03 2019 marcelbonnet@machine.STUDIO:/usr/obj/usr/src/amd64.amd64/sys/MACHINE-12 amd64 $ pkg iinfo php73 php73-7.3.4 php73-composer-1.8.4 php73-ctype-7.3.4 php73-curl-7.3.4 php73-filter-7.3.4 php73-hash-7.3.4 php73-intl-7.3.4 php73-json-7.3.4 php73-mbstring-7.3.4 php73-opcache-7.3.4 php73-openssl-7.3.4 php73-phar-7.3.4 $ gdb /usr/local/bin/php php.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `php -r phpinfo();'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libelf.so.2...Reading symbols from /usr/lib/debug//lib/libelf.so.2.debug...done. done. Loaded symbols for /lib/libelf.so.2 Reading symbols from /lib/libcrypt.so.5...Reading symbols from /usr/lib/debug//lib/libcrypt.so.5.debug...done. done. Loaded symbols for /lib/libcrypt.so.5 Reading symbols from /usr/local/lib/libargon2.so.0...done. Loaded symbols for /usr/local/lib/libargon2.so.0 Reading symbols from /lib/libm.so.5...Reading symbols from /usr/lib/debug//lib/libm.so.5.debug...done. done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libthr.so.3...Reading symbols from /usr/lib/debug//lib/libthr.so.3.debug...done. done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /usr/local/lib/libxml2.so.2...done. Loaded symbols for /usr/local/lib/libxml2.so.2 Reading symbols from /lib/libz.so.6...Reading symbols from /usr/lib/debug//lib/libz.so.6.debug...done. done. Loaded symbols for /lib/libz.so.6 Reading symbols from /usr/lib/liblzma.so.5...Reading symbols from /usr/lib/debug//usr/lib/liblzma.so.5.debug...done. done. Loaded symbols for /usr/lib/liblzma.so.5 Reading symbols from /usr/local/lib/libpcre2-8.so.0...done. Loaded symbols for /usr/local/lib/libpcre2-8.so.0 Reading symbols from /lib/libc.so.7...BFD: /lib/libc.so.7: invalid relocation type 37 BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276 Reading symbols from /usr/lib/debug//lib/libc.so.7.debug...done. done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/php/20180731-debug/opcache.so...done. Loaded symbols for /usr/local/lib/php/20180731-debug/opcache.so Reading symbols from /lib/libcrypto.so.111...Reading symbols from /usr/lib/debug//lib/libcrypto.so.111.debug...done. done. Loaded symbols for /lib/libcrypto.so.111 Reading symbols from /libexec/ld-elf.so.1...Reading symbols from /usr/lib/debug//libexec/ld-elf.so.1.debug...done. done. Loaded symbols for /libexec/ld-elf.so.1 #0 openssl_lh_strcasehash (c=0x802b618a2 ) at /usr/src/crypto/openssl/crypto/lhash/lhash.c:361 361 if (c == NULL || *c == '\0') [New Thread 800f63000 (LWP 100460/)] (gdb) bt #0 openssl_lh_strcasehash (c=0x802b618a2 ) at /usr/src/crypto/openssl/crypto/lhash/lhash.c:361 #1 0x000801c811fd in obj_name_hash (a=0x7fffdad0) at /usr/src/crypto/openssl/crypto/objects/o_names.c:166 #2 0x000801d37036 in OPENSSL_LH_delete (lh=0x800f87fc0, data=0x7fffdad0) at /usr/src/crypto/openssl/crypto/lhash/lhash.c:302 #3 0x000801c80e78 in OBJ_NAME_remove (name=0x802b618a2 , type=1) at obj_lcl.h:12 #4 0x000801d3731a in OPENSSL_LH_doall (lh=0x800f87fc0, func=0x801c81170 ) at /usr/src/crypto/openssl/crypto/lhash/lhash.c:198 #5 0x000801c81108 in OBJ_NAME_cleanup (type=1) at obj_lcl.h:12 #6 0x000801c8e468 in evp_cleanup_int () at /usr/src/crypto/openssl/crypto/evp/names.c:83 #7 0x000801d6915d in OPENSSL_cleanup () at /usr/src/crypto/openssl/crypto/init.c:567 #8 0x000800ccb205 in __cxa_finalize (dso=0x0) at /usr/src/lib/libc/stdlib/atexit.c:239 #9 0x000800c5b781 in exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:74 #10 0x007a9560 in main (argc=3, argv=0x7fffde08) at php_cli.c:1427 Current language: auto; currently minimal On Mon, 21 Jan 2019 at 17:00, Stefan Bethke wrote: > I'm seeing a lot of coredumps with a stack trace similar to this, on a > 12-stable machine: > > # gdb /usr/local/sbin/httpd /httpd.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the
PHP 7.2: SIGSEGV in OpenSSL
I'm seeing a lot of coredumps with a stack trace similar to this, on a 12-stable machine: # gdb /usr/local/sbin/httpd /httpd.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `/usr/local/sbin/httpd -DNOHTTPACCEPT'. Program terminated with signal 11, Segmentation fault. ... (gdb) bt #0 openssl_lh_strcasehash (c=0x803466cf2 ) at /freebsd/checkout/src/12/crypto/openssl/crypto/lhash/lhash.c:361 #1 0x00080138564d in obj_name_hash (a=0x7fffe9d0) at /freebsd/checkout/src/12/crypto/openssl/crypto/objects/o_names.c:166 #2 0x00080143be77 in OPENSSL_LH_delete (lh=0x800a27240, data=0x7fffe9d0) at /freebsd/checkout/src/12/crypto/openssl/crypto/lhash/lhash.c:302 #3 0x0008013852c8 in OBJ_NAME_remove ( name=0x803466cf2 , type=1) at obj_lcl.h:12 #4 0x00080143c15a in OPENSSL_LH_doall (lh=0x800a27240, func=0x8013855c0 ) at /freebsd/checkout/src/12/crypto/openssl/crypto/lhash/lhash.c:198 #5 0x000801385558 in OBJ_NAME_cleanup (type=1) at obj_lcl.h:12 #6 0x000801392918 in evp_cleanup_int () at /freebsd/checkout/src/12/crypto/openssl/crypto/evp/names.c:83 #7 0x00080146e39d in OPENSSL_cleanup () at /freebsd/checkout/src/12/crypto/openssl/crypto/init.c:567 #8 0x0008007a24e5 in __cxa_finalize (dso=0x0) at /freebsd/checkout/src/12/lib/libc/stdlib/atexit.c:233 #9 0x0008007320e1 in exit (status=54947058) at /freebsd/checkout/src/12/lib/libc/stdlib/exit.c:62 #10 0x000800a55118 in ?? () #11 0x7fffeb90 in ?? () The one case I could isolate the PHP code is calling stream_socket_enable_crypto(), but I suspect there might be others. Is anybody else seeing this? Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
