[issue46781] Tracing: c_return doesn't report the result
Matthias Urlichs added the comment: Added a github PR. Unfortunately it breaks the cprofile testcase, which apparently relies on the old argument value (for no good reason IMHO). I don't know how the profiler works internally. If somebody who does could have a look at it and/or its testcase I'd be grateful. -- ___ Python tracker <https://bugs.python.org/issue46781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46781] Tracing: c_return doesn't report the result
Change by Matthias Urlichs : -- keywords: +patch pull_requests: +29537 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31393 ___ Python tracker <https://bugs.python.org/issue46781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46781] Tracing: c_return doesn't report the result
Matthias Urlichs added the comment: Likewise for c_exception, which should report the exception thruple -- and even has an XXX comment reminding us to fix that (ceval.c 4542). -- ___ Python tracker <https://bugs.python.org/issue46781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46781] Tracing: c_return doesn't report the result
New submission from Matthias Urlichs : When tracing/profiling, the "return" event reports the value returned by the exiting function. However, this does not work for C functions. The profiler's "c_return" hook is called with the same C function object as "c_call". This unnecessarily complicates debugging and should be fixed. https://stackoverflow.com/questions/61067303/get-return-value-of-python-builtin-functions-while-tracing -- components: C API messages: 413421 nosy: smurfix priority: normal severity: normal status: open title: Tracing: c_return doesn't report the result type: enhancement versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44219] Opening a file holds the GIL when it calls "isatty()"
Matthias Urlichs added the comment: Please do. However, I do think that changing the stdstream related ioctl calls also is a good idea, if only for code regularity/completeness sake. (Besides, nothing prevents somebody from starting a FUSE file system and then redirecting stdout to it …) -- ___ Python tracker <https://bugs.python.org/issue44219> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44219] Opening a file holds the GIL when it calls "isatty()"
New submission from Matthias Urlichs : Opening a file calls `isatty` which calls an ioctl with the GIL held. GDB: ``` #0 __GI___tcgetattr (fd=18, termios_p=termios_p@entry=0x7f618a5df920) at ../sysdeps/unix/sysv/linux/tcgetattr.c:38 #1 0x7f618bd1ca0c in __isatty (fd=) at ../sysdeps/posix/isatty.c:27 #2 0x0062b746 in _Py_device_encoding (fd=) at ../Python/fileutils.c:62 #3 0x0060bf90 in _io_TextIOWrapper___init___impl (write_through=0, line_buffering=0, newline=0x0, errors='strict', encoding=, buffer=<_io.BufferedWriter at remote 0x7f618986aeb0>, self=0x7f618985a860) at ../Modules/_io/textio.c:1149 ... ``` Please don't do that. In my case, the file in question is implemented as a FUSE mount which is served by the same process (different thread of course). Thus holding the GIL at this point causes a rather interesting deadlock. Tested with 3.9. -- components: Interpreter Core messages: 394208 nosy: smurfix priority: normal severity: normal status: open title: Opening a file holds the GIL when it calls "isatty()" type: crash versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44219> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43744] enum: Adding a member named _classname__ raises IndexError
Change by Matthias Urlichs : -- title: enum: Adding a member named _anything__ raises IndexError -> enum: Adding a member named _classname__ raises IndexError ___ Python tracker <https://bugs.python.org/issue43744> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43744] enum: Adding a member named _anything__ raises IndexError
Change by Matthias Urlichs : -- title: enum: Adding a var named _anything__ raises IndexError -> enum: Adding a member named _anything__ raises IndexError ___ Python tracker <https://bugs.python.org/issue43744> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43744] enum: Adding a var named _anything__ raises IndexError
New submission from Matthias Urlichs : While checking out the Enum implementation I noticed that this code snippet results in an IndexError. I have no idea which error or warning (if any) this should generate instead. Opinions? import enum class duh(enum.Enum): _duh__ = "moo" -- components: Library (Lib) messages: 390301 nosy: smurfix priority: normal severity: normal status: open title: enum: Adding a var named _anything__ raises IndexError type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43744> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20504] cgi.FieldStorage, multipart, missing Content-Length
Change by Matthias Urlichs : -- versions: +Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue20504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20504] cgi.FieldStorage, multipart, missing Content-Length
Matthias Urlichs added the comment: Owch, yeah, this fell off the radar. Anyway, I've signed the CLA, so if somebody could finish and apply this I'd be grateful. Myself, I unfortunately don't have the time. -- ___ Python tracker <https://bugs.python.org/issue20504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33242] Support binary symbol names
Matthias Urlichs <sm...@smurf.noris.de> added the comment: Well, the original problem remains: symbol names aren't constrained to UTF-8 … so if I happen to stumble onto one of those (maybe generated by a code obfuscator), the answer is "don't use Python3 then"? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33242] Support binary symbol names
New submission from Matthias Urlichs <sm...@smurf.noris.de>:
ctypes should support binary symbols.
Rationale: There's no requirement that the symbol name in question is encoded
as ASCII or UTF-8.
>>> import ctypes
>>> t = type('iface', (ctypes.Structure,), {'_fields_': [(b'c_string_symbol',
>>> ctypes.CFUNCTYPE(ctypes.c_uint32))]})
Traceback (most recent call last):
File "", line 1, in
TypeError: '_fields_' must be a sequence of (name, C type) pairs
--
components: ctypes
messages: 315096
nosy: smurfix
priority: normal
severity: normal
status: open
title: Support binary symbol names
type: enhancement
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33242>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32850] Run gc_collect() before complaining about dangling threads
Matthias Urlichs <sm...@smurf.noris.de> added the comment: > It's a deliberate choice. It helped me to find real bugs. For example, I > found a very old reference cycle in socket.create_connection(). Fair enough; I will change the patch to complain before gc'ing. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32850] Run gc_collect() before complaining about dangling threads
Matthias Urlichs <sm...@smurf.noris.de> added the comment: Apparently this patch has not been applied yet. Is there a reason for that, besides "it's obviously correct so there must be something wrong with it"? ;-) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32900] Teach pdb to step through asyncio et al.
Matthias Urlichs <sm...@smurf.noris.de> added the comment: Ah. Thank you for pointing me to that feature, I completely missed it. The proposed enhancement thus boils down to "implement a couple of pdb commands to display and modify this skip list". I'm +1 on keeping the default empty. When you're already in the debugger, mired in the guts of an intractable bug, restarting it all just to set up a skip list isn't sufficient. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32900] Teach pdb to step through asyncio et al.
Matthias Urlichs <sm...@smurf.noris.de> added the comment: *Sigh*. ... if you need Python 3.5 compatibility ... obviously. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32900] Teach pdb to step through asyncio et al.
Matthias Urlichs <sm...@smurf.noris.de> added the comment:
"Example of a problem"? Well, just single-step into, and then back out of, an
@asynccontextmanager-decorated function.
@asynccontextmanager
async def gen():
yield 1234
async def foo():
import pdb;pdb.set_trace()
async with gen() as x:
assert x == 1234
print("done")
trio.run(foo)
# asyncio.get_event_loop().run_until_complete(foo())
Let's assume that you want to single step through that context manager. Now
count how often you need to press "s" until you arrive at the print statement.
With my patch it's 7. Without the patch there are 30 additional steps within
the asynccontextmanager. If you need Python 3.6 compatibility and also use
@async_generator you need to hit Return ~130 times. That's way too much.
Or: let's say you want to step across an await statement that actually goes
through a context switch. You hit "n" and see a . With something like
my patch, and assuming there's no other context to switch to, hitting "s" gets
you back to the current context.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32900>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32900] Teach pdb to step through asyncio et al.
Matthias Urlichs <sm...@smurf.noris.de> added the comment: File attachment failed, retrying … -- keywords: +patch Added file: https://bugs.python.org/file47456/pdb.diff ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32900] Teach pdb to step through asyncio et al.
New submission from Matthias Urlichs <sm...@smurf.noris.de>: The attached patch is a proof-of-concept implementation of a way to teach pdb to "single-step" through non-interesting code that you can't skip with "n". The prime example for this is asyncio, trio et al., though decorators like @contextlib.contextmanager also benefit. A "real" implementation should allow the user to specify ranges to ignore, on the pdb command line (probably by filename and optional range of line numbers, instead of pattern matching). A visual indication of how much code has been skipped-ahead that way might also be beneficial. -- components: asyncio messages: 312509 nosy: asvetlov, giampaolo.rodola, njs, smurfix, yselivanov priority: normal severity: normal status: open title: Teach pdb to step through asyncio et al. type: enhancement ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32850] Run gc_collect() before complaining about dangling threads
Matthias Urlichs <sm...@smurf.noris.de> added the comment: Upon further consideration (and following the observation that my test cases no longer block for two seconds each after applying the first version of this patch): we do not want to clear the reference to "dangling_threads" since that's a weakset. We want to clear the "thread" variable, which holds a reference to a random member of that set, which will arbitrarily block the cleanup loop from ever succeeding. Updated patch attached. -- Added file: https://bugs.python.org/file47446/gc.patch ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32850] Run gc_collect() before complaining about dangling threads
New submission from Matthias Urlichs <sm...@smurf.noris.de>: Lib/test/support/__init__.py::threading_cleanup() complains about dangling threads even if the reference in question would be cleaned up by the garbage collector. This is not useful, esp. when the list of referrers to the "dangling" thread looks like this: [, , ] Thus I propose to check, run gc, check again, and only *then* complain-and-wait. Hence the attached patch for your consideration. -- components: Tests files: gc.patch keywords: patch messages: 312206 nosy: smurfix priority: normal severity: normal status: open title: Run gc_collect() before complaining about dangling threads type: resource usage versions: Python 3.7 Added file: https://bugs.python.org/file47445/gc.patch ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26789] Please do not log during shutdown
New submission from Matthias Urlichs: … or, if you do, ignore errors. This is during program shutdown. Unfortunately, I am unable to create a trivial example which exhibits the order of destruction necessary to trigger this problem. Traceback (most recent call last): File "/usr/lib/python3.5/asyncio/tasks.py", line 93, in __del__ File "/usr/lib/python3.5/asyncio/base_events.py", line 1160, in call_exception_handler File "/usr/lib/python3.5/logging/__init__.py", line 1308, in error File "/usr/lib/python3.5/logging/__init__.py", line 1415, in _log File "/usr/lib/python3.5/logging/__init__.py", line 1425, in handle File "/usr/lib/python3.5/logging/__init__.py", line 1487, in callHandlers File "/usr/lib/python3.5/logging/__init__.py", line 855, in handle File "/usr/lib/python3.5/logging/__init__.py", line 1047, in emit File "/usr/lib/python3.5/logging/__init__.py", line 1037, in _open NameError: name 'open' is not defined -- components: asyncio messages: 263612 nosy: gvanrossum, haypo, smurfix, yselivanov priority: normal severity: normal status: open title: Please do not log during shutdown type: behavior versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2786] Names in traceback should have class names, if they're methods
Matthias Urlichs added the comment: Please do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2786 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20504] cgi.FieldStorage, multipart, missing Content-Length
Matthias Urlichs added the comment:
Actually, the problem is cgi.py around line 550:
clen = -1
if 'content-length' in self.headers:
try:
clen = int(self.headers['content-length'])
except ValueError:
pass
if maxlen and clen maxlen:
raise ValueError('Maximum content length exceeded')
self.length = clen
if self.limit is None and clen:
self.limit = clen
… so self.limit ends up being -1 instead of None. :-/
Somebody please change this test to
if self.limit is None and clen = 0:
--
nosy: +smurfix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20504
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20504] cgi.FieldStorage, multipart, missing Content-Length
Matthias Urlichs added the comment: Patch attached. -- keywords: +patch Added file: http://bugs.python.org/file35551/cgi.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20504 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20504] cgi.FieldStorage, multipart, missing Content-Length
Matthias Urlichs added the comment: This also applies to 3.4 and 3.5. -- versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20504 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21705] cgi.py: Multipart with more than one file is misparsed
New submission from Matthias Urlichs: This code in cgi.py makes no sense whatsoever: 842 if line.endswith(b--) and last_line_lfend: 843 strippedline = line.strip() 844 if strippedline == next_boundary: 845 break 846 if strippedline == last_boundary: 847 self.done = 1 848 break (Pdb) p next_boundary b'--testdata' (Pdb) p last_boundary b'--testdata--' (Pdb) The net effect of this is that parsing a multipart with more than one file in it is impossible, as the first file's reader will gobble up the remainder of the input. Patch attached. I guess it's a safe bet that no sane person even uses cgi.py any more, otherwise this would have been discovered a bit sooner. -- components: Library (Lib) files: cgi.patch2 messages: 220164 nosy: smurfix priority: normal severity: normal status: open title: cgi.py: Multipart with more than one file is misparsed type: behavior versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35552/cgi.patch2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21705 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21306] PEP 466: backport hmac.compare_digest
Matthias Urlichs added the comment: Currently (Debian's 2.7.7-rc1 package) hmac.compare_digest accepts two bytestring arguments, or two Unicode stings, but not one bytestring and one unicode. I don't think that's a good idea. -- nosy: +smurfix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2722] os.getcwd fails for long path names on linux
Matthias Urlichs [EMAIL PROTECTED] added the comment: MAX_PATH is a compile time constant which, like FD_BITS for select(), may be too small for the system you're ultimately running on. Using that as default initial size is OK, but handling ERANGE is still a very good idea. -- nosy: +smurfix __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2722 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2786] Names in traceback should have class names, if they're methods
New submission from Matthias Urlichs [EMAIL PROTECTED]: Consider this simple error: class foo(object): ... def __init__(self,bar): ...pass ... foo() Traceback (most recent call last): File stdin, line 1, in module TypeError: __init__() takes exactly 2 positional arguments (1 given) The problem is that if that foo call is through a variable (or anything else that obscures which class I'm actually calling) there's no good way to figure this from the traceback. The last line should read TypeError: foo.__init__() takes exactly 2 positional arguments (1 given) or similar. -- messages: 66373 nosy: smurfix severity: normal status: open title: Names in traceback should have class names, if they're methods type: behavior __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2786 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
