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.

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.

Logged In: YES 
user_id=44345

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

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.

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.

Logged In: YES 
user_id=44345

No, we're still discussing stdin.  My only point is that what
you do might be predicated on whether or not you think you
can communicate with the user on stderr.

My thought was that if stderr is valid you can raise an exception
that prints a traceback.  If not, Py_FatalError is your only
recourse.  Your code checks for the directori-ness of stdin as
the first thing, then bails if it is.  If it checked to see if stderr was
valid first, it could decide to raise SystemError instead of
calling Py_FatalError.

Logged In: YES 
user_id=33168

Ok, I understand that part.  But if you can't accept input
from the user, what can you do?

If all you are suggesting is to change Py_FatalError() to
raising a SystemError and still exiting, I'm fine with that
if it can work.  I agree this would probably be nicer too. 
Or am I still missing your point?  Do you want to work on a
patch?  I'm fine with any improvement, I'm just not sure how
much can be done.  If you want to improve the error message,
that would be good too.

Logged In: YES 
user_id=33168

I just changed this to print an error message and exit in 2.5.

Logged In: YES 
user_id=849994

Closing then.