Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1712977

Summary: test_gdb: test_gc() fails on s390x with: Unable to locate python frame
Product: Red Hat Enterprise Linux 8 Reporter: Charalampos Stratakis <cstratak>
Component: python3Assignee: Victor Stinner <vstinner>
Status: CLOSED ERRATA QA Contact: Lukáš Zachar <lzachar>
Severity: unspecified Docs Contact:
Priority: low    
Version: 8.1CC: cstratak, dmalcolm, extras-qa, mcyprian, mhroncok, pviktori, rkuska, shcherbina.iryna, tomspur, torsava, vstinner
Target Milestone: rc   
Target Release: 8.0   
Hardware: s390x   
OS: Unspecified   
Whiteboard:
Fixed In Version: python3-3.6.8-16.el8 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: 1678277 Environment:
Last Closed: 2020-04-28 16:07:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Charalampos Stratakis 2019-05-22 15:31:25 UTC
+++ This bug was initially created as a clone of Bug #1678277 +++

The s390x job of the Fedora CI fails on building python3 package.

test_gdb.test_gc() failed twice on Python compiled in **debug mode** on s390x arch:

FAIL: test_gc (test.test_gdb.PyBtTests)
Verify that "py-bt" indicates if a thread is garbage-collecting
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.2/Lib/test/test_gdb.py", line 852, in test_gc
    self.assertIn('Garbage-collecting', gdb_output)
AssertionError: 'Garbage-collecting' not found in 'Breakpoint 1 (builtin_id) pending.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n\nBreakpoint 1, builtin_id (self=, self@entry=<error reading variable: value has been optimized out>, v=42, v@entry=<error reading variable: value has been optimized out>) at /builddir/build/BUILD/Python-3.7.2/Python/bltinmodule.c:1216\n1216\t    return PyLong_FromVoidPtr(v);\nBreakpoint 2: file /builddir/build/BUILD/Python-3.7.2/Modules/gcmodule.c, line 860.\n[Inferior 1 (process 12917) exited normally]\nUnable to locate python frame\n'

Reformatted gdb catched output:

Breakpoint 1 (builtin_id) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, builtin_id (self=, self@entry=<error reading variable: value has been optimized out>, v=42, v@entry=<error reading variable: value has been optimized out>) at /builddir/build/BUILD/Python-3.7.2/Python/bltinmodule.c:1216
1216	    return PyLong_FromVoidPtr(v);
Breakpoint 2: file /builddir/build/BUILD/Python-3.7.2/Modules/gcmodule.c, line 860.
[Inferior 1 (process 12917) exited normally]
Unable to locate python frame

--- Additional comment from Victor Stinner on 2019-02-18 13:20:32 CET ---

Related bug reports:

* 2015: https://bugzilla.redhat.com/show_bug.cgi?id=1181034#c0 "test_gdb fails on s390(x)" closed as "EOL" (no fixed)
* 2016: https://bugzilla.redhat.com/show_bug.cgi?id=1333064#c0 "/CoreOS/python/Sanity/gdb test is failing on s390x" closed as ERRATA except that no change has been written :-)
* 2016: https://github.com/python/cpython/commit/0d88c652318c4c5eed77fd2e78e9e955ffa5c8d1 fix test_gdb on s390x (ignore some warnings)
* 2018: https://bugs.python.org/issue34007 "test_gdb fails in s390x SLES buildbots" fixed upstream in Python 3.7.1

--- Additional comment from Charalampos Stratakis on 2019-05-22 16:45:46 CEST ---

This seems to be the change that triggered the bug for some reason: https://src.fedoraproject.org/rpms/python3/c/8927d3f2671041d33c2682b47d238c7070474d0e?branch=master

Comment 1 Marcel Plch 2019-06-24 10:38:58 UTC
I have managed to reproduce the issue.
It seems like the compiler on s390x arch inlines functions even with -O0 (and therefore with -Og too) in CFLAGS, when certain flags are specified.

I'm trying to isolate the minimum set of flags required to reproduce the issue.

Comment 2 Marcel Plch 2019-07-19 11:51:48 UTC
The problem emerges from bad compiler flags handling.
I have submitted an upstream issue:
https://bugs.python.org/issue37631?

Comment 3 Charalampos Stratakis 2019-10-03 00:17:12 UTC
This issue can be fixed by making the following change to the SPEC:

-  make EXTRA_CFLAGS="$CFLAGS $MoreCFlags" %{?_smp_mflags}
+  %make_build CFLAGS_NODIST="$CFLAGS_NODIST $MoreCFlags"

This will make the -Og the be appended to the end of the compiler flags, since CFLAGS_NODIST are appended at the end as well. As it stands now, CFLAGS_NODIST contains the -O2 which overrides -Og for the debug build.

The same fix also resolves bug 1714733

Comment 4 Charalampos Stratakis 2019-10-03 01:10:14 UTC
As a side note, when trying to change -Og to -O0 the debug build, the compilation segfaults, as the hardening flags that are enabled by default, require optimizations higher than -O0

Comment 8 errata-xmlrpc 2020-04-28 16:07:22 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:1764