classification
Title: infinite loop in faulthandler._stack_overflow
Type: Stage:
Components: Extension Modules Versions: Python 3.7, Python 3.4
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Paul Murphy, pitrou, ronaldoussoren, vstinner
Priority: normal Keywords: patch

Created on 2015-08-12 20:40 by Paul Murphy, last changed 2019-05-08 17:01 by xry111.

Files
File name Uploaded Description Edit
fix_stack_overflow.patch Paul Murphy, 2015-08-12 20:40 Patch to disable optimizations around stack_overflow under GCC
Messages (6)
msg248472 - (view) Author: Paul Murphy (Paul Murphy) Date: 2015-08-12 20:40
This is a duplicate of Issue 23654, except it occurs on GCC 5.1 with -O2 when building for a ppc64le target.

GCC is optimizes this as a tail call, removing the accesses to the "unused" stack variables.
msg248523 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2015-08-13 15:03
To fix this in a generic way, perhaps the function could update a volatile global variable after the recursive call?
msg248526 - (view) Author: Paul Murphy (Paul Murphy) Date: 2015-08-13 16:14
Somehow, you need to preserve access to the stack memory. The generated code is still growing the stack, it just fails to touch any of it.

I'm guessing a volatile access would just add an extra non-stack access to the infinite loop.

Initially, I had tried creating a non-inlined function to touch the stack memory. It worked in this case, but still required some undesirable compiler specific assistance.
msg248527 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2015-08-13 16:16
> Initially, I had tried creating a non-inlined function to touch the
> stack memory. It worked in this case, but still required some
> undesirable compiler specific assistance.

Hmm... store the non-inlined function's pointer in a volatile global, and call that pointer?
msg248568 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2015-08-14 08:43
GCC has a pragma and function attributes for changing the optimisation flags, that could be used to disable the tail call optimazation here.

Something like the following (using a pragma):

#pragma GCC push_options
#pragma GCC optimize ("-fno-optimize-sibling-calls")
<functions go here>
#pragma GCC pop_options

Note: completely untested, and would need preprocessor guards to avoid warnings with some other compilers.
msg248591 - (view) Author: Paul Murphy (Paul Murphy) Date: 2015-08-14 15:32
...
#pragma GCC optimize ("no-optimize-sibling-calls")
...

Does preserve the desired behavior under -O2 and -O3, probably a bit nicer than using O0.
History
Date User Action Args
2019-05-08 17:01:47xry111setversions: + Python 3.7
2015-08-14 15:32:52Paul Murphysetmessages: + msg248591
2015-08-14 08:43:01ronaldoussorensetnosy: + ronaldoussoren
messages: + msg248568
2015-08-13 16:16:18pitrousetmessages: + msg248527
2015-08-13 16:14:30Paul Murphysetmessages: + msg248526
2015-08-13 15:03:57pitrousetnosy: + pitrou
messages: + msg248523
2015-08-13 02:24:14yselivanovsetnosy: + vstinner
2015-08-12 20:40:48Paul Murphycreate