[issue31092] multiprocessing.Manager() race condition
Lang added the comment: # code reproduce bug # KeyError in lib\multiprocessing\managers.py in incref import multiprocessing as mp from time import sleep def func(queue): pass if __name__ == '__main__': manager = mp.Manager() pool = mp.Pool(1) queue = manager.Queue() r = pool.apply_async(func, args = [queue]) #sleep(1) queue = None pool.close() pool.join() -- nosy: +tlxxzj ___ Python tracker <https://bugs.python.org/issue31092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12860] http client attempts to send a readable object twice
New submission from Lang Martin : on line 765 of client/http.py, the client loops over the read method, sending it's content to the web server. It appears as though the send method should return at this point; instead it falls through and attempts to send the data object through first self.sock.sendall, falling back to the iterable interface. The result is that a readable data object must support a null __iter__ method, or if it supports both a working read and __iter__, the data will be sent to the server twice. Change the break on line 768 to a return, and the expected behavior happens. -- messages: 143227 nosy: langmartin priority: normal severity: normal status: open title: http client attempts to send a readable object twice type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue12860> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9670] Exceed Recursion Limit in Thread
New submission from Jared Lang : Recursion within a thread on OSX can result in a crash by exceeding the systems recursion limit. Recursion behaves as expected if not in thread, meaning it throws a RunTimeError with the message "maximum recursion depth exceeded." The crash is able to be avoided if the recursion limit is set to a lower number, ie. 800, via sys.setrecursionlimit. Example program which crashes on OSX: >>> def f(): ... return f() ... >>> import threading >>> thread = threading.Thread(target=f) >>> thread.start() Bus error Alternatively, the following works as expected: >>> import sys >>> def f(): ... return f() ... >>> import threading >>> thread = threading.Thread(target=f) >>> sys.setrecursionlimit(800) >>> thread.start() >>> Exception in thread Thread-1: Traceback (most recent call last): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/threading.py", line 532, in __bootstrap_inner self.run() File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/threading.py", line 484, in run self.__target(*self.__args, **self.__kwargs) File "", line 2, in f File "", line 2, in f File "", line 2, in f File "", line 2, in f File "", line 2, in f File "", line 2, in f ... RuntimeError: maximum recursion depth exceeded -- assignee: ronaldoussoren components: Macintosh messages: 114787 nosy: jaredlang, ronaldoussoren priority: normal severity: normal status: open title: Exceed Recursion Limit in Thread type: crash versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue9670> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2853] *** glibc detected *** python: double free or corruption
New submission from Michael Lang <[EMAIL PROTECTED]>:
Hi,
i am trying to solve some problems we encounter, when locking files on a
NFS Storage using fcntl.
since this is a security related problem i just add some pseudo code
here that was used to create the problem
fh = os.open('filename')
fcntl.lockf(fh, fcntl.LOCK_EX)
fhw = os.fdopen(fh)
fhw
fcntl.lockf(fh, fcntl.LOCK_UN)
...
when using threads, it's possible to create following problems when
using a Solaris (openSolaris) NFS server:
*** glibc detected *** python: double free or corruption (!prev):
0x1bdbfb20 ***
=== Backtrace: =
/lib64/libc.so.6[0x32b086f4f4]
/lib64/libc.so.6(cfree+0x8c)[0x32b0872b1c]
/lib64/libc.so.6(fclose+0x14b)[0x32b085e75b]
/usr/lib64/libpython2.4.so.1.0[0x32c3e447ce]
/usr/lib64/libpython2.4.so.1.0(PyEval_EvalFrame+0x47c7)[0x32c3e947a7]
/usr/lib64/libpython2.4.so.1.0(PyEval_EvalFrame+0x44a6)[0x32c3e94486]
/usr/lib64/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x925)[0x32c3e95905]
/usr/lib64/libpython2.4.so.1.0[0x32c3e4c263]
/usr/lib64/libpython2.4.so.1.0(PyObject_Call+0x10)[0x32c3e35f90]
/usr/lib64/libpython2.4.so.1.0[0x32c3e3c01f]
/usr/lib64/libpython2.4.so.1.0(PyObject_Call+0x10)[0x32c3e35f90]
/usr/lib64/libpython2.4.so.1.0(PyEval_CallObjectWithKeywords+0x6d)[0x32c3e8f55d]
/usr/lib64/libpython2.4.so.1.0[0x32c3ebb33d]
/lib64/libpthread.so.0[0x32b14062f7]
/lib64/libc.so.6(clone+0x6d)[0x32b08ce85d]
=== Memory map:
0040-00401000 r-xp fd:01 845448
/usr/bin/python
0060-00601000 rw-p fd:01 845448
/usr/bin/python
1bd4d000-1bdd rw-p 1bd4d000 00:00 0
4000-40001000 ---p 4000 00:00 0
40001000-40a01000 rw-p 40001000 00:00 0
40a01000-40a02000 ---p 40a01000 00:00 0
40a02000-41402000 rw-p 40a02000 00:00 0
41402000-41403000 ---p 41402000 00:00 0
41403000-41e03000 rw-p 41403000 00:00 0
41e03000-41e04000 ---p 41e03000 00:00 0
41e04000-42804000 rw-p 41e04000 00:00 0
42804000-42805000 ---p 42804000 00:00 0
42805000-43205000 rw-p 42805000 00:00 0
43205000-43206000 ---p 43205000 00:00 0
43206000-43c06000 rw-p 43206000 00:00 0
43c06000-43c07000 ---p 43c06000 00:00 0
43c07000-44607000 rw-p 43c07000 00:00 0
44607000-44608000 ---p 44607000 00:00 0
44608000-45008000 rw-p 44608000 00:00 0
45008000-45009000 ---p 45008000 00:00 0
45009000-45a09000 rw-p 45009000 00:00 0
45a09000-45a0a000 ---p 45a09000 00:00 0
45a0a000-4640a000 rw-p 45a0a000 00:00 0
32b040-32b041a000 r-xp fd:00 127400
/lib64/ld-2.5.so
32b0619000-32b061a000 r--p 00019000 fd:00 127400
/lib64/ld-2.5.so
32b061a000-32b061b000 rw-p 0001a000 fd:00 127400
/lib64/ld-2.5.so
32b080-32b0946000 r-xp fd:00 127417
/lib64/libc-2.5.so
32b0946000-32b0b46000 ---p 00146000 fd:00 127417
/lib64/libc-2.5.so
32b0b46000-32b0b4a000 r--p 00146000 fd:00 127417
/lib64/libc-2.5.so
32b0b4a000-32b0b4b000 rw-p 0014a000 fd:00 127417
/lib64/libc-2.5.so
32b0b4b000-32b0b5 rw-p 32b0b4b000 00:00 0
32b0c0-32b0c82000 r-xp fd:00 127423
/lib64/libm-2.5.so
32b0c82000-32b0e81000 ---p 00082000 fd:00 127423
/lib64/libm-2.5.so
32b0e81000-32b0e82000 r--p 00081000 fd:00 127423
/lib64/libm-2.5.so
32b0e82000-32b0e83000 rw-p 00082000 fd:00 127423
/lib64/libm-2.5.so
32b100-32b1002000 r-xp fd:00 127455
/lib64/libdl-2.5.so
32b1002000-32b1202000 ---p 2000 fd:00 127455
/lib64/libdl-2.5.so
32b1202000-32b1203000 r--p 2000 fd:00 127455
/lib64/libdl-2.5.so
32b1203000-32b1204000 rw-p 3000 fd:00 127455
/lib64/libdl-2.5.so
32b140-32b1415000 r-xp fd:00 127463
/lib64/libpthread-2.5.so
32b1415000-32b1614000 ---p 00015000 fd:00 127463
/lib64/libpthread-2.5.so
32b1614000-32b1615000 r--p 00014000 fd:00 127463
/lib64/libpthread-2.5.so
32b1615000-32b1616000 rw-p 00015000 fd:00 127463
/lib64/libpthread-2.5.so
32b1616000-32b161a000 rw-p 32b1616000 00:00 0
32b640-32b640d000 r-xp fd:00 127465
/lib64/libgcc_s-4.1.2-20070626.so.1
32b640d000-32b660d000 ---p d000 fd:00 127465
/lib64/libgcc_s-4.1.2-2Segmentation fault
python imported modules/functions
from threading import Thread
import fcntl
from os import O_APPEND, O_CREAT, O_EXCL, O_LARGEFILE, O_NDELAY, ...
from time import asctime, localtime, sleep
from os import open as oopen
from os import fdopen
import sys
is this a "python" bug ? or am i doing something wrong ... the real code
will be available to troubleshoot the problem on request
regards
>>> import sys
[issue8604] Alias for distutils.file_util.write_file in e.g. shutils
New submission from Olemis Lang : Often I have the contents to be written in a file at a given path that I know as well. I recently tried to find a function in stdlib to do that and to my surprise this is what I found : - Such function exists - It's `distutils.file_util.write_file` IMO the last place where people'd look for such a function is inside `distutils` package. Besides I reviewed modules listed under `File and directory access` category in `Library Reference` and found nothing even similar. The idea is to provide a a similar function in `shutils` module -- assignee: tarek components: Distutils messages: 104833 nosy: olemis, tarek priority: normal severity: normal status: open title: Alias for distutils.file_util.write_file in e.g. shutils type: feature request versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue8604> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5072] urllib.open sends full URL after GET command instead of local path
New submission from Olemis Lang :
Hello ...
The first thing I have to say is that I searched the open issues and I
found nothing similar to what I am going to report hereinafter. If this
ticket is duplicate , I apologize ...
Yesterday I was testing how to access the wiki pages in a
Trac [1]_ site and I realized that something wrong was happening
(a bug? ...)
Initially the behavior was as follows :
{{{
#!python
>>> u = urllib.urlopen('http://localhost:8000/trac-dev')
>>> u.read()
'Environment not found'
>>> u.close()
}}}
And tracd reported a line like this
{{{
127.0.0.1 - - [25/Jan/2009 17:32:08] "GET http://localhost:8000/trac-
dev HTTP/1.0" 404 -
}}}
Which means that a 'Not found' error code was sent back to urllib
client.
I tried to access the same page from my browser and tracd reported
{{{
127.0.0.1 - - [25/Jan/2009 18:05:44] "GET /trac-dev HTTP/1.0" 200 -
}}}
The problem is obvious ... urllib was sending the full URL after GET
and it should send only the string after the network location.
I applied the following patch to urllib (yours will be better, I am
sure about that ;)
{{{
#!diff
--- /usr/lib/python2.5/urllib.py2008-07-31 13:40:40.0
-0500
+++ /media/urllib_unix.py 2009-01-26 09:48:54.0 -0500
@@ -270,6 +270,7 @@
def open_http(self, url, data=None):
"""Use HTTP protocol."""
import httplib
+from urlparse import urlparse
user_passwd = None
proxy_passwd= None
if isinstance(url, str):
@@ -312,12 +313,17 @@
else:
auth = None
h = httplib.HTTP(host)
+target = ''.join(sep + part for sep, part in \
+zip(['', ';', '?', '#'], \
+urlparse(selector)[2:]) \
+if part)
+print target
if data is not None:
-h.putrequest('POST', selector)
+h.putrequest('POST', target)
h.putheader('Content-Type', 'application/x-www-form-
urlencoded')
h.putheader('Content-Length', '%d' % len(data))
else:
-h.putrequest('GET', selector)
+h.putrequest('GET', target)
if proxy_auth: h.putheader('Proxy-Authorization', 'Basic %s' %
proxy_auth)
if auth: h.putheader('Authorization', 'Basic %s' % auth)
if realhost: h.putheader('Host', realhost)
}}}
And everithing was «back» to normal ...
{{{
#!python
>>> u = urllib.urlopen('http://localhost:8000/trac-dev')
>>> u.read()
... # Lots of beautiful HTML code ;)
>>> u.close()
}}}
... tracd outputted ...
{{{
127.0.0.1 - - [25/Jan/2009 18:05:44] "GET /trac-dev HTTP/1.0" 200 -
}}}
The same picture is shown when using both Python 2.5.1 and 2.5.2 ...
I have not installed Python 2.6.x so I am not sure about whether this
issue has propagated onto newer versions of Python ... and I don't
know euther if this issue is also present in urllib2 or not ...
... so further research is needed, but IMO this is a serious bug :(
PD: If this is a bug ... how could it be hidden so far ? Is there any
test case written to assert this kind of things ? I checked out
`test.test_urllib` and `test.test_urllibnet` modules and I saw
nothing at all ...
.. [1] Trac
(http://trac.edgewall.org)
--
components: Library (Lib)
messages: 80586
nosy: olemis
severity: normal
status: open
title: urllib.open sends full URL after GET command instead of local path
type: behavior
versions: Python 2.5
___
Python tracker
<http://bugs.python.org/issue5072>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5072] urllib.open sends full URL after GET command instead of local path
Olemis Lang added the comment:
Ooops ... sorry, remove the print statement. The patch is as follows :
{{{
#!diff
--- /usr/lib/python2.5/urllib.py2008-07-31 13:40:40.0
-0500
+++ /media/urllib_unix.py 2009-01-26 09:48:54.0 -0500
@@ -270,6 +270,7 @@
def open_http(self, url, data=None):
"""Use HTTP protocol."""
import httplib
+from urlparse import urlparse
user_passwd = None
proxy_passwd= None
if isinstance(url, str):
@@ -312,12 +313,17 @@
else:
auth = None
h = httplib.HTTP(host)
+target = ''.join(sep + part for sep, part in \
+zip(['', ';', '?', '#'], \
+urlparse(selector)[2:]) \
+if part)
if data is not None:
-h.putrequest('POST', selector)
+h.putrequest('POST', target)
h.putheader('Content-Type', 'application/x-www-form-
urlencoded')
h.putheader('Content-Length', '%d' % len(data))
else:
-h.putrequest('GET', selector)
+h.putrequest('GET', target)
if proxy_auth: h.putheader('Proxy-Authorization', 'Basic %s' %
proxy_auth)
if auth: h.putheader('Authorization', 'Basic %s' % auth)
if realhost: h.putheader('Host', realhost)
}}}
I apologize once again ...
___
Python tracker
<http://bugs.python.org/issue5072>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5072] urllib.open sends full URL after GET command instead of local path
Olemis Lang added the comment:
Actually I am using a proxy hosted in some other machine (i.e. not my
PC ... sorry, I didnt mention :S ...) I «debugged» urllib and, when
branching at this point (see below ;) in URLopener.open_http :
{{{
#!python
# urllib,py
def open_http(self, url, data=None):
"""Use HTTP protocol."""
import httplib
user_passwd = None
proxy_passwd= None
if isinstance(url, str): # Branching here !!
host, selector = splithost(url)
if host:
user_passwd, host = splituser(host)
host = unquote(host)
realhost = host
else:
host, selector = url
}}}
url variable is bound to the following binary tuple
{{{
#!python
('172.18.2.7:3128', 'http://localhost:8000/trac-dev')
}}}
My IP is 172.18.2.99 ... so the `else` branch is the one being executed
If you need further details ... dont hesitate and ask anything you
want ;)
PD: What d'u mean when you said?
> Do you have an HTTP proxy? running at the *same* port? (!)
I dont understand this since *I already said* that *I accessed* my Trac
environment using my web browser (Opera 9.63, I dont know whether this
is relevant at all ... ), *I sent you* the lines outputted by tracd to
stdout (or stderr ... I am not very sure right now ... ;) and *I told
you* that, once I applied the path *I submitted*, everything was *back
to normal* ...
I dont understand how could all this be possible if I were running
tracd and an HTTP proxy in the *same* port, or even in case
`http_proxy` envvar be set to the hostname + port where my Trac
instance is listening for incoming connections ...
Anyway ... CMIIW ...
I also checked that immediately before executing the following
statements ...
{{{
#!python
# urllib,py
h = httplib.HTTP(host)
if data is not None:
h.putrequest('POST', selector)
h.putheader('Content-Type', 'application/x-www-form-
urlencoded')
h.putheader('Content-Length', '%d' % len(data))
else:
h.putrequest('GET', selector)
}}}
... `selector` is bound to 'http://localhost:8000/trac-dev' ... BTW the
`else` clause *is the one executed* in this case, and this is
consistent with tracd reports *I sent before* and is logical since
`data` arg *is missing* in the code snippet I sent before.
___
Python tracker
<http://bugs.python.org/issue5072>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5072] urllib.open sends full URL after GET command instead of local path
Olemis Lang added the comment: > Quoting Antoine Pitrou ... > I suppose 172.18.2.7:3128 is the address:port of the your proxy, right? Yes ... > In which case, urllib seems to do the right thing. When talking to an HTTP proxy, requests are of the form "GET http://site.com/path";, rather than "GET /path". It's up to the proxy to strip the host part of the URL when forwarding the request to the target server. This being said ... > (but I suppose tracd could also be more permissive and allow the "GET http://site.com/path"; variant. It seems Apache does) ... It works with Apache (I am talking about trac once again ...) therefore I will report this issue to Trac devs instead ... Thnx a lot ! Sorry if I caused you any trouble ... ___ Python tracker <http://bugs.python.org/issue5072> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17545] os.listdir and os.path.join inconsistent on empty path
New submission from Bernard Lang:
The empty path '' is considered as an acceptable path in os.path.join, and
works as a neutral prefix:
print os.path.join('','aaa') ===> aaa
which seems rather natural.
But it raises an exception when used as a parameter to os.listdir.
Logically, it should then list the current directory.
(the alternative would be to raise an exception when os.path.join gets an empty
argument).
The inconsistency became clear to me when I had to write the following function
:
def listdirs(path,flist): # Appends to "flist" all paths to files that
# start with "path". Argument "path" can be empty string ''.
if path=='' : localist=os.listdir('.')
else : localist=os.listdir(path)
for f in localist :
p=os.path.join(path,f)
flist.append(p)
if os.path.isdir(p) :
listdirs(p,flist)
return flist
The conditionnal is needed only to avoid the exception, while the code is
unique afterwards.
This is related to Issue818059, but I did not see how that issue was resolved.
Furthermore, the case of the empty path as argument to os.listdir should be
documented in http://docs.python.org/2/library/os.html
--
components: Library (Lib)
messages: 185207
nosy: babou
priority: normal
severity: normal
status: open
title: os.listdir and os.path.join inconsistent on empty path
type: enhancement
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue17545>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17545] os.listdir and os.path.join inconsistent on empty path
Bernard Lang added the comment:
Reply to R.David.Murray
> See also issue 6095.
You are right. I goofed, this is the issue I meant to point to.
> $ ls ''
> ls: cannot access : No such file or directory
> So, the behavior is consistent with the shell.
This is a fair remark.
But still, giving a meaning to something that has none in the shell would not
be an inconsistency either. There are lots of other differences in the Unix
shell design, and strings are often used as a syntactic device. You do not have
to quote file names or paths, unless they raise syntactic problems.
Now if you look at path manipulation commands in the shell, you have :
$ basename aaa
aaa
$ dirname aaa
.
This is a fair choice for the shell since an empty path would print as nothing.
Furthermore, string manipulation is not as convenient with the shell as it is
with Python. So the shell is altogether ignoring the empty path, and string
manipulations (possibly using the empty string) to build a path representation
are not part of the path system.
Python has already made a different choice.
In [4]: os.path.basename('aaa')
Out[4]: 'aaa'
In [5]: os.path.dirname('aaa')
Out[5]: ''
These are the two results of os.path.split('aaa'), which is somewhat the
inverse of os.path.join(...) which I initially considered.
So os.path.dirname in Python does return the empty string '' where the shell
dirname returns a dot. This could also be seen as an inconsistency between Unix
shell and Python.
However, the Unix shell is internally consistent, while taking into account its
own specific constraints.
It seems that it is more important for Python to similarly have its own
internal consistency, especially when considering that Python is already
departing from Unix shell in some minor ways, which are related to the internal
consistency issue that was raised.
--
___
Python tracker
<http://bugs.python.org/issue17545>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17545] os.listdir and os.path.join inconsistent on empty path
Bernard Lang added the comment: Thank you, David. BTW, I sent a message on april 20 to d...@python.org about a bug in the documentation regarding os.readlink(path) on page http://docs.python.org/2/library/os.html and proposing an alternative text. I got no reply. This was not long ago ... should I just wait ? Sorry for asking you ... I know no one else. Regards Bernard * R. David Murray , le 20-04-13, a écrit: > > Changes by R. David Murray : > > > -- > keywords: +easy > stage: -> needs patch > > ___ > Python tracker > <http://bugs.python.org/issue17545> > ___ -- SVP Ne plus m'écrire à bernard.l...@inria.fr mais à l'adresse ci-dessous Please No longer write to bernard.l...@inria.fr but to the address below bernard.l...@datcha.net ,_ /\o\o/gsm +33 6 6206 1693 http://www.datcha.net/ ^ tel +33 1 3056 1693 Je n'exprime que mon opinion - I express only my opinion CAGED BEHIND WINDOWS or FREE WITH LINUX -- ___ Python tracker <http://bugs.python.org/issue17545> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
