[ python-Bugs-1441530 ] socket read() can cause MemoryError in Windows

2006-03-02 Thread SourceForge.net
Bugs item #1441530, was opened at 2006-03-02 10:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441530&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 Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: taukki (taukki)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket read() can cause MemoryError in Windows

Initial Comment:
When a big mail (>10MB) is fetched MemoryError may
result (reproduced in Windows XP/2003, Python 2.41):

Traceback (most recent call last):
  File "t5.py", line 9, in ?
data = f.read(26872159)
  File "c:\python24\lib\socket.py", line 307, in read
data = self._sock.recv(recv_size)
MemoryError

The problem is not actually in imaplib (though it
requests the whole mail in one read), but probably in
combination of socket core code and the implementation
of read() function (he way it buffers the received data
in a list?). I can easily reproduce the problem e.g
with these snippets:

CLIENT->
import socket
import time

s = socket.socket()

s.connect(("127.0.0.1", 8037))
f = s.makefile("r", 20)
while 1:
  data = f.read(26872159) # Using smaller value here  
helps, 10 seems to work forever...
  #data = s.recv(26872159) # THIS WORKS OK
  print len(data)

-SERVER->
import SocketServer
import time

PORT = 8037
time.sleep(0.2)

s = "X" * 1823
class
TimeRequestHandler(SocketServer.StreamRequestHandler):
def handle(self):
  for x in range(20):
self.wfile.write(s)
print x


server = SocketServer.TCPServer(("", PORT),
TimeRequestHandler)
print "listening on port", PORT
server.serve_forever()





--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441530&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1441864 ] Omission in docs for urllib2.urlopen()

2006-03-02 Thread SourceForge.net
Bugs item #1441864, was opened at 2006-03-02 16:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441864&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: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Kent Johnson (kjohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Omission in docs for urllib2.urlopen()

Initial Comment:
The docs for urllib2.urlopen() don't explicitly say
that if the data parameter is provided then it will do
a POST. I suggest replacing the second paragraph
(beginning with "data should be a string") with this text:

In HTTP requests, the optional data argument may be
given to specify a POST request (normally the request
type is GET). The data argument must be in standard
application/x-www-form-urlencoded format, for example
one returned from urllib.urlencode().


Kent

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441864&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1441884 ] A (treaded) Python crash only on dual core machines

2006-03-02 Thread SourceForge.net
Bugs item #1441884, was opened at 2006-03-02 18:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441884&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: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: A (treaded) Python crash only on dual core machines

Initial Comment:
There is a strange freeze/crash only on dual core machines:

I have a python app (Python 2.3.5 /Pythonwin build 203
/ Windows) running with no stability problems on normal
machines (Or a crash is so rare, that absolutely nobody
obverses it, though the overall majority of users uses
single core machines). Threads, network &
pythonwin/win32ui all in use.

Yet, from 3 users, _all_ using a Dual Processor System
(XEON, amd x2 3800+) computer, I have reports, that the
application freezes hard and/or crashes with a kind of
random stack dump (operating system). I cannot
experiment with those machines.

I found no hints other than:

http://groups.google.de/group/comp.lang.python/browse_frm/thread/64ca033e1a7f6c61/719b147e870bd5e6

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=480325

.. both discussions remaining in uncertainty.

Are there (known) problems with Python/Pythonwin
specifically for dual core's  (py2.3.5 / pywin203) ?

What could I do to find the problem?

Robert


--

PS: there is very little C extension-code (SWIG)
involved, yet I looked over that so often, I guess its
save:


//

#include "stdafx.h"
#include "commctrl.h"
#include "ext.h"

BOOL APIENTRY DllMain( HANDLE hModule,
   DWORD  ul_reason_for_call,
   LPVOID lpReserved
 )
{
return TRUE;
}

class CAllowThreads {
public:
PyThreadState *_save; \
CAllowThreads() {
_save = PyEval_SaveThread();
}
~CAllowThreads() {
PyEval_RestoreThread(_save);
}
};

PyObject* PyListView_GetSubItemRect(
HWND hwndLV,
int iItem,
int iSubItem,
int code
//LPRECT lpRect
)
{
RECT r;
{
  CAllowThreads _t;
  ListView_GetSubItemRect(
hwndLV,
iItem,
iSubItem,
code,
&r );
}
return Py_BuildValue("",
r.left,r.top,r.right,r.bottom);

}

int GetStringAddr(const char* s) {
return (int)s;
}

int PlaySoundResource(int resid, HMODULE hmod)
{
CAllowThreads _t;
return PlaySound(MAKEINTRESOURCE(resid), hmod,
SND_RESOURCE);
}

int PlaySoundFile(const char* fname, int flag)
{
CAllowThreads _t;
return PlaySound(fname, NULL, flag);
}

