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: 2006-03-08 22:03
Message:
Logged In: YES
user_id=33168
I just changed this to print an error message and exit in 2.5.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-14 16:16
Message:
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.
----------------------------------------------------------------------
Comment By: Skip Montanaro (montanaro)
Date: 2005-11-14 15:57
Message:
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.
----------------------------------------------------------------------
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
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
