Title: Top-level exception handler writes to stdout unsafely
Type: behavior Stage: needs patch
Components: Interpreter Core Versions: Python 3.2, Python 3.3, Python 3.4, Python 2.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: belopolsky, codegrunt, exarkun, georg.brandl, jafo, pitrou
Priority: low Keywords:

Created on 2006-11-16 23:50 by exarkun, last changed 2012-10-21 12:32 by pitrou.

File name Uploaded Description Edit
fputsfix.diff codegrunt, 2008-01-19 14:01 Proposed patch review
Messages (10)
msg30568 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2006-11-16 23:50
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.
msg55382 - (view) Author: Sean Reifschneider (jafo) * (Python committer) Date: 2007-08-28 21:20
I don't suppose you could wrangle up a proposed patch to fix this?
msg55410 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2007-08-29 02:38
Not likely, given the number of things on my plate already.
msg55411 - (view) Author: Sean Reifschneider (jafo) * (Python committer) Date: 2007-08-29 03:05
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?
msg55852 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2007-09-12 18:11
I'll look into it.
msg60162 - (view) Author: Lorenzo Stoakes (codegrunt) Date: 2008-01-19 14:01
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 :-)
msg60192 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2008-01-19 16:43
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.
msg60200 - (view) Author: Lorenzo Stoakes (codegrunt) Date: 2008-01-19 17:32
Ok, thankyou for your feedback, I will take another look at it.
msg123012 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-12-01 20:52
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.
msg173447 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-10-21 12:32
This is certainly a low-priority issue, as it will almost never happen in practice.
Date User Action Args
2012-10-21 12:32:30pitrousetpriority: high -> low
versions: + Python 3.4
nosy: + pitrou

messages: + msg173447

stage: test needed -> needs patch
2012-10-20 20:13:40serhiy.storchakasetnosy: - serhiy.storchaka
2012-10-20 20:13:22serhiy.storchakasetmessages: - msg162876
2012-10-06 11:51:25georg.brandlsetassignee: georg.brandl ->
2012-06-15 08:59:19serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg162876
2011-06-12 21:29:52terry.reedysetversions: + Python 3.3, - Python 2.6, Python 3.1
2010-12-01 20:52:36belopolskysetkeywords: - easy
nosy: + belopolsky
messages: + msg123012

2010-05-11 20:53:34terry.reedysetversions: + Python 2.7, Python 3.2
2009-05-15 02:24:47ajaksu2setstage: test needed
type: behavior
versions: + Python 3.1
2008-01-19 17:32:11codegruntsetmessages: + msg60200
2008-01-19 16:43:03exarkunsetmessages: + msg60192
2008-01-19 14:01:26codegruntsetfiles: + fputsfix.diff
nosy: + codegrunt
messages: + msg60162
2008-01-12 01:28:40akuchlingsetkeywords: + easy
2008-01-04 04:11:04christian.heimessetversions: + Python 2.6
2007-09-12 18:11:54georg.brandlsetnosy: + georg.brandl
messages: + msg55852
2007-08-29 03:05:40jafosetassignee: georg.brandl
messages: + msg55411
2007-08-29 02:38:17exarkunsetmessages: + msg55410
2007-08-28 21:20:14jafosetnosy: + jafo
messages: + msg55382
2006-11-16 23:50:09exarkuncreate