bpo-34720: Fix test_importlib.test_bad_traverse for AIX

[aixtools]

Fix Modules/_testmultiphase.c so that it exits with non-zero status on AIX just as other systems do (non zero exit status, e.g. as result of a segmentation fault) when a NULL pointer is accessed for data.

https://bugs.python.org/issue34720

[aixtools]

close, and reopen, to rerun the tests (still showing one red X atm).

[taleinat]

Test-only changes usually don't require a NEWS entry. In this case, it should be removed.

(Bedevere will complain, but you may ignore that, and I or another core dev will simply add the "skip news" tag.)

[aixtools]

I'll remove the News, as requested.

[taleinat]

Perhaps this could replace the Py_VISIT(m_state->integer); call on all platforms, thus avoiding the #ifdef?

[serhiy-storchaka]

Calling Py_VISIT(m_state->integer) is the purpose of this test.

But I wondering if it could be better to just skip the test on AIX in Python code.

[aixtools]

Obviously, I cannot "decide" what is "cleaner" - letting the test run, but have a modification in the C code the test calls, or having an "SkipIf" in the test (and move the comment to the test, so it is clear why the skip is needed).

I will make the recommended change.

[ncoghlan]

This test case originated from c2b0b12, and the new behaviour it's actually attempting to verify is:

1. In debug mode, module creation automatically invokes the registered traverse function (for eager detection of problematic traversal function definitions)
2. When the traversal function isn't checking correctly for a valid module state, the module creation fails

Actually implementing a valid traversal function here isn't overly important, as the module using it never actually gets created.

So I think @taleinat's right that this bad traversal function can be simplified to avoid the #ifdef, but I think it can be simplified all the way to being just:

m_state = PyModule_GetState(self);
/* The following assertion mimics any traversal function that doesn't correctly handle
 * the case during module creation where the module state hasn't been created yet.
 */
assert(m_state != NULL);
Py_VISIT(m_state->integer);
return 0;

That way the case of interest will always fail on the assert() call, and never even attempt to dereference the pointer.

[ncoghlan]

I think we can make this test more robust in general by replacing the null-pointer dereference with a known-to-be-incorrect assert() call.

[ncoghlan]

This test case originated from c2b0b12, and the new behaviour it's actually attempting to verify is:

1. In debug mode, module creation automatically invokes the registered traverse function (for eager detection of problematic traversal function definitions)
2. When the traversal function isn't checking correctly for a valid module state, the module creation fails

Actually implementing a valid traversal function here isn't overly important, as the module using it never actually gets created.

So I think @taleinat's right that this bad traversal function can be simplified to avoid the #ifdef, but I think it can be simplified all the way to being just:

m_state = PyModule_GetState(self);
/* The following assertion mimics any traversal function that doesn't correctly handle
 * the case during module creation where the module state hasn't been created yet.
 */
assert(m_state != NULL);
Py_VISIT(m_state->integer);
return 0;

That way the case of interest will always fail on the assert() call, and never even attempt to dereference the pointer.

[bedevere-bot]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[ncoghlan]

Note that the failing CI check is just looking for a NEWS entry.

The entry for this one would go in the "Tests" section, and can be generated with the Blurb CLI or the web service at https://blurb-it.herokuapp.com/ (as per the updated https://devguide.python.org/committing/#what-s-new-and-news-entries section)

[aixtools]

I have made the requested changes; please review again.

[bedevere-bot]

Thanks for making the requested changes!

@ncoghlan: please review the changes made to this pull request.

[ncoghlan]

Since I had forgotten why we didn't need to worry about the assert() getting compiled out in fully optimised release builds, I modified the block comment in the test traversal function to explain the details of that.

[ncoghlan]

Miss Islington will merge this automatically once CI completes successfully, but after that we'll want to keep an eye on https://buildbot.python.org/all/#/grid?branch=master&tag=stable&tag=nondebug to make sure release mode builds aren't unexpectedly affected by the change.

[miss-islington]

@aixtools: Status check is done, and it's a success ✅ .