Bug 232311 - lang/php71 and lang/php72 with extensions dumps core on aarch64
Summary: lang/php71 and lang/php72 with extensions dumps core on aarch64
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Torsten Zuehlsdorff
URL:
Keywords:
Depends on: 233204
Blocks: 201763
  Show dependency treegraph
 
Reported: 2018-10-16 08:49 UTC by hlh
Modified: 2019-01-07 13:17 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (tz)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description hlh 2018-10-16 08:49:21 UTC
On FreeBSD nakiska.lab.bel 12.0-ALPHA9 FreeBSD 12.0-ALPHA9 r339301 PINE64  arm64

I upgrade php to lang/php72

When I run `php -v` without extensions (I rename /usr/local/etc/php to /usr/local:etc/PHP and create a empty /usr/local/etc/php)

I get:

PHP 7.2.11 (cli) (built: Oct 16 2018 08:46:45) ( ZTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies

With extensions I get:
Segmentation fault (core dumped)

and

[root@nakiska ~]# lldb /usr/local/bin/php -- -v
(lldb) target create "/usr/local/bin/php"
Current executable set to '/usr/local/bin/php' (aarch64).
(lldb) settings set -- target.run-args  "-v"
(lldb) run
Process 10319 launching
Process 10319 launched: '/usr/local/bin/php' (aarch64)
Process 10319 stopped
* thread #1, name = 'php', stop reason = trace
    frame #0: 0x00000000405b6678 ld-elf.so.1`dlopen_object(name="/usr/local/lib/php/20170718-zts/session.so", fd=-1, refobj=0x00000000405f4000, lo_flags=2, mode=257, lockstate=<unavailable>) at rtld.c:3295
   3292	    }
   3293	    GDB_STATE(RT_ADD,NULL);
   3294	
