`sapi/phpdbg/tests/watch_006.phpt` fails on ppc64le
Personne n'a encore pris cette issue.
- Langage dominant
- C
- Étoiles
- 40.4k
- Forks
- 8.2k
- Merge moyen
- 2 j 13 h
- PR mergées (30 j)
- 96
Description
Description
The test is failing on ppc64le Linux (at least, I can't repro on arm64 macOS) like so:
$ cat sapi/phpdbg/tests/watch_006.diff
--
prompt> [Breaking on watchpoint $b]
Old value:
New value (reference): Array ([0] => 1)
018+
019+ [Element 0 has been added to watchpoint]
>00006: $a[0] = 2;
00007: $a[1] = 3;
00008: $c = [1];
--
Essentially, a (spurious?) message about a watchpoint being added occurs, that doesn't seem to happen on other platforms.
GDB stack trace:
(gdb) b phpdbg_watch.c:1038
Breakpoint 1 at 0x7a434c: file /home/cb/php-src/sapi/phpdbg/phpdbg_watch.c, line 1038.
(gdb) handle SIGSEGV nostop noprint
Signal Stop Print Pass to program Description
SIGSEGV No No Yes Segmentation fault
(gdb) run -qIb -n sapi/phpdbg/tests/watch_006.php < ~/phpdbg.cmd
Starting program: /home/cb/php-src/sapi/phpdbg/phpdbg -qIb -n sapi/phpdbg/tests/watch_006.php < ~/phpdbg.cmd
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Successful compilation of /home/cb/php-src/sapi/phpdbg/tests/watch_006.php]
prompt> [Breakpoint #0 added at /home/cb/php-src/sapi/phpdbg/tests/watch_006.php:4]
prompt> [Breakpoint #0 at /home/cb/php-src/sapi/phpdbg/tests/watch_006.php:4, hits: 1]
>00004: $a[0] = 1;
00005: $b = &$a;
00006: $a[0] = 2;
prompt> [Added watchpoint #0 for $a[0]]
prompt> [Added recursive watchpoint #1 for $b]
prompt> [Breaking on watchpoint $a[0]]
Old value: 0
New value: 1
>00005: $b = &$a;
00006: $a[0] = 2;
00007: $a[1] = 3;
prompt> [Breaking on watchpoint $b]
Old value:
New value (reference): Array ([0] => 1)
Breakpoint 1, phpdbg_check_watchpoint (watch=0x7ffff7860840) at /home/cb/php-src/sapi/phpdbg/phpdbg_watch.c:1038
1038 phpdbg_notice("Element %.*s has been added to watchpoint", (int) ZSTR_LEN(str), ZSTR_VAL(str));
(gdb) bt
#0 phpdbg_check_watchpoint (watch=0x7ffff7860840) at /home/cb/php-src/sapi/phpdbg/phpdbg_watch.c:1038
#1 0x00000001007a4c24 in phpdbg_print_changed_zvals () at /home/cb/php-src/sapi/phpdbg/phpdbg_watch.c:1176
#2 0x000000010078515c in phpdbg_execute_ex (execute_data=0x7ffff7817020) at /home/cb/php-src/sapi/phpdbg/phpdbg_prompt.c:1781
#3 0x00000001006aa75c in zend_execute (op_array=0x7ffff786d000, return_value=0x100a307d8 <phpdbg_globals+1360>)
at /home/cb/php-src/Zend/zend_vm_execute.h:63001
#4 0x0000000100781524 in phpdbg_do_run (param=0x0) at /home/cb/php-src/sapi/phpdbg/phpdbg_prompt.c:884
#5 0x000000010079c1e0 in phpdbg_internal_stack_execute (stack=0x7fffffffcc28, allow_async_unsafe=true) at /home/cb/php-src/sapi/phpdbg/phpdbg_cmd.c:702
#6 0x000000010079c334 in phpdbg_stack_execute (stack=0x7fffffffcc28, allow_async_unsafe=true) at /home/cb/php-src/sapi/phpdbg/phpdbg_cmd.c:732
#7 0x000000010078434c in phpdbg_interactive (allow_async_unsafe=true, input=0x7ffff78050f0 "r\n") at /home/cb/php-src/sapi/phpdbg/phpdbg_prompt.c:1547
#8 0x000000010077595c in main (argc=4, argv=0x7ffffffff078) at /home/cb/php-src/sapi/phpdbg/phpdbg.c:1610
Very interestingly, it does not reproduce with USE_ZEND_ALLOC=0 set.
Valgrind memcheck output: https://gist.github.com/NattyNarwhal/19a11906157ff459e9592041293d6312
PHP Version
PHP 8.4.0-DEV
Operating System
Gentoo
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par sapi/phpdbg/tests/watch_006.phpt et reproduisez l’échec sur ppc64le Linux, en comparant le comportement avec USE_ZEND_ALLOC=0. Lisez sapi/phpdbg/phpdbg_watch.c autour de phpdbg_check_watchpoint() et examinez la sortie Valgrind et la trace GDB liées. C’est terminé lorsque le test ne signale plus l’élément de watchpoint parasite et réussit sans le problème de mémoire signalé.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- c, php
- Domaine
- cli, devtools, testing-qa
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- À l'abandon
- Clarté
- Plutôt claire
- Accessibilité débutants
- 35/100