[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