[issue25299] TypeError: __init__() takes at least 4 arguments (4 given)
A. Skrobov added the comment: Joannah, I see that under #25314, the docs were updated to match the implementation: https://github.com/python/cpython/commit/b4912b8ed367e540ee060fe912f841cc764fd293 On the other hand, the discussion here (from 2015) and on #25314 (from 2016) includes suggestions for improvements in the implementation as well. -- ___ Python tracker <https://bugs.python.org/issue25299> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36256] parser module fails on legal input
A. Skrobov added the comment: Is it intentional that the fix is not backported to 3.6 as well? -- ___ Python tracker <https://bugs.python.org/issue36256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36440] more helpful diagnostics for parser module
A. Skrobov added the comment: > Nothing was really "decided", just that meanwhile is better not to ship a > broken parser module. Totally true, but the issue is closed and resolved, meaning that no one will ever look at it again. -- ___ Python tracker <https://bugs.python.org/issue36440> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36440] more helpful diagnostics for parser module
New submission from A. Skrobov : Seeing that the implicit resolution at #36256 was to keep the parser module in place, may I suggest that the diagnostics it produces be improved, so that instead of "Expected node type 305, got 11", it would raise "Expected namedexpr_test, got COLON" -- components: Extension Modules messages: 338897 nosy: A. Skrobov, benjamin.peterson, berker.peksag, brett.cannon, fdrake, gregory.p.smith, pablogsal, python-dev, serhiy.storchaka, xcombelle priority: normal severity: normal status: open title: more helpful diagnostics for parser module type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue36440> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36440] more helpful diagnostics for parser module
Change by A. Skrobov : -- keywords: +patch pull_requests: +12510 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36440> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36256] parser module fails on legal input
A. Skrobov added the comment: > The major problem with the parser module is that is unsynchronized with the > actual parser The parser module is "sort of" synchronised with the actual parser, in that it uses the same _PyParser_Grammar; this doesn't mean they always behave the same, as this bug shows :-) (But before #26526, it used to be much worse, with the parser module having a completely independent re-implementation of the parser.) > As a side note, the problem described in this bug was more or less foreseen. > This is in the header of Modules/parsemodule.c: Just to clarify, the bug is not about the cryptic exception message, it's about the exception firing when it shouldn't. -- ___ Python tracker <https://bugs.python.org/issue36256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36256] parser module fails on legal input
New submission from A. Skrobov :
Under #26526, I had optimised the validation code in parser module to use the
actual parser DFAs, but my code considers only the token types in the input,
and doesn't distinguish between different NAMEs (e.g. different keywords).
The result is this:
Python 3.7.0 (default, Aug 22 2018, 20:50:05)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import parser
>>> parser.sequence2st(parser.suite("if True:\n pass\nelse:\n pass").totuple())
Traceback (most recent call last):
File "", line 1, in
parser.ParserError: Expected node type 305, got 11.
The fix for this bug is quite simple, and in fact, it had been languishing for
2.5 years under #26415
I can easily enough extract the fix into a PR of its own, but the bigger
question is: parser module had been advised against using since Python 2.5; now
that it has been broken for 2.5 years, nobody even noticed. (if-else must be
quite a common code construct, so anybody trying to use the module would have
noticed!) So, should perhaps the module be discontinued rather than fixed?
--
components: Extension Modules
messages: 337619
nosy: A. Skrobov, benjamin.peterson, berker.peksag, brett.cannon, fdrake,
giampaolo.rodola, gregory.p.smith, pablogsal, python-dev, serhiy.storchaka,
xcombelle
priority: normal
severity: normal
status: open
title: parser module fails on legal input
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue36256>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Excessive peak memory consumption by the Python parser
A. Skrobov added the comment: I've run pyperformance (0.7.0) with my updated patch, and posted results at the PR page. They look encouraging enough. -- ___ Python tracker <https://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Excessive peak memory consumption by the Python parser
A. Skrobov added the comment: @Serhiy: incredibly, this patch from 2.5 years ago required very minor changes to apply to the latest master. Shows how ossified the parser is :-) Now posted as https://github.com/python/cpython/pull/10995 -- ___ Python tracker <https://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Excessive peak memory consumption by the Python parser
A. Skrobov added the comment: To bump this year-old issue, I have delivered a talk at EuroPython 2017, explaining what my patch does, how it does what it does, and why it's a good thing to do. You can watch my talk at https://www.youtube.com/watch?v=dyRDmcsTwhE&t=1h52m38s -- ___ Python tracker <http://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26526] In parsermodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA
A. Skrobov added the comment: Oh btw, the comment in the beginning of Grammar/Grammar > # Note: Changing the grammar specified in this file will most likely > #require corresponding changes in the parser module > #(../Modules/parsermodule.c). is no longer true: after this patch went in, changing the grammar no longer requires translating the changes into Modules/parsermodule.c Can somebody please remove the obsolete comment from there? -- ___ Python tracker <http://bugs.python.org/issue26526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Excessive peak memory consumption by the Python parser
A. Skrobov added the comment: Updated the comment for Init_ValidationGrammar() -- Added file: http://bugs.python.org/file44370/patch ___ Python tracker <http://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Excessive peak memory consumption by the Python parser
A. Skrobov added the comment: Xavier, the big picture description of my patch is in http://bugs.python.org/file43665/devguide_patch The heap fragmentation was observed by Victor, not by myself. Victor, could you please create a new ticket for your python_memleak.py reproducer? -- ___ Python tracker <http://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26526] In parsermodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA
A. Skrobov added the comment: Thanks Xavier! Yes, this is the same DFA that's used by the main Python parser. For some reason, parsermodule didn't previously reuse it, but instead did its own thing. Any volunteers to review the other patch for Python parser, at http://bugs.python.org/issue26415 ? -- ___ Python tracker <http://bugs.python.org/issue26526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Excessive peak memory consumption by the Python parser
A. Skrobov added the comment: Fixing whitespace in the patch, and including an update for the docs -- Added file: http://bugs.python.org/file43664/patch ___ Python tracker <http://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Excessive peak memory consumption by the Python parser
Changes by A. Skrobov : Added file: http://bugs.python.org/file43665/devguide_patch ___ Python tracker <http://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Excessive peak memory consumption by the Python parser
A. Skrobov added the comment: (Updating the issue title, to avoid confusion between two orthogonal concerns) -- title: Fragmentation of the heap memory in the Python parser -> Excessive peak memory consumption by the Python parser ___ Python tracker <http://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Fragmentation of the heap memory in the Python parser
A. Skrobov added the comment: My current patch avoids the memory peak *and* doesn't add any memory fragmentation on top of whatever is already there. In other words, it makes the parser better in this one aspect, and it doesn't make it worse in any aspect. -- ___ Python tracker <http://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Fragmentation of the heap memory in the Python parser
A. Skrobov added the comment: An arena might help reclaim the memory once the parsing is complete, but it wouldn't reduce the peak memory consumption by the parser, and so it wouldn't prevent a MemoryError when parsing a 35MB source on a PC with 2GB of RAM. -- ___ Python tracker <http://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Fragmentation of the heap memory in the Python parser
A. Skrobov added the comment:
Now that #26526 landed (thanks to everybody involved!), I'm requesting a review
on an updated version of my patch, which addresses the excessive memory
consumption by the parser.
The description of my original patch still applies:
> The attached patch for the parser reduces "Maximum resident set size
> (kbytes)" threefold, for the degenerate example of 'import ast;
> ast.parse("0,"*100, mode="eval")', by eliminating many CST nodes that
> have a single child.
>
> According to the comment in Parser/node.c -- "89% of PyObject_REALLOC calls
> in PyNode_AddChild passed 1 for the size" -- the memory saving should be
> generally applicable, and not limited just to this degenerate case.
> I've now tried it with "perf.py -r -m", and the memory savings are as follows:
> ...
> on these benchmarks, the saving is not threefold, of course; but still quite
> substantial (up to 30%).
My new patch updates Modules/parsermodule.c to accept such "compressed" nodes,
so that everything still builds cleanly and passes the tests.
--
nosy: +benjamin.peterson, berker.peksag, brett.cannon, fdrake, giampaolo.rodola
Added file: http://bugs.python.org/file43261/patch
___
Python tracker
<http://bugs.python.org/issue26415>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26526] In parsermodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA
Changes by A. Skrobov : -- keywords: +patch Added file: http://bugs.python.org/file43069/issue26526_16704_63395.diff ___ Python tracker <http://bugs.python.org/issue26526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26526] In parsermodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA
A. Skrobov added the comment: Thank you Fred for your review! I don't have commit access myself; can anybody please commit it for me? -- ___ Python tracker <http://bugs.python.org/issue26526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Fragmentation of the heap memory in the Python parser
A. Skrobov added the comment: Ping? This patch is two months old now. -- ___ Python tracker <http://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26526] In parsermodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA
A. Skrobov added the comment: Ping? This patch is two months old now. -- ___ Python tracker <http://bugs.python.org/issue26526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Fragmentation of the heap memory in the Python parser
A. Skrobov added the comment: I've now tried it with "perf.py -r -m", and the memory savings are as follows: ### 2to3 ### Mem max: 45976.000 -> 47440.000: 1.0318x larger ### chameleon_v2 ### Mem max: 436968.000 -> 401088.000: 1.0895x smaller ### django_v3 ### Mem max: 23808.000 -> 22584.000: 1.0542x smaller ### fastpickle ### Mem max: 10768.000 -> 9248.000: 1.1644x smaller ### fastunpickle ### Mem max: 10988.000 -> 9328.000: 1.1780x smaller ### json_dump_v2 ### Mem max: 10892.000 -> 10612.000: 1.0264x smaller ### json_load ### Mem max: 11012.000 -> 9908.000: 1.1114x smaller ### nbody ### Mem max: 8696.000 -> 7944.000: 1.0947x smaller ### regex_v8 ### Mem max: 12504.000 -> 9432.000: 1.3257x smaller ### tornado_http ### Mem max: 27636.000 -> 27608.000: 1.0010x smaller So, on these benchmarks, the saving is not threefold, of course; but still quite substantial (up to 30%). The run time difference, on these benchmarks, is between "1.04x slower" and "1.06x faster", for reasons beyond my understanding (variability of background load, possibly?) -- ___ Python tracker <http://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26526] In parsemodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA
New submission from A. Skrobov: Updating Modules/parsermodule.c for every change in grammar and/or parser is a maintenance burden, listed as such at https://docs.python.org/devguide/grammar.html The attached patch lets the validation code use the auto-generated DFA structures, thus ensuring it stays up to date with the grammar. It also trims the code by over 2KLOC. -- components: Extension Modules files: patch messages: 261486 nosy: A. Skrobov, fdrake priority: normal severity: normal status: open title: In parsemodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file42110/patch ___ Python tracker <http://bugs.python.org/issue26526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Fragmentation of the heap memory in the Python parser
A. Skrobov added the comment:
The attached patch for the parser reduces "Maximum resident set size (kbytes)"
threefold, for the degenerate example of 'import ast; ast.parse("0,"*100,
mode="eval")', by eliminating many CST nodes that have a single child.
According to the comment in node.c -- "89% of PyObject_REALLOC calls in
PyNode_AddChild passed 1 for the size" -- the memory saving should be generally
applicable, and not limited just to this degenerate case.
Modules/parsermodule.c is not yet updated to match. Please tell if you want me
to do that, in case that my proposed change to the parser is acceptable.
--
Added file: http://bugs.python.org/file42101/patch
___
Python tracker
<http://bugs.python.org/issue26415>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Fragmentation of the heap memory in the Python parser
A. Skrobov added the comment: @Serhiy: if your build is 32-bit, then every node is half the size, as it mostly consists of pointers. The amount of heap fragmentation can also depend on gcc/glibc version. -- ___ Python tracker <http://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Out of memory, trying to parse a 35MB dict
A. Skrobov added the comment:
OK, I've now looked into it with a fresh build of 3.6 trunk on Linux x64.
Peak memory usage is about 3KB per node:
$ /usr/bin/time -v ./python -c 'import ast; ast.parse("0,"*100,
mode="eval")'
Command being timed: "./python -c import ast; ast.parse("0,"*100,
mode="eval")"
...
Maximum resident set size (kbytes): 3015552
...
Out of the 2945 MB total peak memory usage, only 330 MB are attributable to the
heap use:
$ valgrind ./python -c 'import ast; ast.parse("0,"*100, mode="eval")'
==21232== ...
==21232== HEAP SUMMARY:
==21232== in use at exit: 3,480,447 bytes in 266 blocks
==21232== total heap usage: 1,010,171 allocs, 1,009,905 frees, 348,600,304
bytes allocated
==21232== ...
So, apparently, it's not the nodes themselves taking up a disproportionate
amount of memory -- it's the heap getting so badly fragmented that 89% of its
memory allocation is wasted.
gprof confirms that there are lots of mallocs/reallocs going on, up to 21 per
node:
$ gprof python
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls s/call s/call name
17.82 0.31 0.31 220 0.00 0.00 PyParser_AddToken
13.79 0.55 0.242 0.12 0.16 freechildren
12.64 0.77 0.22 21039125 0.00 0.00 _PyMem_RawMalloc
6.32 0.88 0.11 17000101 0.00 0.00 PyNode_AddChild
5.75 0.98 0.10 28379846 0.00 0.00 visit_decref
5.75 1.08 0.10 104 0.00 0.00 ast_for_expr
4.60 1.16 0.08 2867 0.00 0.00 collect
4.02 1.23 0.07 20023405 0.00 0.00 _PyObject_Free
2.30 1.27 0.04 3031305 0.00 0.00 _PyType_Lookup
2.30 1.31 0.04 3002234 0.00 0.00
_PyObject_GenericSetAttrWithDict
2.30 1.35 0.041 0.04 0.05 ast2obj_expr
1.72 1.38 0.03 28366858 0.00 0.00 visit_reachable
1.72 1.41 0.03 12000510 0.00 0.00 subtype_traverse
1.72 1.44 0.03 3644 0.00 0.00 list_traverse
1.44 1.47 0.03 3002161 0.00 0.00 _PyObjectDict_SetItem
1.15 1.49 0.02 20022785 0.00 0.00 PyObject_Free
1.15 1.51 0.02 15000763 0.00 0.00 _PyObject_Realloc
So, I suppose what needs to be done is to try reducing the number of reallocs
involved in handling an AST node; the representation of the nodes themselves
doesn't need to change.
--
___
Python tracker
<http://bugs.python.org/issue26415>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Out of memory, trying to parse a 35MB dict
A. Skrobov added the comment: Yes, I understand that this is a matter of memory consumption, which is why I submitted this ticket as "resource usage". What I don't understand is, what could possibly require gigabytes of memory for this task? -- ___ Python tracker <http://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Out of memory, trying to parse a 35MB dict
A. Skrobov added the comment: My Python is 64-bit, but my computer only has 2GB physical RAM. -- ___ Python tracker <http://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Out of memory, trying to parse a 35MB dict
A. Skrobov added the comment: Mine is on Windows. I've now installed both 2.7.10 and 3.4.3 to reconfirm, and it's still the same, on both of them, except that on 3.4.3 it crashes with a MemoryError much faster (within a couple minutes). -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware versions: +Python 3.4 ___ Python tracker <http://bugs.python.org/issue26415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Out of memory, trying to parse a 35MB dict
A. Skrobov added the comment:
A practical note: if, instead of importing crash.py, I do a json.loads, with a
few extra transformations:
with open("crash.py") as f: holo_table={tuple(int(z) for z in k.split(', ')):v
for k,v in
json.loads(f.readlines()[0][13:].replace('(','"').replace(')','"')).iteritems()}
--the whole data structure loads in a jiffy.
Makes me wonder why this roundabout approach is so much more efficient than the
native parsing.
--
___
Python tracker
<http://bugs.python.org/issue26415>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26415] Out of memory, trying to parse a 35MB dict
New submission from A. Skrobov:
I have a one-line module that assigns a tuple->int dictionary:
holo_table = {(0, 0, 0, 0, 0, 0, 1, 41, 61, 66, 89): 9, (0, 0, 0, 70, 88, 98,
103, 131, 147, 119, 93): 4, [35MB skipped], (932, 643, 499, 286, 326, 338, 279,
200, 280, 262, 115): 5}
When I try to import this module, Python grinds 100% of my CPU for like half an
hour, then ultimately crashes with a MemoryError.
How much memory does it need to parse 35MB of data, of a rather simple
structure?
Attaching the module, zipped to 10MB.
--
components: Interpreter Core
files: crash.zip
messages: 260704
nosy: A. Skrobov
priority: normal
severity: normal
status: open
title: Out of memory, trying to parse a 35MB dict
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file42011/crash.zip
___
Python tracker
<http://bugs.python.org/issue26415>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25299] TypeError: __init__() takes at least 4 arguments (4 given)
A. Skrobov added the comment: Thank you for confirming that the mismatch between the documentation and the behaviour is preserved in Python 3! Adding it to the list of affected versions. -- versions: +Python 3.5 ___ Python tracker <http://bugs.python.org/issue25299> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25299] TypeError: __init__() takes at least 4 arguments (4 given)
New submission from A. Skrobov:
Python 2.7.3 (default, Dec 18 2014, 19:10:20)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from argparse import ArgumentParser
>>> parser = ArgumentParser()
>>> parser.add_argument("--foo", help="foo", action='store_const')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/argparse.py", line 1281, in add_argument
action = action_class(**kwargs)
TypeError: __init__() takes at least 4 arguments (4 given)
>>>
First, the exception message is entirely unhelpful (you wanted at least 4, you
got 4, what's your problem?)
Second, adding "const=None" to the invocation makes it succeed; but, according
to https://docs.python.org/2/library/argparse.html#const this argument defaults
to "None", so it shouldn't be necessary to specify it explicitly. Thus, either
the documentation or the implementation is wrong.
--
assignee: docs@python
components: Documentation, Extension Modules
messages: 252106
nosy: A. Skrobov, docs@python
priority: normal
severity: normal
status: open
title: TypeError: __init__() takes at least 4 arguments (4 given)
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue25299>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23592] SIGSEGV on interpreter shutdown, with daemon threads running wild
A. Skrobov added the comment: That's right; and working around this issue, by taming the daemon threads a bit, wasn't too difficult. Still, if the daemon threads are part of the language, they shouldn't crash the interpreter process, I suppose? -- ___ Python tracker <http://bugs.python.org/issue23592> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23592] SIGSEGV on interpreter shutdown, with daemon threads running wild
New submission from A. Skrobov: I'm observing that this line of code: https://hg.python.org/cpython/file/ec9bffc35cad/Python/ceval.c#l3010 -- causes a SIGSEGV on interpreter shutdown, after running some really convoluted Python code with daemon threads running wild. At the time of the crash, tstate->frame==NULL, and tstate->curexc_type points to an exceptions.UnboundLocalError I can reliably reproduce the crash, but unfortunately I cannot provide a standalone reproducer. I'm speculating that this case is due to some daemon threads carrying on running while their variables are being destroyed from underneath them. The traceback is probably of little use, but adding it nevertheless: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x4dc15940 (LWP 10317)] 0x004d5c00 in PyEval_EvalFrameEx (f=0xc0da70, throwflag=0) at Python/ceval.c:3010 3010if (tstate->frame->f_exc_type != NULL) (gdb) bt #0 0x004d5c00 in PyEval_EvalFrameEx (f=0xc0da70, throwflag=0) at Python/ceval.c:3010 #1 0x004d6db2 in PyEval_EvalCodeEx (co=0x2be1d510, globals=0x2b9c62f0, locals=0x0, args=0x2f6e9bf8, argcount=2, kws=0x2f6e9c08, kwcount=0, defs=0x2be2fb78, defcount=1, closure=0x0) at Python/ceval.c:3267 #2 0x004d9ac9 in fast_function (func=0x2be37648, pp_stack=0x4dc13c90, n=2, na=2, nk=0) at Python/ceval.c:4131 #3 0x004d96d8 in call_function (pp_stack=0x4dc13c90, oparg=1) at Python/ceval.c:4056 #4 0x004d4258 in PyEval_EvalFrameEx (f=0x2f6e9a60, throwflag=0) at Python/ceval.c:2681 #5 0x004d6db2 in PyEval_EvalCodeEx (co=0x2be26250, globals=0x2b9c62f0, locals=0x0, args=0x2ac81f48, argcount=2, kws=0x2ac81f58, kwcount=0, defs=0x2be2fe88, defcount=1, closure=0x0) at Python/ceval.c:3267 #6 0x004d9ac9 in fast_function (func=0x2be39108, pp_stack=0x4dc14230, n=2, na=2, nk=0) at Python/ceval.c:4131 #7 0x004d96d8 in call_function (pp_stack=0x4dc14230, oparg=1) at Python/ceval.c:4056 #8 0x004d4258 in PyEval_EvalFrameEx (f=0x2ac81db8, throwflag=0) at Python/ceval.c:2681 #9 0x004d99af in fast_function (func=0x2ee97840, pp_stack=0x4dc14620, n=1, na=1, nk=0) at Python/ceval.c:4121 #10 0x004d96d8 in call_function (pp_stack=0x4dc14620, oparg=0) at Python/ceval.c:4056 #11 0x004d4258 in PyEval_EvalFrameEx (f=0xc47fe0, throwflag=0) at Python/ceval.c:2681 #12 0x004d99af in fast_function (func=0x2be396f0, pp_stack=0x4dc14a10, n=1, na=1, nk=0) at Python/ceval.c:4121 #13 0x004d96d8 in call_function (pp_stack=0x4dc14a10, oparg=0) at Python/ceval.c:4056 #14 0x004d4258 in PyEval_EvalFrameEx (f=0x2f67bdf0, throwflag=0) at Python/ceval.c:2681 #15 0x004d6db2 in PyEval_EvalCodeEx (co=0x2be26880, globals=0x2b9c62f0, locals=0x0, args=0x2ef75fd8, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3267 #16 0x0056346e in function_call (func=0x2be395a0, arg=0x2ef75fb0, kw=0x0) at Objects/funcobject.c:526 #17 0x0042182c in PyObject_Call (func=0x2be395a0, arg=0x2ef75fb0, kw=0x0) at Objects/abstract.c:2529 #18 0x0042c0d0 in instancemethod_call (func=0x2be395a0, arg=0x2ef75fb0, kw=0x0) at Objects/classobject.c:2602 #19 0x0042182c in PyObject_Call (func=0x2eec5060, arg=0x2aacf060, kw=0x0) at Objects/abstract.c:2529 #20 0x004d8ceb in PyEval_CallObjectWithKeywords (func=0x2eec5060, arg=0x2aacf060, kw=0x0) at Python/ceval.c:3904 #21 0x0052358b in t_bootstrap (boot_raw=0x2fab9d78) at ./Modules/threadmodule.c:614 #22 0x00342f00677d in start_thread () from /lib64/libpthread.so.0 #23 0x00342e4d49ad in clone () from /lib64/libc.so.6 -- components: Interpreter Core messages: 237283 nosy: A. Skrobov priority: normal severity: normal status: open title: SIGSEGV on interpreter shutdown, with daemon threads running wild type: crash versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue23592> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