PyObject* py_ToolTipRelayMsg(  PyObject* self,
PyObject* args )
{
MSG msg;
HWND hwTT;
   
if(!PyArg_ParseTuple(args,"i(i(ii)):ToolTipRelayMsg",
 &hwTT,

&msg.hwnd,&msg.message,&msg.wParam,&msg.lParam,&msg.time,
 &msg.pt, ((int*)&msg.pt)+1) )
return NULL;


{
  CAllowThreads _t;
  SendMessage(hwTT,TTM_RELAYEVENT,0,(LPARAM)&msg);
}

Py_INCREF( Py_None );
return Py_None;
}

---

"GetStringAddress" is used only once like this (leades
to correct NUL termination I think):

self.sb.SendMessage(commctrl.SB_SETTEXT,iPane,extension.GetStringAddr(text))

--- swig:
static PyObject *_wrap_GetStringAddr(PyObject *self,
PyObject *args) {
PyObject *resultobj;
char *arg0 ;
int result ;

if(!PyArg_ParseTuple(args,(char
*)"s:GetStringAddr",&arg0)) return NULL;
result = (int )GetStringAddr((char const *)arg0);
resultobj = PyInt_FromLong((long)result);
return resultobj;
} 

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441884&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1441984 ] Multiple simultaneous sendtos on AF_UNIX socket broken.

2006-03-02 Thread SourceForge.net
Bugs item #1441984, was opened at 2006-03-02 19:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441984&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 Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Brunswick (bdbrunswick)
Assigned to: Nobody/Anonymous (nobody)
Summary: Multiple simultaneous sendtos on AF_UNIX socket broken.

Initial Comment:
Using the same AF_UNIX socket to do multiple
simultaneous calls to sendto from different threads,
the messages get their to address mixed up.

This is because of the use of a static per-socket
buffer s->sock_addr in Modules/socketmodule.c function
getsockaddrarg. It needs to be per thread.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441984&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1442012 ] Traceback in pydoc

2006-03-02 Thread SourceForge.net
Bugs item #1442012, was opened at 2006-03-02 21:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442012&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Traceback in pydoc

Initial Comment:
On some objects I have, calling 'help(obj)' raises an
exception.  Python 2.4.2, Windows XP.

This is the traceback, together with some info from
pdb.pm():

>>> help(r)
Traceback (most recent call last):
  File "", line 1, in ?
  File "C:\Python24\lib\site.py", line 328, in __call__
return pydoc.help(*args, **kwds)
  File "c:\python24\lib\pydoc.py", line 1647, in __call__
self.help(request)
  File "c:\python24\lib\pydoc.py", line 1691, in help
else: doc(request, 'Help on %s:')
  File "c:\python24\lib\pydoc.py", line 1475, in doc
pager(title % desc + '\n\n' + text.document(object,
name))
  File "c:\python24\lib\pydoc.py", line 296, in document
if inspect.isclass(object): return self.docclass(*args)
  File "c:\python24\lib\pydoc.py", line 1193, in docclass
lambda t: t[1] == 'method')
  File "c:\python24\lib\pydoc.py", line 1143, in spill
name, mod, object))
  File "c:\python24\lib\pydoc.py", line 301, in document
return self.docother(*args)
  File "c:\python24\lib\pydoc.py", line 1290, in docother
chop = maxlen - len(line)
TypeError: unsupported operand type(s) for -:
'_compointer_meta' and 'int'
>>> import pdb
>>> pdb.pm()
> c:\python24\lib\pydoc.py(1290)docother()
-> chop = maxlen - len(line)
(Pdb) args
self = 
object = 
name = Item
mod = None
maxlen = 
doc = None
(Pdb) where
  (1)?()
  c:\python24\lib\site.py(328)__call__()
-> return pydoc.help(*args, **kwds)
  c:\python24\lib\pydoc.py(1647)__call__()
-> self.help(request)
  c:\python24\lib\pydoc.py(1691)help()
-> else: doc(request, 'Help on %s:')
  c:\python24\lib\pydoc.py(1477)doc()
-> print value
  c:\python24\lib\pydoc.py(299)document()
-> pass
  c:\python24\lib\pydoc.py(1193)docclass()
-> lambda t: t[1] == 'method')
  c:\python24\lib\pydoc.py(1143)spill()
-> name, mod, object))
  c:\python24\lib\pydoc.py(301)document()
-> return self.docother(*args)
> c:\python24\lib\pydoc.py(1290)docother()
-> chop = maxlen - len(line)
(Pdb)


The problem seems to be that the TextDoc.docother
method is called with unexpected arguments.

The signature is 
docother(object, name, mod, maxlen, doc)

but it is called with the object to document as the
'maxlen' parameter.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442012&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com