This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: --with-tsc crashes on ppc64
Type: crash Stage: resolved
Components: Interpreter Core Versions: Python 3.4, Python 3.5
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: dmalcolm, iritkatriel
Priority: normal Keywords: patch

Created on 2011-08-31 21:51 by dmalcolm, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
python-2.7.2-tsc-on-ppc.patch dmalcolm, 2011-08-31 21:51
Messages (3)
msg143281 - (view) Author: Dave Malcolm (dmalcolm) (Python committer) Date: 2011-08-31 21:51
On 64-bit PPC builds configured --with-tsc, Python segfaults within the first function call in the bytecode interpreter.

Upon investigation this is due to this code in Python/ceval.c:
    32  typedef unsigned long long uint64;
    34  /* PowerPC support.
    35     "__ppc__" appears to be the preprocessor definition to detect on OS
X, whereas
    36     "__powerpc__" appears to be the correct one for Linux with GCC
    37  */
    38  #if defined(__ppc__) || defined (__powerpc__)
    40  #define READ_TIMESTAMP(var) ppc_getcounter(&var)
    42  static void
    43  ppc_getcounter(uint64 *v)
    44  {
    45      register unsigned long tbu, tb, tbu2;
    47    loop:
    48      asm volatile ("mftbu %0" : "=r" (tbu) );
    49      asm volatile ("mftb  %0" : "=r" (tb)  );
    50      asm volatile ("mftbu %0" : "=r" (tbu2));
    51      if (__builtin_expect(tbu != tbu2, 0)) goto loop;
    53      /* The slightly peculiar way of writing the next lines is
    54         compiled better by GCC than any other way I tried. */
    55      ((long*)(v))[0] = tbu;
    56      /*((long*)(v))[1] = tb; */ /* <==== this is the bug */
    57  }
    59  #elif defined(__i386__)

(gdb) p sizeof(long)
$44 = 8
(gdb) p sizeof(uint64)
$45 = 8

Looks like lines 55 and 56 are erroneously assuming that a long is 4 bytes on
this arch: line 56 above is trashing the next value beyond the timer value, which is on the machine's stack, corrupting local variables within PyEval_EvalFrameEx.

The code has been this way since ppc_getcounter was added, in:

I may have broken this in:
which was for:
by (perhaps) generalizing support from ppc to (ppc and ppc64) (not sure about

I'm attaching a patch which splits the ppc tsc support into 32-bit and 64-bit parts, and which also removes an aliasing violation on 32-bit ppc.

(I'm tracking this downstream in Fedora's bug tracker as )
msg221562 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-06-25 17:47
This refers to a crash so can we have a code review please, I'm certainly not qualified to do one on ceval.c.
msg401382 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-09-08 13:31
I don't see anything like the code of the patch in ceval.c now.

I will close this soon unless given a reason not to.
Date User Action Args
2022-04-11 14:57:21adminsetgithub: 57081
2021-10-15 17:44:05iritkatrielsetstatus: pending -> closed
stage: patch review -> resolved
2021-09-08 13:31:22iritkatrielsetstatus: open -> pending

nosy: + iritkatriel
messages: + msg401382

resolution: out of date
2019-03-15 23:45:22BreamoreBoysetnosy: - BreamoreBoy
2014-06-25 17:47:01BreamoreBoysetnosy: + BreamoreBoy

messages: + msg221562
versions: + Python 3.5, - Python 3.1, Python 2.7, Python 3.2, Python 3.3
2011-08-31 21:51:24dmalcolmcreate