[Python-bugs-list] [ python-Bugs-448351 ] coredump in selectmodule.c on Solaris 8
noreply@sourceforge.net
noreply@sourceforge.net
Tue, 02 Apr 2002 06:44:22 -0800
Bugs item #448351, was opened at 2001-08-06 04:23
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448351&group_id=5470
Category: Extension Modules
Group: Platform-specific
>Status: Open
>Resolution: Remind
>Priority: 7
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: coredump in selectmodule.c on Solaris 8
Initial Comment:
I get coredump if I run a small script with Python 2.0
on Solaris 8, compiled with Sun CC Forte 6.1 compiler
(64 bits). I suggest to run it more than once to
produce the error. Purify showed me that there are
reading and writings outside the stack boundary.
The interesting part of the source:
Modules/selectmodule.c
.
.
static PyObject *
select_select(PyObject *self, PyObject *args)
{
#ifdef MS_WINDOWS
/* This would be an awful lot of stack space on
Windows! */
pylist *rfd2obj, *wfd2obj, *efd2obj;
#else
pylist rfd2obj[FD_SETSIZE + 3];
pylist wfd2obj[FD_SETSIZE + 3];
pylist efd2obj[FD_SETSIZE + 3];
#endif
.
.
.
}
In our environment FD_SETSIZE is 65536 as defined in
sys/select.h (see
below). The allocated stack space in select_select is
3*sizeof(rfd2obj)*(FD_SETSIZE+3). It is more than
3Mbytes. The difference between the addresses of the
same variable in two
seperate threads is about 2Mbytes. Lets suppose char
*p1 = (char *)rfd2obj
in thread N and char *p2 = (char *)rfd2obj in thread N
+ 1, abs(p1-p2)
is about 2MB (dbx showed this). The stack is
overwritten between the threads. Is it possible that
the stack size is limited to 2 Mbytes per thread? We
fixed it as solved on Windows allocating these
variables on the heap.
Select.h from Solaris 8.
/usr/include/sys/select.h:
.
.
#ifndef FD_SETSIZE
#ifdef _LP64
#define FD_SETSIZE 65536
#else
#define FD_SETSIZE 1024
#endif /* _LP64 */
.
.
----------------------------------------------------------------------
>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-02 09:44
Message:
Logged In: YES
user_id=6380
Reopened and raised priority to 7. We should get this sorted
out for 2.2.1 final is released.
----------------------------------------------------------------------
Comment By: Troels Walsted Hansen (troels)
Date: 2002-01-16 13:02
Message:
Logged In: YES
user_id=32863
Unfortunately 1024 is too much as well. I just finished a
long session with Purify on Solaris (with
FD_SETSIZE==1024), and stack corruption occurs unless I
change the test to "#if FD_SETSIZE > 1023"
Maybe the limit should be lowered to 511 so Windows users
will get same behaviour as the old code?
I have been testing Python 2.2, browsing CVS tells me the
code is the same at this point in time.
----------------------------------------------------------------------
Comment By: Barry Warsaw (bwarsaw)
Date: 2001-10-18 15:48
Message:
Logged In: YES
user_id=12800
Ah I forgot to close this bug report. This code's been in
the source long enough to have uncovered problems if there
were any.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-08-16 17:58
Message:
Logged In: YES
user_id=31435
Back to Barry for re-testing on Linux: I checked in
another version that refuses to add 3 to FD_SETSIZE
anymore. Fortune favors the bold.
----------------------------------------------------------------------
Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 12:53
Message:
Logged In: YES
user_id=12800
I've just checked in a minimal patch, taking the easy way
out (i.e. testing for FD_SETSIZE > 1024). This subtly
changes the behavior on Windows (where Tim says the value is
now 512) since Windows won't normally take the
allocate-on-heap path now.
selectmodule.c 2.54 has the change.
The changes pass on Linux both for normal, small FD_SETSIZEs
and for artificially cranked FD_SETSIZEs. Assigning back to
Tim for verification on Windows.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-08-06 16:52
Message:
Logged In: YES
user_id=31435
Reassigned to Barry. I may a good choice to write the
code, but not to test it (I know zilch about sockets, and
can't provoke the problem on Windows anyway).
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 08:36
Message:
Logged In: YES
user_id=6380
Dear Anonymous,
a quick workaround is to change the three #ifdef MS_WINDOWS
in selectmodule.c into #if FD_SETSIZE > 1024.
A better idea is currently being discussed on python-dev.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-06 04:31
Message:
Logged In: NO
The attachment missed, this is the mentioned script:
import threading
import telnetlib
def telnetToHost():
hostname = "my_hostname"
username = "user_name"
password = "password"
tn = telnetlib.Telnet(hostname)
tn.read_until("login: ")
tn.write(username + '\n')
tn.read_until("Password: ")
tn.write(password + '\n')
class MyThread(threading.Thread):
def run(self):
print "ThreadID", self.cnt, "started"
telnetToHost()
print "ThreadID", self.cnt, "finished"
for i in range(0,4):
m = MyThread()
m.cnt = i
m.start()
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448351&group_id=5470