[issue43367] submodule of c-extension module is quirky
Change by Yannick Jadoul : -- nosy: +YannickJadoul ___ Python tracker <https://bugs.python.org/issue43367> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43145] Leak of locks in a subprocess
Change by Yannick Jadoul : -- nosy: +YannickJadoul ___ Python tracker <https://bugs.python.org/issue43145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42961] Use-after-free (of a heap type) during finalization
Change by Yannick Jadoul : -- nosy: +YannickJadoul ___ Python tracker <https://bugs.python.org/issue42961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42882] Restarting the interpreter causes UB on 3.10.0a4
Yannick Jadoul added the comment: Wow, that was fast! Thanks! I tried this out locally, and all pybind11's tests pass now. We can try again once there's a nightly build or new alpha :-) -- ___ Python tracker <https://bugs.python.org/issue42882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42882] Restarting the interpreter causes UB on 3.10.0a4
New submission from Yannick Jadoul :
Issue detected in the embedding tests of pybind11, running on the latest alpha
of 3.10: https://github.com/pybind/pybind11/issues/2774
I have reduced the weird issue/crash to a minimal reproducer, which
consistently reproduces the crash on my Linux machine:
```
#include
int main() {
Py_InitializeEx(1);
Py_Finalize();
Py_InitializeEx(1);
PyRun_SimpleString("class Widget: pass\n"
"class DerivedWidget(Widget):\n"
"def __init__(self):\n"
"super().__init__()\n");
Py_Finalize();
printf("Works\n");
return 0;
}
```
Removing the two lines in the middle that restart the interpreter makes the
example work.
I've also bisected CPython to find the issue (3.10.0a3 is fine, 3.10.0a4 is
not), and arrived at https://github.com/python/cpython/pull/20058
(ba3d67c2fb04a7842741b1b6da5d67f22c579f33 being the first commit that breaks
the example above). But I am not entirely sure where to start debugging.
The reproducing example above consistently crashes on my local machine
(SIGABRT, exit code 134):
```
Fatal Python error: compiler_make_closure: lookup '__class__' in DerivedWidget
5 -1
freevars of __init__: ('__class__',)
Python runtime state: initialized
Current thread 0x7f036485b680 (most recent call first):
Aborted (core dumped)
```
But note that in the pybind11 tests, the underlying issue causes a different
error (Python throwing a weird, seemingly unrelated exception). So something
seems to be messed up in the interpreter internals, and the above example just
triggers it.
--
components: Interpreter Core
messages: 384761
nosy: YannickJadoul
priority: normal
severity: normal
status: open
title: Restarting the interpreter causes UB on 3.10.0a4
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue42882>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42015] Order of decrementing reference counts in meth_dealloc
Yannick Jadoul added the comment: Yes, sorry for the delay; I got caught up in something else. Meanwhile, https://github.com/python/cpython/pull/22670 should solve our issues. I think Henry confirmed this locally? -- ___ Python tracker <https://bugs.python.org/issue42015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42015] Order of decrementing reference counts in meth_dealloc
Change by Yannick Jadoul : -- keywords: +patch pull_requests: +21643 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22670 ___ Python tracker <https://bugs.python.org/issue42015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42015] Order of decrementing reference counts in meth_dealloc
New submission from Yannick Jadoul : In Python 3.9, the line `Py_XDECREF(PyCFunction_GET_CLASS(m));` was added to `meth_dealloc` (in `methodobject.c`). Unfortunately for pybind11, it's inserted exactly two lines too low, since it accesses the `PyMethodDef` and we store the `PyMethodDef` instance in the capsule that's used as `self`-argument of the `PyCFunction`. Result: UB, since `Py_XDECREF(m->m_self);` brings down the refcount of the capsule to 0 and (indirectly) frees the `PyMethodDef`, while its contents are now still accessed. >From the pybind11 perspective, it would be optimal if this could be fixed in >CPython itself, by moving up this one `Py_XDECREF` 2 lines. This would a) be >more efficient than creating a workaround, and b) allow old, existing versions >of pybind11 to work with Python 3.9 (well, 3.9.1, then, hopefully); the user >base of pybind11 has grown quite a bit and now includes giants like scipy or >some Google libraries. I will make a PR implementing this, soon. If there's a different, recommended way of creating these `PyCFunctionObject`s dynamically and cleaning up the `PyMethodDef`, we'd be interested as well, to make sure these kinds of breakages are avoided in the future. Apologies for only figuring out now how to debug this, using valgrind. Up until yesterday, we only saw some failures in CI on macOS, but it was hard to reproduce and debug locally. - Related issue: https://bugs.python.org/issue41237 - pybind11 issue: https://github.com/pybind/pybind11/issues/2558 - pybind11 PR: https://github.com/pybind/pybind11/pull/2576 -- components: C API, Interpreter Core messages: 378500 nosy: YannickJadoul priority: normal severity: normal status: open title: Order of decrementing reference counts in meth_dealloc type: crash versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41980] Argparse documentation is slightly misleading
Yannick Gingras added the comment: Raymond, I would love to submit the PR if we reach a consensus on what the new message should be. I'm a bit out of touch with how things work these days. Is Github the best place to submit the PR? Paul, very good digging! Reading the coding and running a few examples, I understand that the ``prog`` of the subparser is always the name of the main program with the name of the subcommand *unless* a usage string is supplied, in which case it overrides prog. I suspect that the intent is to favour the programmer supplied usage string and that copying the usage string in the prog of the subparser is an implementation detail. I think we can reword the documentation to describe the expected behavior with more emphasis on the common cases. -- ___ Python tracker <https://bugs.python.org/issue41980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41980] Argparse documentation is slightly misleading
New submission from Yannick Gingras : In argparse.rst, while documenting ArgumentParser.add_subparsers, ``prog`` is described on line 1630 as: usage information that will be displayed with sub-command help, by default the name of the program and any positional arguments before the subparser argument This is confusing since ``prog`` is actually a very small prefix of the usage message. Describing this parameter as "name of the program" or event "name of the program with sub-commands" would be more clear. -- components: Library (Lib) messages: 378316 nosy: ygingras priority: normal severity: normal status: open title: Argparse documentation is slightly misleading versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue41980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39109] [C-API] PyUnicode_FromString
New submission from Yannick : Python version: 3.5 Tested with VS Studio 2017 in an C-API extension. When you have a UTF-8 encoded char buffer which is filled with a 0 or empty, and you youse the PyUnicode_FromString() method on this buffer, you will get a PyObject*. The content looks good, but the refence counter looks strange. In case of an 0 as char in the buffer, the ob_refcnt Field is set to 100 and in case of an empty buffer, the ob_refcnt Field is set to something around 9xx. Example Code: string s1 = u8""; string s2 = u8"0"; PyObject *o1 = PyUnicode_FromString(s1.c_str()); //o1->ob_refcnt = 9xx PyObject *o2 = PyUnicode_FromString(s2.c_str()); //o2->ob_refcnt = 100 I think the ob_refcnt Field should be 1 in both cases. Or why is the refcnt here so high? -- components: C API messages: 358706 nosy: YannickSchmetz priority: normal severity: normal status: open title: [C-API] PyUnicode_FromString type: behavior versions: Python 3.5 ___ Python tracker <https://bugs.python.org/issue39109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28380] Mock functions with autospec don't support assert_called_once, assert_called, assert_not_called
New submission from Yannick Brehon: If one defines a mock for a function, using autospec=True, then the mock will correctly support assert_called_once_with(), among others, but not assert_called_once, assert_called, and assert_not_called. The attached file contains a fix for the issue. -- components: Library (Lib) files: fix_autospecced_mock_functions.patch keywords: patch messages: 278208 nosy: Yannick Brehon priority: normal severity: normal status: open title: Mock functions with autospec don't support assert_called_once, assert_called, assert_not_called type: behavior versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file44991/fix_autospecced_mock_functions.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26210] `HTMLParser.handle_data` may be invoked although `HTMLParser.reset` was invoked
Yannick Duchêne added the comment: The documentation says: > Reset the instance. Loses all unprocessed data. How can parsing go ahead with all unprocessed data lost? This is the “Loses all unprocessed data” which made me believe it is to stop it. May be the documentation is unclear. By the way, if `reset` does not stop the parser, then a `stop` method is missing. I searched for it, and as there was nothing else and could not imagine the parser cannot be stopped, I though `reset` is the way to stop it. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26211] HTMLParser: “AssertionError: we should not get here!”
Yannick Duchêne added the comment: `reset` is called to stop the parser. If really `reset` should not be called during parser hooks execution, then the documentation should says so and an error should be raised when `reset` is invoked. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26210] `HTMLParser.handle_data` may be invoked although `HTMLParser.reset` was invoked
Yannick Duchêne added the comment: Thanks Xiang, for the clear explanations. So an error should be triggered when `reset` is invoked while it should not. And remains the issue about how to stop the parser: should an exception be raised and caught at an outer invocation level? Something like raising StopIteration? (I don't enjoy using exceptions for flow control, but that seems to be the Python way, cheese). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26210] `HTMLParser.handle_data` may be invoked although `HTMLParser.reset` was invoked
Yannick Duchêne added the comment: > And I don't see how to stop the process either. I just did it with `raise StopIteration`, caught at a proper place (in the procedure which invokes `feed` and `close`), and it seems to be fine, I have no more strange behaviours. At least, I cannot see a cleaner way. Now `reset` is invoked after end of parsing only (thus to be able to have a next round). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26211] HTMLParser: “AssertionError: we should not get here!”
Yannick Duchêne added the comment: I'm closing this issue, as the the issue http://bugs.python.org/issue26210 is the real one and this one seems to be a variant of the former. -- status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26210] `HTMLParser.handle_data` may be invoked although `HTMLParser.reset` was invoked
Changes by Yannick Duchêne <yannick_duch...@yahoo.fr>: -- nosy: +ezio.melotti ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26210] `HTMLParser.handle_data` may be invoked although `HTMLParser.reset` was invoked
New submission from Yannick Duchêne: `HTMLParser.handle_data` may be invoked although `HTMLParser.reset` was invoked. This occurs at least when `HTMLParser.reset` was invoked during `HTMLParser.handle_endtag`. According to the documentation, `HTMLParser.reset` discard all data, so it should immediately stop the parser. Additionally as an aside, it's strange `HTMLParser.reset` is invoked during object creation as it's invoking a method on an object which is potentially not entirely initialized (that matters with derived classes). -- components: Library (Lib) messages: 258973 nosy: Hibou57 priority: normal severity: normal status: open title: `HTMLParser.handle_data` may be invoked although `HTMLParser.reset` was invoked versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26211] HTMLParser: “AssertionError: we should not get here!”
New submission from Yannick Duchêne:
Using HTMLParser on the attached file, I got this:
File "/usr/lib/python3.5/html/parser.py", line 111, in feed
self.goahead(0)
File "/usr/lib/python3.5/html/parser.py", line 171, in goahead
k = self.parse_starttag(i)
File "/usr/lib/python3.5/html/parser.py", line 303, in parse_starttag
endpos = self.check_for_whole_start_tag(i)
File "/usr/lib/python3.5/html/parser.py", line 383, in
check_for_whole_start_tag
raise AssertionError("we should not get here!")
AssertionError: we should not get here!
The file purposely contains an error, as I was to check the behaviour of my
application in the case of this error … I finally triggered one in the library
:-P
--
components: Library (Lib)
files: sample.html
messages: 258975
nosy: Hibou57
priority: normal
severity: normal
status: open
title: HTMLParser: “AssertionError: we should not get here!”
versions: Python 3.5
Added file: http://bugs.python.org/file41721/sample.html
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26211>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26205] Inconsistency concerning nested scopes
Yannick Duchêne added the comment: Better at least two, if I'm not wrong: the innermost scope may be the module's scope. So there is always at least the module scope and the built‑ins scope, at least two up to four. (if I have not overlooked something) -- nosy: +Hibou57 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22011] “make test” fails with 3.4.1 on Ubuntu 12.04
New submission from Yannick Duchêne: `make test` fails with Python 3.4.1 on Ubuntu 12.04 Intel 32 bits. The single `./configure` option used, was `--prefix=$HOME/.local`. As attached file, an archive containing both standard output and standard error outputs. Not some important error notifications appears only in standard output, not in standard error: “OSError: [Errno 28] No space left on device”. The latter is surprising as there was 11GiB free space. -- components: Build files: test-logs.tar.gz messages: 223468 nosy: Hibou57 priority: normal severity: normal status: open title: “make test” fails with 3.4.1 on Ubuntu 12.04 versions: Python 3.4 Added file: http://bugs.python.org/file35996/test-logs.tar.gz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22011 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2204] document ConfigParser behaviour when a file has same section multiple times
Yannick Gingras yging...@ygingras.net added the comment: The attached patch is a proof of concept for throwing an exception. As discussed on the mailing list [1], it has some shortcomings that should be addressed before it is merged. [1]: http://mail.python.org/pipermail/python-dev/2009- -- keywords: +patch nosy: +ygingras Added file: http://bugs.python.org/file12938/no-dups-configparser.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2204 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2920] Patch to print symbolic value or errno in EnvironmentError.__str__()
New submission from Yannick Gingras [EMAIL PROTECTED]: EnvironmentError and its subclass OSError add the value of errno in their error message. This value is an integer but the specific value in an implementation detail and the C runtime recommends that programmers use the symbolic values instead. Ex: one should use ENODATA instead of 61. For the same reason, the Python interpreter should try to return the symbolic value or errno when possible. The attached patch replaces errno in EnvironmentError.__str__() by its symbolic value when possible. -- components: Interpreter Core files: python-26-sympolic-errno.diff keywords: patch messages: 67074 nosy: ygingras severity: normal status: open title: Patch to print symbolic value or errno in EnvironmentError.__str__() versions: Python 2.6 Added file: http://bugs.python.org/file10377/python-26-sympolic-errno.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2920 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
