Repository navigation
errors writing to stdout during interpreter exit exit with status 0 #69052
Description
| BPO | 24864 |
|---|---|
| Nosy | @rbtcollins, @vadmium, @serhiy-storchaka |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2015-08-15.00:48:35.581>
created_at = <Date 2015-08-14.08:59:02.195>
labels = []
title = 'errors writing to stdout during interpreter exit exit with status 0'
updated_at = <Date 2015-08-15.00:48:35.580>
user = 'https://github.com/rbtcollins'bugs.python.org fields:
activity = <Date 2015-08-15.00:48:35.580>
actor = 'rbcollins'
assignee = 'none'
closed = True
closed_date = <Date 2015-08-15.00:48:35.581>
closer = 'rbcollins'
components = []
creation = <Date 2015-08-14.08:59:02.195>
creator = 'rbcollins'
dependencies = []
files = []
hgrepos = []
issue_num = 24864
keywords = []
message_count = 9.0
messages = ['248570', '248571', '248573', '248575', '248578', '248580', '248582', '248624', '248627']
nosy_count = 3.0
nosy_names = ['rbcollins', 'martin.panter', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue24864'
versions = ['Python 3.6']
Activity
rbtcollins commentedon Aug 14, 2015
I was trying to demonstrate how testing some code is hard, and I stumbled upon this.
The following code should be debuggable when run with a bad stdout - e.g.
python foo.py > /dev/full
---
Here is a transcript of a session with it:
---
The same thing done on stderr exits with an exit code of 0 as well.
rbtcollins commentedon Aug 14, 2015
Oh, and for added joy sys.last_value is not set here, so I've yet to manage to poke at what is being executed - clearly pdb is still managing to single-step, ish.
serhiy-storchaka commentedon Aug 14, 2015
See also bpo-11380.
rbtcollins commentedon Aug 14, 2015
FWIW Python 2.7.8 behaves the same way (different message, same behaviour).
rbtcollins commentedon Aug 14, 2015
Oh, one nuance - the reason my except isn't triggering is that the write is happening in interpreter shutdown - in flush_std_files.
Adding a a flush there allows that to work, but its fugly:
---
try:
print("What... is your quest?")
# Workaround bug 24864: force the write to be immediate
sys.stdout.flush()
except:
sys.stderr.write("Exception in program.\n")
e = sys.exc_info()[1]
try:
# Workaround bug 24864 close the file so flush_std_files doesn't run
# during interpreter cleanup.
sys.stdout.close()
finally:
raise e from None
---
rbtcollins commentedon Aug 14, 2015
Updating the title to reflect my deeper understanding: the only issue here is that we don't alter the exit code.
[-]errors writing to stdout are uncatchable and exit with status 0[/-][+]errors writing to stdout during interpreter exit exit with status 0[/+]vadmium commentedon Aug 14, 2015
I don’t know much about PDB, but if this is just about setting the exit code, it may be a dupe of bpo-5319. The fix proposed there is a new Py_FinalizeEx() API that returns an exit status, if I remember correctly.
rbtcollins commentedon Aug 14, 2015
This patch is a minimal stab at the issue.
We should do this change because as it stands genuine user affecting errors can be masked both in pipelines and non-pipeline cases.
A more comprehensive patch would also change e.g. Py_Exit, and the various other users of Py_Finalize like freeze.
I'm not sure where to add an automated test for this; it does sane things under my manual testing.
rbtcollins commentedon Aug 14, 2015
Oh, just saw your comment Martin; yes, this does look like a dupe.