Ralf Schmitt added the comment:
I can easily reproduce it using python 2.5.
I'll test with trunk.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1725737>
_
_
Changes by Ralf Schmitt:
--
nosy: +schmir
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue21>
___
Python-bugs-list mailing list
Unsubs
Ralf Schmitt added the comment:
Ofcouse the problem was not logging, but I wanted to "replay" those
commands. This is where I got the error.
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Ralf Schmitt added the comment:
Well, I've been a victim of this one yesterday in a real world example.
I'm logging the repr of arguments to XMLRPC method calls and we happen
to use nested lists, which where deep enough to overflow that stack.
It's now 8 years later and I ca
Ralf Schmitt added the comment:
I'm attaching a patch, which makes mmap.mmap the mmap class itself and
also makes it subclassable. It also contains changes to the documentation.
This is against revision 60148 of trunk.
--
nosy: +schmir
Added file: http://bugs.python.org/fil
Ralf Schmitt added the comment:
Ok, I've upped the limit to some very high value and tried to provoke a
stack overflow.
eval("["*x+"]"*x) segfaults on my machine for x somewhere around 2
(linux, amd64). When setting MAXSTACK to 5000 eval("["*x+"]&
New submission from Ralf Schmitt:
The parser can handle nested structures only up to a certain limit.
The limit is currently reached around 33 deeply nested lists, which is a
bit too low.
This patch increases that limit by a factor of 10.
see http://bugs.python.org/issue21 for further
Changes by Ralf Schmitt:
--
versions: +Python 2.6
Added file: http://bugs.python.org/file9249/up-maxstack.txt
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Ralf Schmitt added the comment:
Many thanks for handling it immediately.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1087741>
_
___
Python-bugs-list
Ralf Schmitt added the comment:
one more. this program seems to leak memory:
x=1000
e="["*x+"]"*x
while 1:
try:
eval(e)
except MemoryError:
pass
__
Tracker <[EMAIL PROTECTED]>
<htt
Ralf Schmitt added the comment:
yes, here it is. I've added the tests to Lib/test/test_parser.
BTW, is it possible to trigger a segfault by constructing a parser.st
object and calling compile on it?
Added file: http://bugs.python.org/file9258/up-maxstack+test
Ralf Schmitt added the comment:
sorry, I somehow managed to introduce a segfault:
~/pydev/trunk/ cat t.py
[EMAIL PROTECTED] ok
from mmap import mmap
class anon_mmap(mmap):
def __new__(klass, *args, **kwargs):
res = mmap
Changes by Ralf Schmitt:
Added file: http://bugs.python.org/file9261/subclass_mmap_patch.txt
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1087741>
_
___
Ralf Schmitt added the comment:
./python Lib/test/test_mmap.py works with a debug build with this patch.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
New submission from Ralf Schmitt:
collect_children is only called in process_request, so at least the last
process forked is not collected. This could be handled by calling
collect_children every X seconds or by handling SIGCHLD.
--
messages: 61773
nosy: schmir
severity: normal
status
Ralf Schmitt added the comment:
Well, one child isn't the maximum. All children which do not finish
before the last client connects, will live on as zombies (and will be
collected when the next client connects). If that is acceptable, then
just close this report.
Using signals would be e
Ralf Schmitt added the comment:
this test program work with python 2.4 and 2.5:
import optparse
p1=optparse.OptionParser()
p2=optparse.OptionParser()
p1.remove_option('-h')
p2.remove_option('-h')
This issue should be closed.
Ralf Schmitt added the comment:
python trunk supports this. please close.
--
nosy: +schmir
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue870807>
__
Ralf Schmitt added the comment:
this is a duplicate of http://bugs.python.org/issue21.
Please close.
--
nosy: +schmir
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
New submission from Ralf Schmitt:
xmlrpclib uses datetime.strftime which cannot handle dates before 1900.
this patch adds a custom date formatting function, which does not have
this restriction. It also contains 2 additional unit tests, which both
fail with the unpatched version
Ralf Schmitt added the comment:
Well, all it basically does is changing calls to obj.strftime to a
custom string formatting function (where obj is a datetime.datetime,
datetime.date or datetime.time). These strftime calls are made during
object marshalling. So, all the objects to be marshalled
Ralf Schmitt added the comment:
when I set the the stack size to 128kb on a 64bit linux with ulimit -s
128, the tests still pass (default stack size is 8192 kb).
However the following fails at recursion level 180 with a segfault:
def f(count):
print count
f(count+1)
f(0)
If I set the
New submission from Ralf Schmitt:
mmap.flush returns the result of the call to FlushViewOfFile as an
integer, and does not check for errors. On unix it does check for
errors. The function should return None and raise an exception if an
error occurs...
This bug can lead to data loss...
Here&#
Ralf Schmitt added the comment:
The patch looks good, I've tested it on trunk and also release25-maint.
It applies with fuzz and one has to add a "from __future import
with_statement".
I think this should also be applied to release25-maint. IMHO, this is a
rather severe problem, a
Ralf Schmitt added the comment:
http://bugs.python.org/issue1777412 describes the cause of this issue
(i.e. strftime not being able to handle years before 1900).
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
New submission from Ralf Schmitt:
I think this should be disabled on 64 bit systems. It makes running
regrtest.py for me basically impossible.
Martin, I've put you on the nosy list, as you have committed this one in
revision 60793.
--
files: test_crasher_only_on_32bit.txt
mes
Changes by Ralf Schmitt:
--
components: +Tests
type: -> resource usage
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2137>
__
___
Python-bugs-li
Ralf Schmitt added the comment:
I didn't check the trunk version - I just assumed it would also be there.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2137>
__
_
Ralf Schmitt added the comment:
I've attached a new patch against current trunk, which now also contains
unit tests.
--
type: -> feature request
versions: -Python 2.5
Added file: http://bugs.python.org/file9491/siginterrupt+tests.txt
_
Ralf Schmitt added the comment:
Isn't this a candidate for backporting to 2.5?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2067>
__
___
Python-bugs-
Ralf Schmitt added the comment:
Attaching an updated version of the patch against trunk revision 61011.
Added file: http://bugs.python.org/file9520/xmlrpc_date_before_1900_r61011.txt
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Changes by Ralf Schmitt:
--
nosy: +schmir
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1633953>
_
___
Python-bugs-list mailing list
Unsubs
Ralf Schmitt added the comment:
python 2.6 has os.closerange. however it is currently not used in popen2.
--
nosy: +schmir
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Ralf Schmitt added the comment:
running setup.py sdist --prune results in:
making hard links in ex-0.0.0...
hard linking MANIFEST.in -> ex-0.0.0
hard linking setup.py -> ex-0.0.0
hard linking .hg/00changelog.i -> ex-0.0.0/.hg
hard linking .hg/dirstate -> ex-0.0.0/.hg
hard linking
Ralf Schmitt added the comment:
.hg, .git, are also candidates
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1725737>
_
___
Python-bugs-list mailing list
Ralf Schmitt added the comment:
.bzr, and _darcs (yes, underscore) also.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1725737>
_
___
Python-bugs-list
Ralf Schmitt added the comment:
updated version of diff, which also excludes .hg, .git, .bzr, and _darcs.
Added file: http://bugs.python.org/file9527/more-vcs-exclude.txt
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Ralf Schmitt added the comment:
also patch docs.
Added file: http://bugs.python.org/file9528/more-vcs-exclude+docs.txt
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Changes by Ralf Schmitt:
--
nosy: +georg.brandl
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1725737>
_
___
Python-bugs-list mailing list
Ralf Schmitt added the comment:
http://bugs.python.org/issue1095784 proposes to exclude:
.#* (CVS conflict files, but emacs sometimes also generates them)
*~ would also be a candidate
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Ralf Schmitt added the comment:
The original patch should by betelgeus should be applied to 2.5 branch.
Georg, this is complete from my point of view and could be applied.
Unless you want *~ and .#* to also be excluded?
--
versions: +Python 2.5, Python 2.6
Ralf Schmitt added the comment:
distutils.extension has:
if warnings is not None:
warnings.warn(msg)
else:
sys.stderr.write(msg + '\n')
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Ralf Schmitt added the comment:
_svn might also be a candidate. it is used on windows when
SVN_ASP_DOT_NET_HACK is set.
(see http://svn.collab.net/repos/svn/trunk/notes/asp-dot-net-hack.txt).
But, I don't care enough to provide a patch.
What do you thinkm about excluding *
Ralf Schmitt added the comment:
then close this one and also http://bugs.python.org/issue1095784
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1725737>
_
__
Ralf Schmitt added the comment:
related issue: http://bugs.python.org/issue1725737
--
nosy: +schmir
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Changes by Ralf Schmitt:
--
nosy: +schmir
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2240>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Ralf Schmitt:
--
nosy: +schmir
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1683>
__
___
Python-bugs-list mailing list
Unsubs
Ralf Schmitt added the comment:
I'd like to also see this in 2.6. Should I update the patch (if it
doesn't apply) and test? (I guess the signal module hasn't changed that
much).
__
Tracker <[EMAIL PROTECTED]>
<http://b
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
attached is a patch. I hope it is ok to change the semantics a bit.
They were very strange:
- on unix it raises an exception on errors. otherwise it always returns 0.
- on windows it returns non-zero on success, and returns zero on
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
Okay, the patch applies just fine (besides configure, which must be
regenerated). Running the tests however consumes 3 gb of memory.
The range functions must be changed to xrange on trunk. I've also
changed the docs a bit ("
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
versions: +Python 2.6
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2240>
__
___
Python-bugs
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
nosy: +schmir
type: -> resource usage
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1751245>
_
_
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
this works now:
$ ./configure --prefix ~/soft/ --exec-prefix ~/soft/deb3
...
~/release25-maint/ ~/soft/deb3/bin/python
[EMAIL PROTECTED] ok
Python 2.5.3a0 (release25-maint, Mar 14 2008, 18:19:57)
[GCC 4.2.3 (
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
nosy: +schmir
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue998998>
___
Python-bugs
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
maybe running ldconfig, or changing /etc/ld.so.conf would have helped.
I'd say close this bug report.
--
nosy: +schmir
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
nosy: +schmir
versions: +Python 2.5
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1474680>
_
_
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
nosy: +schmir
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1509798>
_
___
Python-bugs
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
type: -> compile error
versions: +Python 2.5
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
nosy: +schmir
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1653457>
_
___
Python-bugs
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
nosy: +schmir
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1737127>
_
___
Python-bugs
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
This should be closed:
from http://python.org/download/releases/2.4.5/:
"Since the release candidate, we received various reports that the this
release may fail to build on current operating systems, in particular on
OS X. We h
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
nosy: +schmir
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1773632>
_
___
Python-bugs
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
nosy: +schmir
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1745722>
_
___
Python-bugs
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
ctrl-c should now work with python 2.5.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1737127>
_
_
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
nosy: +schmir
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1702551>
_
___
Python-bugs
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
nosy: +schmir
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1540386>
_
___
Python-bugs
New submission from Ralf Schmitt <[EMAIL PROTECTED]>:
The following short program raises an exception:
import UserList
class C:
pass
print isinstance(C, UserList.UserList)
-
exception:
Traceback (most recent call last):
File "t.py", line 6, in
pr
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
I used svn revision 61433.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2319>
__
___
Python-bugs
New submission from Ralf Schmitt <[EMAIL PROTECTED]>:
os.strerror is missing on my 64 bit linux.
HAVE_STRERROR is not defined in pyconfig.h.
This has been broken in r61483.
--
messages: 63908
nosy: brett.cannon, schmir
severity: normal
status: open
title: os.strerror m
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
I can confirm this issue. 2 tests fail without this patch. please apply.
here are the failing tests:
==
FAIL: test_args_string (test.test_subprocess.ProcessTe
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
my manpage (debian testing) states:
POSIX.1-2001 permits strerror() to set errno if the call encounters an
error, but does not specify what value should be returned as the func‐
tion result in the event of an error. On some s
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
this issue is about the threaded one.
I think it should be rejected. It does not work:
~/ python2.5 xmlrpclib_multicall.py [EMAIL PROTECTED]
failed 1
Traceback (most recent call last):
File "xmlrpclib_m
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
The current behaviour (without your patch) seems ok to me. I just wanted
to point out that the patch in its current form could break on some
platforms.
__
Tracker <[EMAIL PROTECTED]>
<http://
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
I once even had the need for a PYTHON24PATH or PYTHON25PATH.
(And I think this would be the right approach, i.e. even using the minor
version number).
However, now I am a happy user of virtualenv, and I do not even have to
set PYTH
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
c modules cannot be used when the minor version number changes. If I
remember correctly c modules where the problem for me, when I ran python
2.4 and 2.5 in parallel.
__
Tracker <[EMAIL PROTECTE
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
I personally have no need for it (not even for non-automatic boxcarring).
Note that you would also have to write documentation.
--
type: -> feature request
versions: +Python 2.6 -P
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
nosy: +schmir
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2477>
__
___
Python-bugs-list mailing
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
nosy: +schmir
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2480>
__
___
Python-bugs-list mailing
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
nosy: +schmir
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1714>
__
___
Python-bugs-list mailing
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
The current buildbot has errors similar to this one (I assume):
Exception happened during processing of request from ('127.0.0.1', 53126)
Traceback (most recent call last):
File "/Users/ralf/trunk/Lib/SocketSer
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
I just double checked with the following program:
#! /usr/bin/env python
import os
import fcntl
import socket
def isnonblocking(fd):
return bool(fcntl.fcntl(fd, fcntl.F_GETFL, 0) & os.O_NONBLOCK)
def main():
s=soc
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
now that I see that the buildbot was running on ppc *Debian* I'm not
quite sure if we're talking about the same issue.
__
Tracker <[EMAIL PROTECTED]>
<http://
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
No, please do not disable them. I'm not quite sure what to do, but
apparently these sockets returned from accept should be turned into
blocking sockets.
I just do not know, where this should happen. I think that this could
even be
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
With the following diff, test_xmlrpc.py passes without problems.
Like I said, someone else should decide where to turn on blocking mode.
I now think that it should be in the socket.accept (i.e. in the C code)
at least for unix platforms.
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
it should be no problem to add this to the bzr repository. this is where
it belongs.
--
nosy: +schmir
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
this works with python 2.6.
for python 2.5.1 I get the following gdb backtrace:
(gdb) bt
#0 0x2b0d95118e2d in cursor_iternext (self=0x2b0d93bae870)
at /root/src/Python-2.5.1/Modules/_sqlite/cursor.c:854
#1 0x2b0d93dd1
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
Of course the signal handler may raise an exception, so my last argument
isn't that good.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
the same is true for me.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2510>
__
___
Python-bugs
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
I think this should be fixed somewhere in the c code. people calling
sock.recv which a large recv size will also trigger this error.
this fix is wrong. the fixed code reads one byte at a time.
see:
http://mail.python.org/pipermail/pyth
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
Well, I think the right thing to do is limit the maximal size to be read
inside the c function (just to make it impossible to pass around large
values). This is basically the same fix just at another place in the code.
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
that is it seems wrong that it uses 1 byte when a size is given, and
recv_size when size is not given.
By the way I think if you ask for 4096 bytes and the buffering is set to
2048 bytes it should still try to read the full 4096 byte
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
nosy: +schmir
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2632>
__
___
Python-bugs-list mailing
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
One more time: the change is wrong. It should try to recv the maximum
not the minimum of size, buffer_size. If you using a buffering of 16
bytes it will otherwise call recv 256 times when you want to read 1024
bytes. this is wrong.
H
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
versions: +Python 2.6
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2632>
__
___
Python-bugs
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
akuchling, I added you to the nosy list. hope that's ok.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
nosy: +akuchling
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2632>
__
___
Python-bugs
Changes by Ralf Schmitt <[EMAIL PROTECTED]>:
--
nosy: +schmir
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2601>
__
___
Python-bugs-list mailing
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
ahh. yes, same issue. should have taken a look at the bugtracker before,
would have saved me some time...
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
This patch handles the case where the caller has specified the size
argument. When size is unspecified, it should be handled as if size was
infinite. By the formula from your patch, this should be
recv_size = min(self.max_readsize, ma
Ralf Schmitt <[EMAIL PROTECTED]> added the comment:
quoting http://bugs.python.org/issue1389051: "Applied to 2.6 trunk in
rev. 61008 and to 2.5-maint in rev. 61009."
I don't know about py3k...
--
versions: +Python 2.6
__
Trac
101 - 200 of 292 matches
Mail list logo
