I install Python 3.7.3 on CentOS 7.6. However, when I run "make test", I got a failure on test_dtrace as:

Ran 8 tests in 4.752s

FAILED (failures=6, skipped=2)
test test_dtrace failed
test_dtrace failed

== Tests result: FAILURE ==

1 test failed:
    test_dtrace

Total duration: 4 sec 771 ms
Tests result: FAILURE

I also encountered this on Scientific Linux 7.4 (Linux 3.10.0-693.11.6.el7.x86_64) while trying to build Python 3.8.0.

I think it is due to differences in versions of 'dtrace' on different platforms.
On my MacOS-X v10.14.6 (Mojave) system, the 'dtrace' command has a  -q (quiet the output) option.
On SL 7.4, it does not. The options are quite different.


This is output and versions from my test run:

    ./python  ./Tools/scripts/run_tests.py 
    == CPython 3.8.0 (default, Oct 29 2019, 14:37:09) [GCC 4.8.5 20150623 (Red Hat 4.8.5-16)]
    == Linux-3.10.0-693.11.6.el7.x86_64-x86_64-with-glibc2.17 little-endian
    == cwd: /opt/Python-3.8.0/build/test_python_30482
    == CPU count: 2
    == encodings: locale=UTF-8, FS=utf-8

Below is an error from the test log that shows the 'q' option being rejected from 'dtrace' (linux'):

    0:10:16 load avg: 1.79 Re-running test_dtrace in verbose mode
    skipped "dtrace(1) failed: ('/usr/bin/dtrace', 'invalid option', '-q')\nUsage /usr/bin/dtrace [--help] [-h | -G] [-C [-I<Path>]] -s File.d [-o <File>]"

Assuming 'dtrace' is run as a sub-process, the different versions could be producing very different results.

I attached a (clipped) version of my 'make test' output, it is essentially the same as sayno996's results.
There are also some error from 'test_nis" which can be ignoed for this issue.

I hope this helps.

There are actually two different issues here.

dtrace -q will not work on Fedora-based linux (haven't tried elsewhere) and that probably should be corrected, but that is NOT what causes the test fail. 

The tests' setup checks whether dtrace is usuable, and since it is not, those tests are skipped. 

However, stap IS usable, so those tests run.

test.test_dtrace.SystemTapOptimizedTests.test_line will always fail because it expects files in dtracedata (line.stp and line.stp.expected) that are not there.

I've attached a file showing isolated runs of test_dtrace on a newly built Python 3.8.6 on two Centos 7 systems.

The first is against the official Centos 7 Docker container, and stap fails because Linuxkit kernel modules are not installed. The test_dtrace check for a working stap fails, and all 4 tests are skipped.

The second is against a virtualized Centos 7 where the kernel modules are properly installed and stap works.

I don't see how test_dtrace ever passes on a system with a working /bin/stap command.