0 votos

la instalación del puerto osx de php74 se bloquea con una instrucción ilegal: 4

Tengo un problema con php74 compilado por macports que se bloquea con la instrucción ilegal 4 cuando ejecuto phpunit para probar la unidad de mi proyecto.

uname -v
Darwin Kernel Version 20.3.0: Thu Jan 21 00:07:06 PST 2021; root:xnu-7195.81.3~1/RELEASE_X86_64

sudo port selfupdate
Password:
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.6.4 installed,
MacPorts base version 2.6.4 downloaded.
--->  Updating the ports tree

Utilizo este ordenador para el desarrollo de sitios web con php74, apache 2.4 y mysql8.

Esto funcionó bien y pude ejecutar pruebas unitarias en mi proyecto usando phpunit 8.5.4

El otro día el ordenador se bloqueó y no respondía, así que lo apagué y lo volví a encender.

Después de eso, las pruebas unitarias (phpunit) ejecutando el comando php74 (7.4.15) sale con la instrucción ilegal 4.

Otros comandos de php, ejecutados ya sea a través de apache, o desde el CLI funcionan bien, sólo parece ser los comandos de phpunit que rompen php74.

he reinstalado una versión anterior de php74, (7.4.14 y 7.4.13) y el compilador se quejó de que faltaba MacOSX11.2. usando la versión anterior de php => mismo error.

He probado otra versión de phpunit (9.5.2) => mismo error.

ejecuto la utilidad de disco para escanear los errores de la unidad, ninguno encontrado => el mismo error

he probado a copiar el /opt/local/php74 desde otro mac a este ordenador => mismo error.

Lo he hecho: eliminado completamente xcode. eliminado macports y desinstalado todos los puertos. reinstalado xcode 12.4 vinculado simbólicamente el SDK 11.3 con el 11.2, es decir:

ls -Al  /Library/Developer/CommandLineTools/SDKs
total 0
lrwxr-xr-x  1 root  wheel   14 24 Feb 11:08 MacOSX.sdk -> MacOSX11.3.sdk
drwxr-xr-x  8 root  wheel  256 24 Feb 11:09 MacOSX10.15.sdk
lrwxr-xr-x  1 root  wheel   55 24 Feb 14:49 MacOSX11.2.sdk -> /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk
drwxr-xr-x  7 root  wheel  224 24 Feb 11:08 MacOSX11.3.sdk

este enlace eliminó la advertencia de macports, no estoy seguro si era correcto, pero parece que funciona.

reinstalación de todos los puertos

y el error se mantiene.

./phpunit --group Jobs_model
PHPUnit 9.5.2 by Sebastian Bergmann and contributors.

Warning:       Your XML configuration validates against a deprecated schema.
Suggestion:    Migrate your XML configuration using "--migrate-configuration"!

zsh: illegal hardware instruction  ./phpunit --group Jobs_model

sudo port installed | grep -e php -e mysql -e apache
  apache2 @2.4.46_1+preforkmpm (active)
  mysql8 @8.0.23_0 (active)
  mysql8-server @8.0.23_0 (active)
  mysql_select @0.1.2_4 (active)
  php74 @7.4.15_0+libedit (active)
  php74-apache2handler @7.4.15_0 (active)
  php74-calendar @7.4.15_0 (active)
  php74-cgi @7.4.15_0 (active)
  php74-curl @7.4.15_0 (active)
  php74-exif @7.4.15_0 (active)
  php74-fpm @7.4.15_0 (active)
  php74-ftp @7.4.15_0 (active)
  php74-gd @7.4.15_0 (active)
  php74-geoip @1.1.1_0 (active)
  php74-gettext @7.4.15_0 (active)
  php74-gmagick @2.0.5RC1_0 (active)
  php74-iconv @7.4.15_0 (active)
  php74-igbinary @3.2.1_0 (active)
  php74-intl @7.4.15_0 (active)
  php74-ldap @7.4.15_0 (active)
  php74-mbstring @7.4.15_0 (active)
  php74-memcached @3.1.5_0 (active)
  php74-mysql @7.4.15_0+mysqlnd (active)
  php74-opcache @7.4.15_0 (active)
  php74-openssl @7.4.15_0 (active)
  php74-soap @7.4.15_0 (active)
  php74-sodium @7.4.15_0 (active)
  php74-xdebug @3.0.2_0 (active)
  php74-xmlrpc @7.4.15_0 (active)
  php74-zip @1.19.2_0 (active)
  php_select @1.0_0 (active)

