[ python-Bugs-1353504 ] Python drops core when stdin is bogus

[SourceForge.net]

Bugs item #1353504, was opened at 2005-11-10 14:16
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Python drops core when stdin is bogus

Initial Comment:
Someone here at work had the bright idea to execute a
Python
script from a Solaris 10 ~/.dtprofile file. 
Apparently, at the time
that script is run stdin is bogus.  Python core dumps
with this
gdb backtrace:

#0  0x0807d290 in PyDict_SetItem (op=0x815b79c,
key=0x8163f20, value=0x0)
    at ../Objects/dictobject.c:549
#1  0x0807e0f7 in PyDict_SetItemString (v=0x815b79c,
key=0x8118df2 "stdin",
    item=0x0) at ../Objects/dictobject.c:1988
#2  0x080e0d03 in _PySys_Init () at
../Python/sysmodule.c:977
#3  0x080ddfdb in Py_InitializeEx (install_sigs=1) at
../Python/pythonrun.c:190
#4  0x080dfa89 in Py_Initialize () at
../Python/pythonrun.c:283
#5  0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at
../Modules/main.c:418
#6  0x0805ca13 in main (argc=3, argv=0x8047c08) at
../Modules/python.c:23

(This is from 2.4.2, but it also happens in 2.3.4.)

Looking at the code in _PySys_Init it calls

    sysin = PyFile_FromFile(stdin, "<stdin>", "r", NULL);

which returns NULL.  In PyFile_FromFile it creates a new
PyFileObject, then initializes it by calling a static
function,
fill_file_fields.  This apparently fails, causing a NULL
pointer return.  Back in _PySys_Init it checks
PyErr_Occurred,
but fill_file_fields never raised an except.  The NULL
pointer
is passed to PyDict_SetItemString and havoc ensues.

I haven't checked CVS, but 2.4 (and probably 2.3) should be
fixed.  I suggest raising an IOError in
fill_file_fields instead
of just setting f to NULL and returning it.


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-14 14:08

Message:
Logged In: YES 
user_id=33168

Did you mistype and still mean stdin or are we talking about
stderr?

IIRC, calling Py_FatalError() was what I intended if stdin
is bogus.  I don't know what else to do.  If you can think
of scenarios where we could improve the behaviour, I think
that's fine to do.  I suppose you could set stdin to None,
but I'm not sure what that would do or if it would improve
anything.

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

Comment By: Skip Montanaro (montanaro)
Date: 2005-11-14 14:01

Message:
Logged In: YES 
user_id=44345

Well, I built from CVS^H^H^HSubversion HEAD at work and tried
again.  Still got a core dump, but that was a side-effect of
calling
Py_FatalError.  Is that the intended behavior?  I guess with a
bogus stderr that makes sense, but if stderr happened to be
valid at this point, I'd rather have it raise something more
meaningful for the user, like SystemError.


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

Comment By: Skip Montanaro (montanaro)
Date: 2005-11-12 05:18

Message:
Logged In: YES 
user_id=44345

Thanks Neal.  I'll check it out at work next week.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-10 23:24

Message:
Logged In: YES 
user_id=33168

This should be fixed in 2.4.3 and CVS (2.3.5 is probably
affected too).  I remember dealing with directories
specifically.  Checkout the current sysmodule.c.  Here's the
checkin:  

r39652 | nnorwitz | 2005-10-02 18:03:46 -0700 (Sun, 02 Oct
2005) | 5 lines

SF bug #887946.

Let me know if this bug is different and the patch doesn't
solve the problem.

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

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