0 votes

L'installation du portage osx de php74 plante avec une instruction illégale : 4

J'ai un problème avec php74 compilé par macports qui plante avec l'instruction illégale 4 quand je lance phpunit pour tester mon projet.

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

J'utilise cet ordinateur pour le développement de sites web avec php74, apache 2.4 et mysql8.

Cela fonctionnait bien et j'ai pu lancer des tests unitaires sur mon projet en utilisant phpunit 8.5.4.

L'autre jour, l'ordinateur s'est bloqué et ne répondait plus, j'ai donc éteint et rallumé l'ordinateur.

Après cela, les tests unitaires (phpunit) exécutant la commande php74 (7.4.15) se terminent avec l'instruction illégale 4.

Les autres commandes php, exécutées soit via apache, soit depuis le CLI fonctionnent correctement, il semble que ce soit les commandes phpunit qui cassent php74.

J'ai réinstallé une version antérieure de php74, (7.4.14 & 7.4.13) et le compilateur s'est plaint de l'absence de MacOSX11.2. en utilisant la version antérieure de php => même erreur.

J'ai essayé une autre version de phpunit (9.5.2) => même erreur.

J'ai lancé l'utilitaire de disque pour rechercher les erreurs de lecteur, aucune n'a été trouvée => même erreur

J'ai essayé de copier le fichier /opt/local/php74 d'un autre Mac sur cet ordinateur => même erreur.

j'ai : supprimé complètement xcode. supprimé macports et désinstallé tous les ports. réinstallé xcode 12.4 lié symboliquement le SDK 11.3 au SDK 11.2 ie :

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

ce lien a supprimé l'avertissement de macports, je ne suis pas sûr qu'il soit correct, mais il semble fonctionner.

réinstallation de tous les ports

et l'erreur persiste.

./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)

Ma question est la suivante : que recommande-t-on pour résoudre ce problème ?

Je ne veux vraiment pas effacer le mac, mais c'est un peu ce qui se passe.

Voici un exemple de trace de pile de la console d'erreur. https://pastebin.com/td7Xi4EL

2voto

rybosome Points 1829

Voici les éléments importants :

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

Remarquez que vous êtes exactement à 512 (= 2^9) cadres de pile et que les cadres parents ont été tronqués. Vous obtenez un KERN_PROTECTION_FAILURE à 0x7ffeeccd3ff8 parce que vous avez dépassé la taille maximale de la pile et que vous essayez d'écrire dans une région protégée (l'adresse illégale se trouve juste au-dessus de Stack dans le STACK GUARD qui a été créée expressément pour faire face à des situations de ce type).

Cela s'est produit parce qu'il y avait une chaîne d'appels de fonctions hautement récursifs et que cela a simplement dépassé la limite de la pile par défaut de 512 cadres (8192 KB) (voir ulimit -s ). D'après l'apparence des cadres récurrents ( ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER() encore et encore), je suppose que c'est le code php (le vôtre ou le cadre de test unitaire) qui est récurrent, plutôt que le code C de l'interpréteur lui-même.

Si vous n'êtes pas sûr de l'endroit où se produit la récursion, une solution temporaire consisterait à augmenter la limite de la pile de la fonction php processus en utilisant ulimit(1) et relancez votre commande dans la même fenêtre de Terminal :

ulimit -s 65532
./phpunit --group Jobs_model

Cela permet d'exécuter votre test avec une limite de 64 Mo pour la pile. Notez que l'option le noyau spécifie une limite supérieure maximale pour la pile de 64 Mo :

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

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

donc si votre récursivité est énorme, vous manquerez toujours d'espace. À ce moment-là, cependant, vous voudrez vraiment savoir ce qui récurse autant.

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X