[Python-bugs-list] [ python-Bugs-476648 ] socket.getnameinfo crashes interpreter
noreply@sourceforge.net
noreply@sourceforge.net
Thu, 01 Nov 2001 21:24:51 -0800
Bugs item #476648, was opened at 2001-10-30 20:58
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476648&group_id=5470
Category: Python Library
Group: None
>Status: Open
Resolution: Works For Me
>Priority: 7
Submitted By: Mark Rowe (icep17)
Assigned to: Martin v. Löwis (loewis)
Summary: socket.getnameinfo crashes interpreter
Initial Comment:
When making an invalid call to socket.getnameinfo() it
is possible to crash the interpreter. From what I've
seen, this occurs under Windows ME with Python 2.2b1
and Windows 98 with Python 2.2a3. It does not occur
under Mandrake 8.0 with Python 2.2a3.
>>> import socket
>>> socket.getnameinfo(socket.inet_aton('127.0.0.1'), 0)
This results with Python causing an error in
MSVCRT.DLL. Under Mandrake 8.0 it causes the expected
exception:
Traceback (most recent call last):
File "<stdin>", line 1, in ?
SystemError: new style getargs format but argument is
not a tuple
----------------------------------------------------------------------
>Comment By: Tim Peters (tim_one)
Date: 2001-11-01 21:24
Message:
Logged In: YES
user_id=31435
Re-opened this and raised priority. Martin, near the start
of PySocket_getnameinfo we've got
n = PyArg_ParseTuple(sa, "si|ii", &hostp, &port, &flowinfo,
scope_id);
and that's surely incorrect (note that we're not passing
the address of scope_id there! we're passing its value,
and scope_id is uninitialized stack trash).
There's more than just that going on here, though. If
that's repaired, the PyArg_ParseTuple fails, and so it
jumps to the "fail:" label, and sa gets decref'ed there.
But sa was obtained from a previous PyArg_ParseTuple call,
so should not be decref'ed by this routine (this routine
has a borrowed reference to sa). That part almost
certainly explains the "negative refcount" msg icep17 sees
in a debug build.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-01 20:15
Message:
Logged In: NO
I can reproduce it with 2.2b1 on Win9x, and by using that
same code.
----------------------------------------------------------------------
Comment By: Mark Rowe (icep17)
Date: 2001-11-01 20:05
Message:
Logged In: YES
user_id=147838
Under Windows ME with Python 2.2b1 I still get the crash. I
have asked my friend to check it (Windows 95c Python 2.2b1)
and he also gets the crash. I compiled the debug build of
Python and running the above code in an interpreter session
gives:
Adding parser accelerators ...
Done.
Python 2.2b1 (#25, Oct 21 2001, 13:42:02) [MSC 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import socket
[8983 refs]
>>> socket.getnameinfo(socket.inet_aton('127.0.0.1'), 0)
C:\Program
Files\python22\Python-2.2b1\Objects\tupleobject.c:147
negative ref co
unt -572662308
Traceback (most recent call last):
File "<stdin>", line 1, in ?
SystemError: new style getargs format but argument is not a
tuple
[9020 refs]
>>>
The Debug build of Python does not crash, but instead
reports a negative refrence count, which could be the cause
of the crash in the release build. As I am not too familiar
with the internals of Python I have trouble understanding
what is happening when running the interpreter under the
debugger, but if you would like some more detail I will
happily provide it.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-11-01 06:22
Message:
Logged In: YES
user_id=21627
I cannot reproduce this in 2.2b1 (it works the same on
Win32 as it does on Linux), but I also fail to see what
code change may have caused to fail it in 2.2a3.
Please update to 2.2b1 and retest; if it still happens,
check that you don't have any extra copies of
python22.dll. If so, please add a note in this report, and
we'll re-open it.
If you can, it would help enourmously if you could run the
program in a debugger and report the stack trace in case
of error, and the file and line number causing the crash.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476648&group_id=5470