Top-level exception handler writes to stdout unsafely

[exarkun]

BPO	1598083
Nosy	@birkenfeld, @abalkin, @pitrou, @iritkatriel
Files	fputsfix.diff: Proposed patch

^{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 2022-01-09.12:11:59.368>
created_at = <Date 2006-11-16.23:50:09.000>
labels = ['interpreter-core', 'type-bug', '3.8', '3.9', '3.10']
title = 'Top-level exception handler writes to stdout unsafely'
updated_at = <Date 2022-01-09.12:11:59.367>
user = 'https://bugs.python.org/exarkun'

bugs.python.org fields:

activity = <Date 2022-01-09.12:11:59.367>
actor = 'iritkatriel'
assignee = 'none'
closed = True
closed_date = <Date 2022-01-09.12:11:59.368>
closer = 'iritkatriel'
components = ['Interpreter Core']
creation = <Date 2006-11-16.23:50:09.000>
creator = 'exarkun'
dependencies = []
files = ['9215']
hgrepos = []
issue_num = 1598083
keywords = []
message_count = 11.0
messages = ['30568', '55382', '55410', '55411', '55852', '60162', '60192', '60200', '123012', '173447', '409364']
nosy_count = 7.0
nosy_names = ['georg.brandl', 'jafo', 'exarkun', 'belopolsky', 'pitrou', 'codegrunt', 'iritkatriel']
pr_nums = []
priority = 'low'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue1598083'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

[exarkun]

When an exception reaches the top frame and is displayed by the exception handler, they are handled by formatting them to stderr. This involves a series of calls to PyFile_WriteString, either directly from PyErr_Display or indirectly through PyTraceBack_Print. Few, if any, of these PyFile_WriteString calls have their result checked for error. Worse, PyFile_WriteString itself does not check the return value of fputs().

So, for example, with a signal handler installed, a signal received while a traceback is being printed can result in the traceback _not_ being printed.

[jafo]

I don't suppose you could wrangle up a proposed patch to fix this?

[exarkun]

Not likely, given the number of things on my plate already.

[jafo]

Ok, thanks JP.

Georg recently touched one of these functions and seemed to do the right
thing with respect to checking errors, so I've assigned it to you. Can
you take this?

[birkenfeld]

I'll look into it.

[codegrunt]

Surely it's not a good idea to attempt to generate an exception within
an exception handler, couldn't this lead to an infinite loop scenario?

The checks prior to fputs() handle any errors by calling err_closed()
and returning -1. I suggest we do the same for the fputs() statement.
According to the documentation for fputs(), any errors result in a
return value of EOF, therefore an if(fputs(...) == EOF) { ... } check
seems appropriate.

I enclose a patch to this end, please let me know whether I'm way off
the mark here :-)

[exarkun]

The attached patch doesn't fix the issue I described:

• err_closed() will raise an exception indicated the file is closed.
  However, the file is not necessarily closed, so this exception is wrong.
• Most or all PyFile_WriteString callers are still not checking its
  return value, so the exception will generally be ignored.
• The traceback still won't be reported.

[codegrunt]

Ok, thankyou for your feedback, I will take another look at it.

[abalkin]

I don't see anything "easy" in this issue. Error handling in exception or signal handlers is quite tricky.

I don't see this as a high priority either, but will leave this for others to decide.

[pitrou]

This is certainly a low-priority issue, as it will almost never happen in practice.

[iritkatriel]

I think this can be closed as out of date because PyFile_WriteString/Object no longer use puts and they do check for errors. The error checking of PyFile_WriteString/Object in the traceback display code was the subject of bpo-45635.