Nadeem Vawda added the comment:
Here's an implementation of read1() that satisfies that condition, along with
some relevant unit tests.
--
keywords: +patch
Added file: http://bugs.python.org/file21531/gzipfile_read1.diff
___
Python tracker
Nadeem Vawda added the comment:
> Something looks fishy: what happens if size is -1 and EOFError is not raised?
You're right - I missed that possibility. In that case, extrasize and offset get
updated incorrectly, which will break subsequent calls to seek() and tell().
However, it se
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue11795>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
> As a reference, I think you are refering to #5863 and #10791. Pretty fine
> job, I must say.
Thank you :)
> Nadeem, what do you think?. Is xz in your list?.
Yes, it's the next substantial thing I was planning on working on. I don't have
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue5996>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
I've looked at the code for Python 3, and there isn't anything there that
prevents this from happening there, either. So the fix should be applied
to 3.2 and 3.3 as well.
An alternative approach would be to limit the size of the cache, so that
the call
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue11277>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
Patch for 3.3 and 3.2
--
keywords: +patch
Added file: http://bugs.python.org/file21584/filecmp-lru-cache-3.3.diff
___
Python tracker
<http://bugs.python.org/issue11
Nadeem Vawda added the comment:
Patch for 2.7.
--
Added file: http://bugs.python.org/file21585/filecmp-lru-cache-2.7.diff
___
Python tracker
<http://bugs.python.org/issue11
Changes by Nadeem Vawda :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue11802>
___
___
Python-bugs-list mailing list
Un
Nadeem Vawda added the comment:
Oops, there was a typo in the 2.7 patch ("import _thread" instead of
"import thread"). Corrected patch attached.
--
Added file: http://bugs.python.org/file21586/filecmp-lru-cache-2.7.diff
___
P
Nadeem Vawda added the comment:
Because the lru_cache decorator doesn't provide any way to invalidate
stale cache entries.
Perhaps I should factor out the duplicated code into a separate class
that can then also be exposed to users of the stdlib. But that would only
apply to 3.3, so the u
Nadeem Vawda added the comment:
> I question whether this should be backported. Please discuss with the RM.
Will do. Are you referring specifically to 2.7, or to 3.1 and 3.2 as well?
--
___
Python tracker
<http://bugs.python.org/issu
Nadeem Vawda added the comment:
Georg? Benjamin? Do you think this fix should be backported?
--
nosy: +benjamin.peterson, georg.brandl
___
Python tracker
<http://bugs.python.org/issue11
Nadeem Vawda added the comment:
> By the way, at this point I think we could simply skip the test on BSDs
> and OS X. The tested functionality is cross-platform, so testing under
> a limited set of systems should be ok.
Another solution would be to rewrite the test to not use mmap
Nadeem Vawda added the comment:
> I think there's basically noone and nothing (even among the buildbots)
> that runs bigmem tests on a regular basis, so I'd much rather keep the
> mmap() solution, even if that means it must be skipped on OS X.
Fair enough.
(As an aside, if
New submission from Nadeem Vawda :
Could you provide more details on the problem? What version of Python did
you encounter this error under? A short code fragment that triggers the
error would also be useful.
(I get no errors executing "sys.stdin.flush()" on 2.6.6 or 3.3)
-
Nadeem Vawda added the comment:
> So i finally did some tests using Nadeem's code snippet
> from msg133677. The largest top(1) i ever got was
>30477 python3 2.7 00:09.77 101877912M+ 240K
> but the system is unusable then.
The code I posted was
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue11877>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue11918>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
Changeset a0681e7a6ded fixes this bug for 2.7 - too-large buffers cause
an OverflowError during argument parsing, so there is no possibility of
truncation happening.
--
status: open -> closed
___
Python tracker
&l
Nadeem Vawda added the comment:
haypo> Can we just remove the test?
I think so. The test was originally intended to catch the case where crc32() or
adler32() would get a buffer of >=4GB, and then silently truncate the size and
produce an incorrect result (issue10276). However, 2.7&
Nadeem Vawda added the comment:
test_move_dir_caseinsensitive is failing on some of the XP buildbots:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4514
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/2696
http://www.python.org/dev/buildbot/all
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12021>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
Thanks for the tests; I'll review and commit them tomorrow morning.
> Even if that means that there is no test which checksums an
> entire superlarge mmap() region.
Bear in mind that the test is only to be removed from 2.7; it will still
be prese
Nadeem Vawda added the comment:
sdaoden> @Nadeem: note that the committed versions of the tests would not
sdaoden> show up the Mac OS X mmap() bug AFAIK, because there is an
sdaoden> intermediate .close() of the file to be mmapped.
Thanks for catching that. Should be fixed now.
hay
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12041>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12046>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
Thanks for the bug report. It seems that the code needs fixing. I'll look
into it this weekend.
--
assignee: -> nadeem.vawda
nosy: +nadeem.vawda
stage: -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12053>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12060>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12062>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
The code has been fixed. Once again, thanks for the bug report.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nadeem Vawda added the comment:
Fixed in 3.1, 3.2 and 3.3.
2.7 no longer has this problem -- the fix for issue8651 ensures that the
functions cannot receive inputs large enough to be problematic (since we
don't define PY_SSIZE_T_CLEAN).
--
resolution: -> fixed
stage: nee
Nadeem Vawda added the comment:
Also failing to compile on OS X:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.x/builds/1385/steps/test/logs/stdio
The problem seems to be that is not being included on these
non-Linux systems. Looking at Modules/socketmodule.h reveals
Nadeem Vawda added the comment:
The OpenIndiana bots are now green, but the BSD and OS X bots are still
failing. It seems that on those systems, depends on
and maybe some other headers, so the current configure
script detects it as "present but not usable".
I'm current
Nadeem Vawda added the comment:
OK. I'll try to put together something cleaner just for 3.3, then.
--
assignee: -> nadeem.vawda
stage: patch review -> needs patch
versions: -Python 2.7, Python 3.1, Python 3.2
___
Python tra
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12081>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
OK, that's great. It'll be another couple of hours before I can do
anything from the FreeBSD side; I'm still waiting for the ISO to finish
downloading :/
--
___
Python tracker
<http://bugs.pytho
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12084>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
All the buildbots are back to normal. It looks like FreeBSD was having
the same problem as OS X.
--
___
Python tracker
<http://bugs.python.org/issue1746
Nadeem Vawda added the comment:
Also, if I'm reading the documentation correctly, there isn't any
support for incremental in-memory coding, so it wouldn't be possible
to implement classes analogous to BZ2Compressor/BZ2Decompressor.
--
assignee:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue7443>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12107>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12124>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
The behaviour of int() can be made consistent with the syntax for Python
integer literals by specifying a base of 0:
>>> int("0050", 0)
Traceback (most recent call last):
File "", line 1, in
ValueError: invalid
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12131>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Nadeem Vawda :
test_packaging fails when regrtest is run with the -j option (run multiple
tests concurrently).
$ ./python -Wd -E -bb -j0 -v test_packaging
[snip]
==
ERROR: test_build_ext
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12133>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12141>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Nadeem Vawda :
When running "make test" on Python3, test_socket reports a number of
ResourceWarnings due to unclosed sockets. Attached is a patch that changes the
relevant tests so that they close all the created sockets.
test_multiprocessing and test_xml
Nadeem Vawda added the comment:
Attached is a patch that fixes the warnings in test_xmlrpc, along with some
other file- and socket-related warnings in test_normalization, test_timeout and
test_tk that only show up when regrtest is run with -uall.
The warning in test_timeout could be fixed
Changes by Nadeem Vawda :
--
nosy: +nvawda
___
Python tracker
<http://bugs.python.org/issue1508475>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
test_cgi causes a strange filehandle leak that only causes a warning when
regrtest terminates, and for some reason doesn't show up if you run just
test_cgi by itself. I've attached a patch that closes the filehandle.
--
nosy: +lukasz.langa
Changes by Nadeem Vawda :
--
nosy: +nvawda
___
Python tracker
<http://bugs.python.org/issue5863>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
The fix for test_normalization was committed as r87441. As for test_cgi, I
still seem to get the leak (also on Linux; Ubuntu 10.10 64-bit). I'll poke
around with it some more tomorrow.
In addition to the ResourceWarnings, some of tests have been ra
Nadeem Vawda added the comment:
r87710 introduces a ResourceWarning in test_threading. Fix attached.
--
___
Python tracker
<http://bugs.python.org/issue10
Changes by Nadeem Vawda :
Added file: http://bugs.python.org/file20255/test_threading.diff
___
Python tracker
<http://bugs.python.org/issue10512>
___
___
Python-bug
Nadeem Vawda added the comment:
r87710 introduces an AttributeError in test_thread's TestForkInThread test
case. If os.fork() is called from a thread created by the _thread module,
threading._after_fork() will get a _DummyThread (with no _block attribute) as
the current thread.
Nadeem Vawda added the comment:
According to POSIX [1], if a multi-threaded program calls fork(), the child
process may only use async-signal-safe system calls between fork() and exec*().
readdir() is not required to be async-safe [2], so reading /proc/self/fds in
the child process is
Nadeem Vawda added the comment:
r87736 introduces another DeprecationError; this time in test_time (line 150;
s/assertEquals/assertEqual/).
--
___
Python tracker
<http://bugs.python.org/issue10
Nadeem Vawda added the comment:
Fix attached for test_imaplib. Most of the warnings were simply due to
reap_server() not closing the server object correctly. The remaining warning
was due a genuine leak in imaplib.IMAP4.__init__() - if an exception is raised
after the connection is opened
Nadeem Vawda added the comment:
Awesome. That just leaves test_urllibnet, test_urllib2net, and test_cgi. I'm
hoping to post patches for the first two tomorrow.
About test_cgi, I've fiddled around with it a bit more. The leak manifests
itself with any set of tests including te
Nadeem Vawda added the comment:
Have you tried my patch (resourcewarning-fixes-3.diff)? It fixes the warning
for me without breaking anything.
I was just worried that the warning was something triggered by my specific
system configuration when you said that you couldn't reproduce it.
Changes by Nadeem Vawda :
--
nosy: +nvawda
___
Python tracker
<http://bugs.python.org/issue4681>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
Looking at the warnings from test_urllib2net, it seems that they all originate
in the FTP tests:
* OtherNetworkTests.test_ftp()
* TimeoutTest.test_ftp_basic()
* TimeoutTest.test_ftp_default_timeout()
Most of these leaks seem to stem from the fact that
Nadeem Vawda added the comment:
Sorry, scratch that - I misunderstood the semantics of SocketIO.close(). I
hadn't realized that the underlying socket is supposed to stay open until it
itself is also explicitly closed (as well as all SocketIO objects referring to
it).
I've been a
Nadeem Vawda added the comment:
Good idea; they look like more work to fix than the warnings so far. Aside from
those two, it looks like test_cgi is all that's left. Just to clarify, did you
manage to reproduce the test_cgi warning?
--
___
P
Nadeem Vawda added the comment:
I have been unable to reproduce this on either 3.2rc1 or 2.6. I used a Zip
archive containing a single file with the data b"a\n" (CRC 0xDDEAA107).
--
nosy: +nvawda
___
Python tracker
<http://bu
Nadeem Vawda added the comment:
I have been working on a patch for this issue. I've implemented everything
except for readline(), readlines() and the iterator protocol.
In the existing implementation, the reading methods seem to interact weirdly -
iternext() uses a readahead buffer,
Nadeem Vawda added the comment:
Here is a patch that rewrites BZ2File to implement the requested feature, and
adds some tests using BytesIO objects.
Some notes:
* iteration and the read*() method now use the same buffering machinery, so
they can be mixed freely. The test for issue8397 has
Nadeem Vawda added the comment:
Yes, see bz2module-v1.diff.
--
___
Python tracker
<http://bugs.python.org/issue5863>
___
___
Python-bugs-list mailing list
Unsub
Nadeem Vawda added the comment:
> BTW,what is the best way to check for case insensitive file-system?
> The test here merely checks if sys.platform returns mac, darwin or win32.
I would suggest not checking at all. If the system is case-sensitive, the test
will pass, so it doesn't
Nadeem Vawda added the comment:
> Interesting! If you are motivated, a further approach would be to expose
> the compressor and decompressor objects from the C extension, and write
> the file object in Python (as in Lib/gzip.py).
I had initially considered doing something that, but
Nadeem Vawda added the comment:
* I had initially considered doing something *like* that
--
___
Python tracker
<http://bugs.python.org/issue5863>
___
___
Pytho
Nadeem Vawda added the comment:
Here is a quick-and-dirty reimplementation of BZ2File in Python, on top of the
existing C implementation of BZ2Compressor and BZ2Decompressor.
There are a couple of issues with this code that need to be fixed:
* BZ2Decompressor doesn't signal when it re
Changes by Nadeem Vawda :
--
nosy: +nvawda
___
Python tracker
<http://bugs.python.org/issue11018>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
>> * The read*() methods are implemented very inefficiently. Since they
>> have to deal with the bytes objects returned by
>> BZ2Decompressor.decompress(), a large read results in lots of
>> allocations that weren't necessary in
Nadeem Vawda added the comment:
Here is an update patch, which corrects a typo in the previous patch, and adds
a test to test_zlib.
The test uses a memory-mapped sparse file, so it gets skipped on systems
without mmap. The alternative would be to allocate a 4+GB buffer of ordinary
memory
Changes by Nadeem Vawda :
--
nosy: +nvawda
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nvawda
___
Python tracker
<http://bugs.python.org/issue11051>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
OK, I've rewritten the whole bz2 module (patch attached), and I think it is now
ready for review. The BZ2File implementation is a cleaned-up version of the one
from my previous patch, with some further additions. I've factored out the
common
Nadeem Vawda added the comment:
Looks good to me. My earlier patch was more defensive because I wasn't sure
whether any of the other tests might be using cgi.log(), but it seems that this
isn't the case.
--
___
Python trac
Nadeem Vawda added the comment:
No objections here. The other remaining leaks that I am aware of are covered by
issue10883.
--
___
Python tracker
<http://bugs.python.org/issue10
Nadeem Vawda added the comment:
Here's an update to the documentation for the bz2 module.
--
Added file: http://bugs.python.org/file20692/bz2-doc.diff
___
Python tracker
<http://bugs.python.org/i
Nadeem Vawda added the comment:
Here's a revised version of bz2-v3.diff, with docstrings that are more
consistent with the updated documentation.
--
___
Python tracker
<http://bugs.python.org/i
Nadeem Vawda added the comment:
Weird, the patch didn't upload...
--
Added file: http://bugs.python.org/file20721/bz2-v3b.diff
___
Python tracker
<http://bugs.python.org/i
Changes by Nadeem Vawda :
--
nosy: +nvawda
___
Python tracker
<http://bugs.python.org/issue8651>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nvawda
___
Python tracker
<http://bugs.python.org/issue8650>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
Thanks for pointing that out; I've uploaded a second patch that changes
async_chat.__init__() to use 'sock' instead of 'conn'.
This change shouldn't affect anything either, since the argument is
simply passed to asyncore.dispatcher
Nadeem Vawda added the comment:
For 3.x, I think that ignoring non-string names is a reasonable fix. The docs
for io.FileIO specify that its name attribute can be either a path or an integer
file descriptor, and changing this doesn't seem to serve any purpose.
As for the case of 2.7&#x
Nadeem Vawda added the comment:
Attached is a fix for 3.x.
--
keywords: +patch
Added file: http://bugs.python.org/file24258/gzip-fdopen.diff
___
Python tracker
<http://bugs.python.org/issue13
Nadeem Vawda added the comment:
As Georg suggested, it would be better to use dummy_threading.RLock,
rather than providing our own implementation.
The test in the patch fails when I try to run it on a no-thread build.
support.import_fresh_module seems to treat the absence of the threading
Nadeem Vawda added the comment:
Fix committed. For the test, it turns out we can get the desired behavior
by telling import_fresh_module to block the threading module directly,
instead of blocking _thread.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status
Nadeem Vawda added the comment:
> As far as fixing this for 2.7 goes, i don't like the _sound_ of it
> because it is gross... But i'm actually okay with having special case
> code in the gzip module that rejects '' as an actual filename
> and uses ''
Nadeem Vawda added the comment:
Done.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12500>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nadeem Vawda added the comment:
Do you have a self-compiled version of zlib (1.2.5) installed on this
system? It looks like this is due to a (benign) version mismatch between
zlib.h and the actual shared lib.
--
___
Python tracker
<h
Nadeem Vawda added the comment:
Either way, the failure should be fixed now.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> pending
___
Python tracker
<http://bugs.python.or
201 - 300 of 535 matches
Mail list logo
