`test_dtrace` fails on s390x Fedora buildbots

[ZeroIntensity]

Bug report

Bug description:

Saw in #157045 (specifically 5693c85). Failing builds seem to be only on Fedora s390x. For example:

• https://buildbot.python.org/#/builders/1634/builds/579
• https://buildbot.python.org/#/builders/1666/builds/579
• https://buildbot.python.org/#/builders/1643/builds/580
• https://buildbot.python.org/#/builders/1640/builds/582
• https://buildbot.python.org/#/builders/1652/builds/583
• https://buildbot.python.org/#/builders/1630/builds/674

Here's the traceback:

======================================================================
FAIL: test_function_entry_return (test.test_dtrace.SystemTapNormalTests.test_function_entry_return)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildbot/worker/cstratak-fedora-stable-s390x/pull_request.cstratak-fedora-stable-s390x.refleak/build/Lib/test/test_dtrace.py", line 466, in test_function_entry_return
    self.run_case("call_stack")
    ~~~~~~~~~~~~~^^^^^^^^^^^^^^
  File "/var/lib/buildbot/worker/cstratak-fedora-stable-s390x/pull_request.cstratak-fedora-stable-s390x.refleak/build/Lib/test/test_dtrace.py", line 463, in run_case
    self.assertEqual(actual_output, expected_output)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 'func[21 chars]k.py:function_1:1\nfunction__entry:call_stack.[642 chars]5:21' != 'func[21 chars]k.py:start:23\nfunction__entry:call_stack.py:f[723 chars]t:28'

I'm unsure whether this is a known issue already, but I couldn't find any existing reports.

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

Linked PRs

• gh-158294: Avoid relying on SystemTap probe handler ordering #158346
• [3.15] gh-158294: Avoid relying on SystemTap probe handler ordering (GH-158346) #158383

[hugovk]

cc @stratakis @vstinner

[stratakis]

This is an issue with the latest systemtap 5.6, the s390x got the update. From its changelog:

Pass-2 optimizer can combine multiple probe handlers that share the same probe point, reducing registration overhead.

call_stack.stp defines handlers to be run in specific order but Systemtap makes no guarantees about that and the latest version exposed the issue. Combining the logic there into one handler should fix it.

[encukou]

Thank you for the fix!

The redness is down to one slow refleaks bot; time to close.