-> 3295	    old_obj_tail = globallist_curr(TAILQ_LAST(&obj_list, obj_entry_q));
   3296	    obj = NULL;
   3297	    if (name == NULL && fd == -1) {
   3298		obj = obj_main;
(lldb) bt
* thread #1, name = 'php', stop reason = trace
  * frame #0: 0x00000000405b6678 ld-elf.so.1`dlopen_object(name="/usr/local/lib/php/20170718-zts/session.so", fd=-1, refobj=0x00000000405f4000, lo_flags=2, mode=257, lockstate=<unavailable>) at rtld.c:3295
    frame #1: 0x00000000405b3be8 ld-elf.so.1`rtld_dlopen(name="/usr/local/lib/php/20170718-zts/session.so", fd=-1, mode=257) at rtld.c:3263
    frame #2: 0x00000000003abdf4 php`php_load_extension + 292
    frame #3: 0x000000000048b72c php`zend_llist_apply + 32
    frame #4: 0x00000000004311f8 php`php_ini_register_extensions + 56
    frame #5: 0x0000000000428fec php`php_module_startup + 2200
    frame #6: 0x0000000000593828 php`php_cli_startup + 20
    frame #7: 0x0000000000592624 php`main + 1120
    frame #8: 0x00000000003200b8 php`__start(argc=2, argv=0x0000ffffffffeaf8, env=0x0000ffffffffeb10, cleanup=<unavailable>) at crt1.c:84
    frame #9: 0x00000000405b0018 ld-elf.so.1`.rtld_start at rtld_start.S:41
(lldb) 

I encounter the same problem with lang/php71
Comment 1 mikael.urankar 2018-11-06 18:43:22 UTC
I don't have the problem here:
pkg info|grep php
php72-7.2.11                   PHP Scripting Language
php72-session-7.2.11           The session shared extension for php

php -v
PHP 7.2.11 (cli) (built: Nov  6 2018 19:37:43) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies

php -m
[PHP Modules]
Core
date
libxml
mysqlnd
pcre
Reflection
session
SPL
standard

[Zend Modules]

uname -a

FreeBSD tegra-x1 13.0-CURRENT FreeBSD 13.0-CURRENT #17 r339595M: Mon Oct 22 18:34:25 CEST 2018     root@pouet:/usr/obj/usr/src/arm64.aarch64/sys/JETSON-TX1  arm64

do you have anything in make.conf?
Comment 2 hlh 2018-11-07 12:24:05 UTC
My make.conf:

KERNCONF?=NAKISKA
MODULES_OVERRIDE=zfs opensolaris fdescfs netgraph rc4 accf_http accf_data dtrace tmpfs pf pflog pfsync allwinner dtb/allwinner

DEFAULT_VERSIONS=php=7.2
DEFAULT_VERSIONS+=bdb=5
DEFAULT_VERSIONS+=perl5=5.26

BATCH=yes
Comment 3 Jochen Neumeister freebsd_committer 2018-11-10 18:56:09 UTC
(In reply to mikael.urankar from comment #1)
I also have no problems with amd64. Did you test it on arm64?
Comment 4 mikael.urankar 2018-11-10 19:08:05 UTC
(In reply to Jochen Neumeister from comment #3)
My report was for aarch64, tested on rpi3 12.0-beta2 and nvidia jetson tx1 13-current.
I haven't tried on amd64.
Comment 5 Jochen Neumeister freebsd_committer 2018-11-10 19:19:53 UTC
hlh@restart.be: are you still having problems?

> DEFAULT_VERSIONS = php = 7.2
You can delete that. PHP72 is default
Comment 6 mikael.urankar 2018-11-19 13:13:49 UTC
Do you still have the problem? If that's the case can you try the wip patch in bug #233204?
Comment 7 hlh 2018-11-20 09:06:31 UTC
(In reply to mikael.urankar from comment #6)

Up to FreeBSD nakiska.lab.bel 12.0-BETA4 FreeBSD 12.0-BETA4 r340271 GENERIC  arm64
The problem persists.

I take 'libexec/rtld-elf/aarch64/reloc.c' from current (r339878) and
apply the WIP TLS relocations patches.

By the way in this patch:
int64_t rtld_tlsdesc_handle(struct tls_data *tlsdesc, int flags);
must be updated to
int64_t rtld_tlsdesc_handle(struct tls_data *tlsdesc);

I recompile and install libexec and bingo all is working fine:-)

[root@nakiska ~]# php -vĀµ
PHP 7.2.11 (cli) (built: Nov 10 2018 09:54:12) ( ZTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.11, Copyright (c) 1999-2018, by Zend Technologies
[root@nakiska ~]# php -m
[PHP Modules]
bz2
Core
ctype
date
dom
filter
gd
gettext
hash
iconv
imap
json
ldap
libxml
mbstring
mysqlnd
openssl
pcre
PDO
pdo_pgsql
pdo_sqlite
pgsql
posix
Reflection
session
SimpleXML
SPL
sqlite3
standard
tidy
tokenizer
xml
Zend OPcache
zip
zlib

[Zend Modules]
Zend OPcache
Comment 8 mikael.urankar 2018-11-20 10:51:57 UTC
(In reply to hlh from comment #7)
ok, cool.

Can you add "201763" to the "Blocks" field?
Comment 9 mikael.urankar 2018-12-13 10:58:26 UTC
From Michal Meloun (mmel@)
Final (and much more complex) version of this patch is under review now:
https://reviews.freebsd.org/D18417

Michal
Comment 10 commit-hook freebsd_committer 2018-12-15 10:39:09 UTC
A commit references this bug:

Author: mmel
Date: Sat Dec 15 10:38:10 UTC 2018
New revision: 342113
URL: https://svnweb.freebsd.org/changeset/base/342113

Log:
  Improve R_AARCH64_TLSDESC relocation.
  The original code did not support dynamically loaded libraries and used
  suboptimal access to TLS variables.
  New implementation removes lazy resolving of TLS relocation - due to flaw
  in TLSDESC design is impossible to switch resolver function at runtime
  without expensive locking.

  Due to this, 3 specialized resolvers are implemented:
   - load time resolver for TLS relocation from libraries loaded with main
     executable (thus with known TLS offset).
   - resolver for undefined thread weak symbols.
   - slower lazy resolver for dynamically loaded libraries with fast path for
     already resolved symbols.

  PR:		228892, 232149, 233204, 232311
  MFC after:	2 weeks
  Differential Revision:	https://reviews.freebsd.org/D18417

Changes:
  head/libexec/rtld-elf/aarch64/reloc.c
  head/libexec/rtld-elf/aarch64/rtld_start.S
  head/libexec/rtld-elf/amd64/reloc.c
  head/libexec/rtld-elf/arm/reloc.c
  head/libexec/rtld-elf/i386/reloc.c
  head/libexec/rtld-elf/mips/reloc.c
  head/libexec/rtld-elf/powerpc/reloc.c
  head/libexec/rtld-elf/powerpc64/reloc.c
  head/libexec/rtld-elf/riscv/reloc.c
  head/libexec/rtld-elf/rtld.c
  head/libexec/rtld-elf/rtld.h
  head/libexec/rtld-elf/sparc64/reloc.c
Comment 11 Torsten Zuehlsdorff freebsd_committer 2019-01-07 11:11:15 UTC
Since there is already a commit referencing this PR: is here anything left todo? Or can we close the issue because its fixed?
Comment 12 hlh 2019-01-07 13:17:44 UTC
(In reply to Torsten Zuehlsdorff from comment #11)

Today committed to 12.0-STABLE (r342847 MFC r342113)

[root@nakiska libexec]# php -v
PHP 7.2.13 (cli) (built: Jan  4 2019 22:38:17) ( ZTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.13, Copyright (c) 1999-2018, by Zend Technologies

Problem solved