# unit test a single case - Thread: https://externals.io/message/101603 - Original archive: https://news-web.php.net/php.internals/101603 - Started by Sam Ding on 2018-01-17T16:40:16+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #101603 — Sam Ding — 2018-01-17T16:40:16+00:00 URL: https://externals.io/message/101603#101603 Hi PHP developers, I am new and try to porting php v7.2.1 on IBM s390x, after building and run unit test "make test", there are some failed cases. Is there any way I can run a single case and get the result? Further how to debug a php unit case code? Thanks, Sam Ding, Linux on z Systems Open Source Ecosystem IBM Toronto Lab, email: samding@ca.ibm.com phone: (905)413-2947 --- ## #101604 — Nikita Popov — 2018-01-17T16:50:58+00:00 URL: https://externals.io/message/101603#101604 · In reply to: #101603 > > Hi PHP developers, > > I am new and try to porting php v7.2.1 on IBM s390x, after building and > run unit test "make test", there are > some failed cases. Is there any way I can run a single case and get the > result? > Further how to debug a php unit case code? > You can use one of make test TESTS=dir sapi/cli/php run-tests.php -P dir to run tests in a certain directory, or a specific test file. The first step for debugging would be to look at the .out or .diff file for the failing .phpt. There will also be a .php file, which can be used to run the test file directly. Nikita --- ## #101605 — mail@pmmaga.net — 2018-01-17T17:34:49+00:00 URL: https://externals.io/message/101603#101605 · In reply to: #101604 > > > > […] > > You can use one of > > make test TESTS=dir > sapi/cli/php run-tests.php -P dir > > to run tests in a certain directory, or a specific test file. > > The first step for debugging would be to look at the .out or .diff file for > the failing .phpt. There will also be a .php file, which can be used to run > the test file directly. > > Nikita > To add to what Nikita said, there will also be a .sh file next to the failing test that you can use to repeat that test only. Regards, Pedro --- ## #101607 — Christoph M. Becker — 2018-01-17T18:00:22+00:00 URL: https://externals.io/message/101603#101607 · In reply to: #101604 > > > > […] > > The first step for debugging would be to look at the .out or .diff file for > the failing .phpt. There will also be a .php file, which can be used to run > the test file directly. See also . -- Christoph M. Becker --- ## #101618 — Christoph M. Becker — 2018-01-18T17:42:57+00:00 URL: https://externals.io/message/101603#101618 > I can run the test case individually now and compare the result between > s390x and x86_64 (both RHEL 7.2) on failed cases. > Found the different results between the two platforms, some are related to > function `var_dump()`, how can I debug php code or even the interpreter > code ? > what debugger is used? If possible, use gdb. There's a .gdbinit[1] in the PHP source tree which offers some helpful macros. [1] -- Christoph M. Becker --- ## #101624 — Christoph M. Becker — 2018-01-19T00:27:47+00:00 URL: https://externals.io/message/101603#101624 > "gdb" seems not support php code. > > I run gdb like follows: > > # gdb ../sapi/cli/php > GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 > Copyright (C) 2013 Free Software Foundation, Inc. > ... > Reading symbols from /home/work/php/php-src/sapi/cli/php...done. > (gdb) b bug72300.php:5 > No source file named bug72300.php. > Make breakpoint pending on future shared library load? (y or [n]) y > Breakpoint 1 (bug72300.php:5) pending. > (gdb) r > Starting program: /home/work/php/php-src/case/../sapi/cli/php > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > > then gdb freezes at this point (/lib64/libthread_db.so.1). > > How to set break point in php and then step by step go into C code? As far as I know, this is not possible. You can, however, set a breakpoint for a certain PHP function (just preprend `zif_` to the PHP function name; in this case do `b zif_ignore_user_abort`). To actually start the debugging, do something like `r ext/standard/tests/general_functions/bug72300.php`. Most likely, there are more elegant ways to do this, but I don't know them. BTW: it seems that your latest mails didn't make it to the list (see e.g. ) for whatever reason. -- Christoph M. Becker