Lukas Lueg added the comment:
I very strongly doubt that it actually crashes your kernel - it basically
can't. Your desktop becomes unresponsive for up to several minutes as the
kernel has paged out about every single bit of memory to disk, raising access
times by several orders of magnitude
Lukas Lueg added the comment:
The behavior is triggered in Modules/_json.c:encoder_listencode_obj(). It
actually has nothing to do with the TypeError itself, any object that produces
a new string representation of itself will do.
The function encoder_listencode_obj() calls the user-supplied
Lukas Lueg added the comment:
It's perfectly fine for the function to return an object that can't be put
directly into a json string. The function may not convert the object directly
but in multiple steps; the encoder will call the function again with the new
object until everything boils
New submission from Lukas Lueg:
If the SSL-port is unavailable due to firewall settings (or the host simply
being down), the SSL-tests in test_smtpnet.py fail instead of being skipped.
The tests should be skipped if the smtp.google.com can't be reached and fail
only in case of unexpected
Lukas Lueg added the comment:
Diff the make test_smtpnet pass if the network-resource is available but
smtp.google.com's ssl-port can't be reached. Most probably there is a better
way to do this.
--
keywords: +patch
Added file: http://bugs.python.org/file34462
Changes by Lukas Lueg lukas.l...@gmail.com:
Added file: http://bugs.python.org/file30475/cityhash_fasthast3.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16427
Lukas Lueg added the comment:
Here are more benchmarks of vanilla 3.4 vs. cityhash vs. fast_hash_3 on both
arm7l and x86-64. The patch was applied varbatim, only caching disabled. On
arm7l, the cpu was fixed to maximum freq (it seems to take ages to switch
frequencies, at least there is a lot
Lukas Lueg added the comment:
I was investigating a callgrind dump of my code, showing how badly
unicode_hash() was affecting my performance. Using google's cityhash instead
of the builtin algorithm to hash unicode objects improves overall performance
by about 15 to 20 percent for my case
Lukas Lueg added the comment:
It's a cache sitting between an informix db and and an internal web service.
Stuff comes out of db, processed, json'ifed, cached and put on the wire. 10**6s
of strings pass this process per request if uncached...
I use CityHash64WithSeed, the seed being cpython's
Lukas Lueg added the comment:
Here are some benchmarks for a arm7l on a rk30-board. CityHash was compiled
with -mcpu=native -O3.
CityHash is around half as fast as the native algorithm for small strings and
way, way slower on larger ones. My guess would be that the complex arithmetic
Lukas Lueg added the comment:
The 10**4-case is an error (see insane %), I've never been able to reproduce.
Having done more tests with fixed cpu frequency and other daemons' process
priority reduced, cityhash always comes out much slower on arm7l
Lukas Lueg added the comment:
Another proposal: Add a new BaseClass that, if inherited from, causes an
exception to be uncatchable (e.g. class HardMemoryError(MemoryError,
UncatchableException)).
--
___
Python tracker rep...@bugs.python.org
http
Changes by Lukas Lueg lukas.l...@gmail.com:
--
nosy: -ebfe
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16632
___
___
Python-bugs-list mailing
Changes by Lukas Lueg lukas.l...@gmail.com:
--
nosy: -ebfe
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9285
___
___
Python-bugs-list mailing
New submission from Lukas Lueg:
The patch zlib_keywords.patch makes zlib's classes and functions accept
keyword arguments as documented. It also fixes two cases in which the docstring
differ from the documentation (decompress(data) vs. decompress(string) and
compressobj(memlevel) vs
Lukas Lueg added the comment:
Attaching a patch to fix all pep8/pyflakes warnings and errors in test_zlib.py
--
Added file: http://bugs.python.org/file28419/zlib_tests_pep8.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Lukas Lueg added the comment:
Nothing of what you mention is a problem of this patch.
The memLevel-keyword was not supported as of now, only the docstring
(memLevel) and the documentation (memlevel) mentioned it. There is no
third-party code that could have used it.
The current docstring
Lukas Lueg added the comment:
Only way to be sure: Enable announce for 3.5 and wait for bug reports
--
nosy: +ebfe
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16632
Lukas Lueg added the comment:
Thorsten, the problem is that you are using line-based syntax. The code 'for
buffer in f:' will read one line per iteration and put it to 'buffer'; for a
file opened in binary mode, the iterator will always seek to the next b'\n'.
Depending on the content
Lukas Lueg added the comment:
@Roger: Triggering the segfault on MacOS 10.6 requires some interaction with
the text-window while the text is being rendered. This includes moving the
window or just clicking into it's canvas. Carefully leaving the window alone
while colorization is going
Lukas Lueg added the comment:
Switching to ActiveState's TCL fixes the problem on MacOS 10.6
I won't be able to produce a trace for a debug-build on Windows; attaching a
semi-useless trace anyway.
--
Added file: http://bugs.python.org/file28135/backtrace_windows.txt
Lukas Lueg added the comment:
On windows, IDLE only crashes if executed via pythonw.exe; if executed under
python.exe, the attached traceback is dumped to stderr
--
Added file: http://bugs.python.org/file28136/excp_traceback.txt
___
Python tracker
Lukas Lueg added the comment:
self.io is set to null before the colorization is finished. When IDLE's
text-window is closed, the AttributeErrors printed to stderr cause IDLE to
crash due to #13582.
One can also trigger the exceptions on any other OS as described in OP. While
#13582
New submission from Lukas Lueg:
IDLE crashes due to what seems to be a use-after-free bug. Opening a file from
the 'Open...'-menu leads to a segfault after the text has been rendered. It
seems this can be reproduced 100% of the time if the file is big (e.g. 150kb)
and the window receives
Lukas Lueg added the comment:
using NSZombieEnabled and MallocStackLoggingNoCompact we can see the
use-after-free behaviour
--
Added file: http://bugs.python.org/file28099/malloc_history.txt
___
Python tracker rep...@bugs.python.org
http
Lukas Lueg added the comment:
PyLint or PyChecker can only do this if the keys are all simple objects like
ints or strings. Consider a class with a custom __hash__
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16385
Lukas Lueg added the comment:
I have to say this feels like spooky action at a distance.
Wouldnt it be less intrusive - while achieving the same result - to make
MemoryError uncatchable if the flag is set?
--
nosy: +ebfe
___
Python tracker rep
Lukas Lueg added the comment:
In any strategy only a heuristic could be used in order to decide wether or not
it's safe to raise MemoryError. How exactly is memory pressure expected for
x=[2]*200 but not for x=2*200 ?
I don't think a new function could ultimatly achieve it's goal
Lukas Lueg added the comment:
The heuristic basically has to decide if memory pressure is so high that it's
not save to return to the interpreter. Even if there is a chosen value (e.g.
failed allocation attempts below 1mb are considered fatal), there can always be
another OS-thread
Lukas Lueg added the comment:
This could be avoided by
lives_in_init = (('lion': ['Africa', 'America']), ('lion': ['Europe']))
lives_in = {}
for k, v in lives_in_init:
assert k not in lives_in
lives_in[k] = v
del lives_in_init
Which is fast enough if executed only during module
New submission from Lukas Lueg lukas.l...@gmail.com:
The built-in function map() currently swallows any exception that might have
occured while trying to get an iterator from any parameter. This produces
unexpected behaviour for applications that require a certain type of exception
Lukas Lueg lukas.l...@gmail.com added the comment:
Collection may re-occur at any time, there is no promise to the callback code.
However, the callback can disable the gc, preventing further collection.
I don't think we need the other callbacks to be informed. As the callbacks are
worked down
Lukas Lueg lukas.l...@gmail.com added the comment:
Agreed, let's have the simple callback first.
To solve 2) later on, we could have the callback proposed here be the
'execution'-callback. It neither has nor will have the capability to prevent
garbage-collection.
We can introduce another
Lukas Lueg lukas.l...@gmail.com added the comment:
Why not make the start-callback be able to return a boolean value to the
gcmodule that indicates if garbage collection should take place or not.
For example, any value returned from the callback that evaluates to False (like
null) will cause
Lukas Lueg lukas.l...@gmail.com added the comment:
+1
--
nosy: +ebfe
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9285
___
___
Python-bugs-list
Lukas Lueg lukas.l...@gmail.com added the comment:
Thanks for your comment; it is a very valid point to consider. However, as a
vector-based implementation is roughly three to four times faster than what
the current API can provide by design (reduced overhead and GIL-relaxation not
included
New submission from Lukas Lueg lukas.l...@gmail.com:
The objects provided by hashlib mainly serve the purpose of computing hashes
over strings of arbitrary size. The user gets a new object (e.g.
hashlib.sha1()), calls .update() with chunks of data and then finally uses
.digest() or .hexdigest
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
agreed
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1501108
___
___
Python-bugs-list
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
Thanks for your efforts. I don't think you are stepping on anyone's toes
when picking up an issue that was unsolved for almost 5 years :-)
Please post patches to this bug for review/comments/help/whatever
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
bump
hashlibopenssl_gil_py27.diff has not yet been applied to py27 and does
not apply cleanly any more. Here is an updated version.
--
status: pending - open
Added file: http://bugs.python.org/file13646/hashlibopenssl_gil_py27_2
Changes by Lukas Lueg knabberknusperh...@yahoo.de:
Removed file: http://bugs.python.org/file13057/hashlibopenssl_gil_py27.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4751
New submission from Lukas Lueg knabberknusperh...@yahoo.de:
The file pointer's behaviour after opening a file in 'a+b' mode is not
consistent among platforms: The pointer is set to the beginning of the
file on Linux and to the end of the file on MacOS. You have to call
.seek(0) before calling
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
I'm not sure if such a API is feasible. The very nature of Python makes
it impossible to tell in advance what the interpreter will do when
getting called. This is even true for simple functions - think of your
function getting decorated
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
This is true for all objects whose input could be concatenated.
For example with hashlib:
data = ['foobar']*10
mdX = hashlib.sha1()
for d in data:
mdX.update(d)
mdY = hashlib.sha1()
mdY.update(.join(data))
mdX.digest
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
Count me in
--
nosy: +ebfe
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1054967
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
passing optimize=1 does not help when there is a script
(...scripts=['bla.py']...) in the given distribution. The error will be
thrown for bla.pyo and bla.pyc
--
nosy: +ebfe
___
Python tracker
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
test_case_md5_0 (__main__.HashLibTestCase) ... ok
test_case_md5_1 (__main__.HashLibTestCase) ... ok
test_case_md5_2 (__main__.HashLibTestCase) ... ok
test_case_md5_huge (__main__.HashLibTestCase) ... ok
test_case_md5_uintmax (__main__
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
yes, I got lost on that one. I'll create a patch for 2.7 tonight.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4751
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
Patch for 2.7
Added file: http://bugs.python.org/file13057/hashlibopenssl_gil_py27.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4751
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
The default encoding is UTF8. Even without that there should be no
problems while staying in the same environment as the
character-translation is the same.
However it violates the rule of least surprise to see zipfile throwing
CRC errors
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
I'll do a patch for 2.7
--
versions: +Python 2.7 -Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4751
Changes by Lukas Lueg knabberknusperh...@yahoo.de:
Removed file: http://bugs.python.org/file12587/hashlibopenssl_small_lock-4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4751
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
PyThread_allocate_lock can fail without interference. object-lock will
stay NULL and the GIL is simply not released.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4751
New submission from Lukas Lueg knabberknusperh...@yahoo.de:
MD5 is one of the most popular cryptographic hash-functions around,
mainly for it's good performance and availability throughout
applications and libraries. The MD5 algorithm is currently implemented
in python as part of the hashlib
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
As I already said to Raymond: At least we should update the
documentation. The FAQ currently linked is from 2005.
The CERT-Advisory from provides a clean and simple language: In 2008,
researchers demonstrated the practical vulnerability
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
It might be a good idea to remove the word secure from the
hashlib documentation, since security of these algorithms is
always limited to a certain period of time.
I'm sorry, was that a boy attempted humor ? [Misuse quote from DH3
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
please attach 64times01-double.zip if possible
--
nosy: +ebfe
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4844
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
solved in #4818 and #4821
--
nosy: +ebfe
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3745
Changes by Lukas Lueg knabberknusperh...@yahoo.de:
Removed file: http://bugs.python.org/file12533/hashopenssl_threads-4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4751
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
I've modified haypo's patch as commented. The object's lock should be
free 99.9% of the time so we try non-blocking first and can thereby skip
releasing and re-locking the gil (to avoid a deadlock).
Added file: http://bugs.python.org
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
The current behaviour may help the majority by ignorance and cause weird
errors for others. We tell people that Python distincts between Text and
Data but actually treat it all the same by implicit encoding.
Modules that only operate
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
Sent the form by fax
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4818
___
___
Python-bugs-list
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
fixed naming, lock get's tried before releasing the gil to wait for it
Added file: http://bugs.python.org/file12568/md5module_small_locks-2.diff
___
Python tracker rep...@bugs.python.org
http
Changes by Lukas Lueg knabberknusperh...@yahoo.de:
Removed file: http://bugs.python.org/file12565/md5module_small_locks.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4818
New submission from Lukas Lueg knabberknusperh...@yahoo.de:
Here is the follow-up to issue #4818. The patches attached allow the
built-in SHA modules to release the GIL.
Also the build-in SHA modules will now no longer accept s# as input.
Input is parsed just as in the openssl-driven classes
Changes by Lukas Lueg knabberknusperh...@yahoo.de:
--
keywords: +patch
Added file: http://bugs.python.org/file12569/sha1module_small_locks.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4821
Changes by Lukas Lueg knabberknusperh...@yahoo.de:
Added file: http://bugs.python.org/file12570/sha256module_small_locks.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4821
Changes by Lukas Lueg knabberknusperh...@yahoo.de:
Added file: http://bugs.python.org/file12571/sha512module_small_locks.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4821
Lukas Lueg knabberknusperh...@yahoo.de added the comment:
The lock is created while having the GIL in EVP_update. No other
function releases the GIL (besides the creator-function which does not
need the local lock).
Thereby no other thread can be in between ENTER and LEAVE while the lock
69 matches
Mail list logo
