msg30568 - (view) |
Author: Jean-Paul Calderone (exarkun) * |
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) * |
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) * |
Date: 2007-08-29 02:38 |
Not likely, given the number of things on my plate already.
|
msg55411 - (view) |
Author: Sean Reifschneider (jafo) * |
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) * |
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) * |
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) * |
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) * |
Date: 2012-10-21 12:32 |
This is certainly a low-priority issue, as it will almost never happen in practice.
|
msg409364 - (view) |
Author: Irit Katriel (iritkatriel) * |
Date: 2021-12-30 12:37 |
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 Issue45635.
|
|
Date |
User |
Action |
Args |
2022-04-11 14:56:21 | admin | set | github: 44242 |
2022-01-09 12:11:59 | iritkatriel | set | status: pending -> closed stage: needs patch -> resolved |
2021-12-30 12:37:13 | iritkatriel | set | status: open -> pending
nosy:
+ iritkatriel messages:
+ msg409364
resolution: out of date |
2020-11-10 19:59:30 | iritkatriel | set | versions:
+ Python 3.8, Python 3.9, Python 3.10, - Python 2.7, Python 3.2, Python 3.3, Python 3.4 |
2012-10-21 12:32:30 | pitrou | set | priority: high -> low versions:
+ Python 3.4 nosy:
+ pitrou
messages:
+ msg173447
stage: test needed -> needs patch |
2012-10-20 20:13:40 | serhiy.storchaka | set | nosy:
- serhiy.storchaka
|
2012-10-20 20:13:22 | serhiy.storchaka | set | messages:
- msg162876 |
2012-10-06 11:51:25 | georg.brandl | set | assignee: georg.brandl -> |
2012-06-15 08:59:19 | serhiy.storchaka | set | nosy:
+ serhiy.storchaka messages:
+ msg162876
|
2011-06-12 21:29:52 | terry.reedy | set | versions:
+ Python 3.3, - Python 2.6, Python 3.1 |
2010-12-01 20:52:36 | belopolsky | set | keywords:
- easy nosy:
+ belopolsky messages:
+ msg123012
|
2010-05-11 20:53:34 | terry.reedy | set | versions:
+ Python 2.7, Python 3.2 |
2009-05-15 02:24:47 | ajaksu2 | set | stage: test needed type: behavior versions:
+ Python 3.1 |
2008-01-19 17:32:11 | codegrunt | set | messages:
+ msg60200 |
2008-01-19 16:43:03 | exarkun | set | messages:
+ msg60192 |
2008-01-19 14:01:26 | codegrunt | set | files:
+ fputsfix.diff nosy:
+ codegrunt messages:
+ msg60162 |
2008-01-12 01:28:40 | akuchling | set | keywords:
+ easy |
2008-01-04 04:11:04 | christian.heimes | set | versions:
+ Python 2.6 |
2007-09-12 18:11:54 | georg.brandl | set | nosy:
+ georg.brandl messages:
+ msg55852 |
2007-08-29 03:05:40 | jafo | set | assignee: georg.brandl messages:
+ msg55411 |
2007-08-29 02:38:17 | exarkun | set | messages:
+ msg55410 |
2007-08-28 21:20:14 | jafo | set | nosy:
+ jafo messages:
+ msg55382 |
2006-11-16 23:50:09 | exarkun | create | |