[issue29242] Crash on GC when compiling PyPy
New submission from Dingyuan Wang: When compiling the PyPy default branch [1] on a Debian testing machine with Python 2.7.13, cpython randomly crashes. (gdb) bt #0 update_refs () at ../Modules/gcmodule.c:332 #1 collect.lto_priv () at ../Modules/gcmodule.c:924 #2 0x5562a804 in collect_generations () at ../Modules/gcmodule.c:1050 #3 _PyObject_GC_Malloc () at ../Modules/gcmodule.c:1511 #4 0x55640ef5 in PyType_GenericAlloc (nitems=0, type=0x55a9dd20 <_PyExc_AttributeError>) at ../Objects/typeobject.c:781 #5 BaseException_new.lto_priv.68 () at ../Objects/exceptions.c:34 #6 0x55642093 in type_call.lto_priv () at ../Objects/typeobject.c:749 #7 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547 #8 0x5565a490 in PyEval_CallObjectWithKeywords () at ../Python/ceval.c:4221 #9 0x556695d0 in PyErr_NormalizeException () at ../Python/errors.c:192 #10 0x55656cad in PyEval_EvalFrameEx () at ../Python/ceval.c:3251 #11 0x5564e525 in PyEval_EvalCodeEx () at ../Python/ceval.c:3584 #12 0x5566ac2e in function_call.lto_priv () at ../Objects/funcobject.c:523 #13 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547 #14 0x5568102e in instancemethod_call.lto_priv () at ../Objects/classobject.c:2602 #15 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547 #16 0x556f333a in call_method.lto_priv () at ../Objects/typeobject.c:1283 #17 0x5573eb8f in slot_tp_setattro.lto_priv () at ../Objects/typeobject.c:5654 #18 0x556667e9 in PyObject_SetAttr () at ../Objects/object.c:1247 #19 0x55650ec3 in PyEval_EvalFrameEx () at ../Python/ceval.c:2253 #20 0x5564e525 in PyEval_EvalCodeEx () at ../Python/ceval.c:3584 #21 0x5566ac2e in function_call.lto_priv () at ../Objects/funcobject.c:523 #22 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547 #23 0x5568102e in instancemethod_call.lto_priv () at ../Objects/classobject.c:2602 #24 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547 #25 0x5565a4dd in PyEval_CallObjectWithKeywords () at ../Python/ceval.c:4221 #26 0x556f3e31 in slot_tp_hash.lto_priv () at ../Objects/typeobject.c:5506 #27 0x5568c908 in dict_subscript.lto_priv () at ../Objects/dictobject.c:1202 #28 0x5565618e in PyEval_EvalFrameEx () at ../Python/ceval.c:1539 #29 0x5564e525 in PyEval_EvalCodeEx () at ../Python/ceval.c:3584 #30 0x5566ac2e in function_call.lto_priv () at ../Objects/funcobject.c:523 #31 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547 #32 0x5568102e in instancemethod_call.lto_priv () at ../Objects/classobject.c:2602 #33 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547 #34 0x5565a490 in PyEval_CallObjectWithKeywords () at ../Python/ceval.c:4221 #35 0x5569ff3a in instance_subscript.lto_priv () at ../Objects/classobject.c:1105 #36 0x5565618e in PyEval_EvalFrameEx () at ../Python/ceval.c:1539 #37 0x5564e525 in PyEval_EvalCodeEx () at ../Python/ceval.c:3584 #38 0x5566ac2e in function_call.lto_priv () at ../Objects/funcobject.c:523 #39 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547 #40 0x55672dd9 in slot_tp_new.lto_priv () at ../Objects/typeobject.c:5849 #41 0x55642093 in type_call.lto_priv () at ../Objects/typeobject.c:749 #42 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547 #43 0x55655e8f in do_call (nk=, na=1, pp_stack=0x7fffb950, func=) at ../Python/ceval.c:4569 #44 call_function (oparg=, pp_stack=0x7fffb950) at ../Python/ceval.c:4374 #45 PyEval_EvalFrameEx () at ../Python/ceval.c:2989 #46 0x55655c7f in fast_function (nk=, na=, n=, pp_stack=0x7fffbaa0, func=) at ../Python/ceval.c:4437 #47 call_function (oparg=, pp_stack=0x7fffbaa0) at ../Python/ceval.c:4372 #48 PyEval_EvalFrameEx () at ../Python/ceval.c:2989 #49 0x55655c7f in fast_function (nk=, na=, n=, pp_stack=0x7fffbbf0, func=) at ../Python/ceval.c:4437 #50 call_function (oparg=, pp_stack=0x7fffbbf0) at ../Python/ceval.c:4372 #51 PyEval_EvalFrameEx () at ../Python/ceval.c:2989 #52 0x55655c7f in fast_function (nk=, na=, n=, pp_stack=0x7fffbd40, func=) at ../Python/ceval.c:4437 ---Type to continue, or q to quit--- #53 call_function (oparg=, pp_stack=0x7fffbd40) at ../Python/ceval.c:4372 #54 PyEval_EvalFrameEx () at ../Python/ceval.c:2989 #55 0x55655c7f in fast_function (nk=, na=, n=, pp_stack=0x7fffbe90, func=) at ../Python/ceval.c:4437 #56 call_function (oparg=, pp_stack=0x7fffbe90) at ../Python/ceval.c:4372 #57 PyEval_EvalFrameEx () at ../Python/ceval.c:2989 #58 0x55655c7f in fast_function (nk=, na=, n=, pp_stack=0x7fffbfe0, func=) at ../Python/ceval.c:4437 #59 call_function (oparg=, pp_stack=0x7fffbfe0) at ../Python/ceval.c:43
[issue28985] sqlite3 authorizer codes constants not up to date
New submission from Dingyuan Wang: We have the sqlite3.set_authorizer function, where the first argument to its callback is one of the Authorizer Action Codes that the SQLite documentations defines[1]. However, the constants in the sqlite3 module is not up to date. The code in _sqlite/module.c haven't been updated since June, 2006. According to the SQLite Changelog[2] and digging through the history, * 2006-08-12 (3.3.7) added SQLITE_CREATE_VTABLE, SQLITE_DROP_VTABLE * 2006-10-09 (3.3.8) added SQLITE_FUNCTION * 2009-01-12 (3.6.8) added SQLITE_SAVEPOINT * 2014-02-03 (3.8.3) added SQLITE_RECURSIVE The constants above should be present in the module. The documentation[3] says, "All necessary constants are available in the sqlite3 module." [1] https://sqlite.org/c3ref/c_alter_table.html [2] https://sqlite.org/changes.html [3] https://docs.python.org/3/library/sqlite3.html#sqlite3.Connection.set_authorizer -- components: Library (Lib) files: sqlite3.patch keywords: patch messages: 283363 nosy: gumblex priority: normal severity: normal status: open title: sqlite3 authorizer codes constants not up to date type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45921/sqlite3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28985> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23962] Incorrect TimeoutError referenced in concurrent.futures documentation
Changes by Dingyuan Wang <abcdoyle...@gmail.com>: -- nosy: +gumblex ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25624] shutil.make_archive makes invalid directory entries
Dingyuan Wang added the comment: Yes, patching zipfile is enough. I wrote a test using `unzip -t` to check the zip. ZipFile.testzip can't detect this kind of error because zlib.decompressobj(-15) will decode b'' to b'' without errors. -- Added file: http://bugs.python.org/file41120/storedirectory_test.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25624] shutil.make_archive makes invalid directory entries
Dingyuan Wang added the comment:
$ mkdir foo; touch foo/a.txt; python3 -c "import shutil;
shutil.make_archive('foo', 'zip', base_dir='foo')"; unzip -t foo.zip
Archive: foo.zip
testing: foo/
error: invalid compressed data to inflate
testing: foo/a.txtOK
At least one error was detected in foo.zip.
(This affects 2.7, 3.4+)
--
versions: +Python 2.7, Python 3.4
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25624>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25624] shutil.make_archive makes invalid directory entries
New submission from Dingyuan Wang: The _make_zipfile in shutil uses ZIP_DEFLATED compression by default, and the fix introduced by #24982 adds directory entries. In zipfile.ZipFile.write, directories is added as 0 file_size, 0 compress_size, regardless of the compression method. Deflate will compress an empty string as \x03\x00, thus the directory entries become incorrect. The command line interface of zipfile is correct. Shutil can be fixed as zipfile.main. As a directory entry with compression methods other than ZIP_STORED is meaningless, zipfile.write and (maybe) zipfile.writestr should always write a ZIP_STORED header for directory entries to avoid the above problem occuring by programming mistakes. -- components: Library (Lib) messages: 254647 nosy: gumblex priority: normal severity: normal status: open title: shutil.make_archive makes invalid directory entries type: behavior versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25624] shutil.make_archive makes invalid directory entries
Dingyuan Wang added the comment: My patch for this. -- keywords: +patch Added file: http://bugs.python.org/file41039/storedirectory.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20387] tokenize/untokenize roundtrip fails with tabs
Dingyuan Wang added the comment: I mean the patch only restores tabs in indentation. The reports above should be corrected. Tabs between tokens and other race conditions can't be restored exactly providing the token stream. This won't affect the syntax. I wonder if it's also a bug or a wont-fix in tokenize/untokenize roundtrip because fixing it involves adding whitespace information in the token stream. (I can't pull down the whole hg repo, so the patch is manually created by just diffing two versions.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20387 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20387] tokenize/untokenize roundtrip fails with tabs
Dingyuan Wang added the comment:
Sorry for the inconvenience. I failed to find this old bug.
I think there is another problem. The docs of `untokenize` said The iterable
must return sequences with **at least** two elements, the token type and the
token string. Any additional sequence elements are ignored., so if I feed in,
say, a 3-tuple, the untokenize should accept it as tok[:2].
The attached patch should have addressed the problems above.
When trying to make a patch, a tokenize bug was found. Consider the new
attached tab.py, the tabs between comments and code, and the tabs between
expressions are lost, so when untokenizing, position information is used to
produce equivalent spaces, instead of tabs.
Despite the tokenization problem, the patch can produce syntactically correct
code as accurately as it can.
The PEP 8 recommends spaces for indentation, but the usage of tabs should not
be ignored.
new tab.py (in Python string):
'#!/usr/bin/env python\n# -*- coding: utf-8 -*-\n\ndef foo():\n\t\n\tTests
tabs in tokenization\n\t\tfoo\n\t\n\tpass\n\tpass\n\tif 1:\n\t\t# not indent
correctly\n\t\tpass\n\t\t# correct\ttab\n\t\tpass\n\tpass\n\tbaaz =
{\'a\ttab\':\t1,\n\t\t\t\'b\': 2}\t\t# also fails\n\npass\n#if
2:\n\t#pass\n#pass\n'
--
keywords: +patch
nosy: +gumblex
Added file: http://bugs.python.org/file39748/tokenize.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20387
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24447] tab indentation breaks in tokenize.untokenize
New submission from Dingyuan Wang: If a script uses tabs for indentation, tokenize.untokenize won't restore original indentation correctly from the second line of the indentation level, and thus breaks the file. This affects all Python versions. Test code: python2 -c 'import sys, tokenize; sys.stdout.write(tokenize.untokenize(tokenize.generate_tokens(sys.stdin.readline)))' tab.py python3 -c 'import sys, tokenize; sys.stdout.buffer.write(tokenize.untokenize(tokenize.tokenize(sys.stdin.buffer.readline)))' tab.py Out: def foo(): pass pass if 1: pass pass -- components: Library (Lib) files: tab.py messages: 245333 nosy: gumblex priority: normal severity: normal status: open title: tab indentation breaks in tokenize.untokenize type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file39704/tab.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24447 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