mi pregunta es, ¿qué se recomienda para solucionar esto?

Realmente no quiero borrar el mac, pero se está moviendo en esa dirección.

aquí hay un ejemplo de seguimiento de la pila de la consola de errores. https://pastebin.com/td7Xi4EL

2voto

rybosome Puntos 1829

Aquí están las partes importantes:

Exception Codes:       KERN_PROTECTION_FAILURE at 0x00007ffeeccd3ff8

VM Regions Near 0x7ffeeccd3ff8:
    MALLOC_LARGE             7ff27e800000-7ff27f101000 [ 9220K] rw-/rwx SM=PRV  
--> STACK GUARD              7ffee94d4000-7ffeeccd4000 [ 56.0M] ---/rwx SM=NUL  stack guard for thread 0
    Stack                    7ffeeccd4000-7ffeed4d4000 [ 8192K] rw-/rwx SM=ALI  thread

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x00007fff2035068f __commpage_gettimeofday_internal + 31
1   libsystem_c.dylib               0x00007fff20266b6d gettimeofday + 45
2   libsystem_c.dylib               0x00007fff20282584 time + 48
3   php                             0x000000010292db7c tsrm_realpath_r + 384
    [...]
503 xdebug.so                       0x000000010551e540 xdebug_execute_ex + 1121
504 php                             0x000000010295e495 ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER + 405
505 php                             0x0000000102942ae7 execute_ex + 35
506 xdebug.so                       0x000000010551e540 xdebug_execute_ex + 1121
507 php                             0x000000010295e495 ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER + 405
508 php                             0x0000000102942ae7 execute_ex + 35509 xdebug.so                         0x000000010551e540 xdebug_execute_ex + 1121
510 php                             0x000000010295e495 ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER + 405
511 php                             0x0000000102942ae7 execute_ex + 35

Fíjate que estás exactamente en 512 (= 2^9) marcos de pila y los marcos padre han sido truncados. Estás obteniendo un KERN_PROTECTION_FAILURE en 0x7ffeeccd3ff8 porque has desbordado el tamaño máximo de la pila y estás intentando escribir en una región protegida (la dirección ilegal está justo encima de Stack en el STACK GUARD que se creó expresamente para detectar este tipo de situaciones).

Esto ocurría porque había una cadena de llamadas a funciones muy recursivas y simplemente se superaba el límite de pila por defecto de 512 cuadros (8192 KB) (ver ulimit -s ). Por el aspecto de los cuadros recursivos ( ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER() una y otra vez), supongo que es el código php (ya sea el tuyo o el del framework de pruebas unitarias) el que está recursando, más que el código C del propio intérprete.

Si no está seguro de dónde se está produciendo la recursión, una solución temporal sería aumentar el límite de la pila del php proceso utilizando ulimit(1) y ejecute su comando de nuevo en la misma ventana de Terminal:

ulimit -s 65532
./phpunit --group Jobs_model

Esto ejecutará su prueba con un límite de pila de 64 MB. Tenga en cuenta que el el núcleo especifica un límite máximo de pila de 64 MB:

#define DFLSSIZ         (8*1024*1024)           /* initial stack size limit */

#define MAXSSIZ         (64*1024*1024)          /* max stack size */

por lo que si tu recursión es muy grande, te quedarás sin espacio. En ese punto, sin embargo, realmente querrías averiguar qué es lo que está recurriendo tanto.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X