On the s390x architecture, the test_regrtest.test_crashed() fails because Python doesn't crash.

test.support._crash_python() calls ctypes.string_at(0) to crash Python. In debug mode, ctypes.string_at(0) fails with an assertion error and the process is killed with the SIGABRT signal. In release mode, ctypes.string_at(0) returns an empty string but doesn't crash.

Attached PR adds a new _testcapi._read_null() function which does crash in a reliable way on s390x and x86 :-) The function uses the C "volatile" keyword to prevent compiler optimizations. I copied the code from my faulthandler._read_null() function in the master branch which was battle tested. It does crash on all platforms... except of AIX.

I have run a build with the patch applied, and can confirm that the tests  pass on s390x.
Full build log can be viewed here: https://kojipkgs.fedoraproject.org//work/tasks/9473/22339473/build.log

New changeset cc4b6f1c6210460c0645b1df508e114e16805784 by Victor Stinner in branch '2.7':
bpo-31719: Fix test_regrtest.test_crashed() on s390x (#3912)
https://github.com/python/cpython/commit/cc4b6f1c6210460c0645b1df508e114e16805784

For the records, test_regrtest.test_crashed() uses faulthandler._sigsegv() in the master branch. This function calls raise(SIGSEGV) directly, rather than trying to read from NULL (address 0).

The main issue with reading from NULL is that it may not crash on AIX.  But I checked: test_regrtest passed on our AIX buildbot.

Why not use just abort() or Py_FatalError()?

$ ./python -c 'import ctypes; ctypes.CDLL("libc.so.6").abort()'
Aborted (core dumped)

$ ./python -c 'import ctypes; ctypes.pythonapi.Py_FatalError(b"boom!")'
Fatal Python error: boom!

Current thread 0x00007f26805c7580 (most recent call first):
  File "<string>", line 1 in <module>
Aborted (core dumped)

> Why not use just abort() or Py_FatalError()?

I try to test how a real program crash, like a real invalid memory read. Maybe it doesn't matter much here.