This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Signals discard one level of exception handling
Type: Stage:
Components: Interpreter Core Versions:
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: dmaurer, facundobatista, mwh
Priority: normal Keywords:

Created on 2003-07-15 06:57 by dmaurer, last changed 2022-04-10 16:09 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
771429.py mwh, 2004-11-09 11:33 mwh's failed attempt to reproduce
Messages (5)
msg17064 - (view) Author: Dieter Maurer (dmaurer) Date: 2003-07-15 06:57
Signals handled by Python (especially KeyboardInterrupt) 
may discard one level of exception handling.

Consider the following code fragment:

try: # outer exception handling level
  try: # inner exception handling level
    blocking_external_extension_function()
  except:
    print "inner exception handling"
except:
  print "outer exception handling"

Assume that "blocking_external_extension_function"
is an external function (implemented in "C") that
blocks until interrupted by a signal (EINTR) and
then returns with an exception but without handling
the signal. In our concrete case, 
"blocking_external_extension_function" has been
"psycopg.connect" (the database "connect" from the
Python-PostgreSQL bridge "psycopg").

In this case, when you interrupt the execution,
while "blocking_external_extension_function"
waits, the "KeyboardInterrupt" is not caught in
the inner "try: ...except: ..." but only in the outer
"try: ... except: ..."

The following happens in detail in Python's main 
interpreter loop:

  *  "blocking_external_extension_function" returns with
     an exception.

  *  Python sets the next instruction to the exception
     handler of the inner exception handling

  *  Python begins a new run through its main loop.
     At the start, it detects the "KeyboardInterrupt"
     signal. It now thinks, the "KeyboardInterrupt" were
     caused inside the inner exception handler
     and pops this exception handling level without
     executing it.

     The interpreter has lost one level of exception 
handling.

The behaviour would probably better fit with expectations, 
when the interpreter would check for signals at the end of 
its main loop and before it sets its instruction pointer to the 
exception handler. 
msg17065 - (view) Author: Facundo Batista (facundobatista) * (Python committer) Date: 2004-11-08 23:45
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo
msg17066 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2004-11-09 11:16
Logged In: YES 
user_id=6656

In addition, attaching any code samples rather than including them 
would seem a good idea.  I can't make head or tail of the code in 
the summary.
msg17067 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2004-11-09 11:33
Logged In: YES 
user_id=6656

Oh, after some judicious view-sourcing and query-replacing, I get 
the problem.  However, I can't reproduce it (see attached script).

So we're back to needing a failing example and more platform 
details.
msg17068 - (view) Author: Facundo Batista (facundobatista) * (Python committer) Date: 2005-01-15 21:26
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.    Facundo
History
Date User Action Args
2022-04-10 16:09:58adminsetgithub: 38854
2003-07-15 06:57:57dmaurercreate