[Python-bugs-list] [ python-Bugs-478001 ] uninit mem read w/signals

[noreply@sourceforge.net]

Bugs item #478001, was opened at 2001-11-04 06:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478001&group_id=5470

>Category: Python Interpreter Core
Group: Python 2.2
Status: Open
>Resolution: Rejected
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Tim Peters (tim_one)
Summary: uninit mem read w/signals

Initial Comment:
if the signal()/sigaction() fails,
uninitialized memory is returned.

the attached patch fixes the problem
(didn't test signal() path, only the sigaction() path)

Neal

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-11-13 14:01

Message:
Logged In: YES 
user_id=12800

Note sigaction() returns 0 on success, -1 on failure,
setting the errno code, while signal() returns SIG_ERR on
failure.  Because PyOS_*sig() attempts to provide a unified
interface to the two different functions, we can't support
both, and forcing a return of SIG_ERR when sigaction() fails
seems to make the most sense.  Still, it might be nice to be
able to get the more detailed error message when available,
and that means we should set the exception (OSError?) and
return NULL.

And then there's the documentation and backward
compatibility problem that Tim mentions. :(
I'm not sure what the right answer is.  Of the sigaction()
errors, it seems that only EINTR should be possible to get
from Python (since Python does its own sanity checking on
the signal number, etc.).

I'm inclined to reject the patch unless it is modified to
address the following issues:

- return SIG_ERR in all cases when an error occurs
- change the call locations to check for this error   
  condition. 
- preferrably include some test cases (either Python or 
  using the CAPI test framework).
- document the new behavior in the C API manual

My vote: -1 for changing this in Python 2.2.  Rejecting, and
reassigning to Tim.  Not closed. Changed the bug category.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-11-04 11:45

Message:
Logged In: YES 
user_id=31435

Assigned to Barry.  Neal's surely correct that we shouldn't 
be ignoring errors, but returning NULL isn't right either.  
Should we force return of SIG_ERR then?  That's the only 
*natural* "error return" value, and there's a backward 
compatibility problem here since we don't document anything 
about error returns for the {get,set}sig functions, nor do 
any of the places we call these check for an error return.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478001&group_id=5470