Arcadiy Ivanov added the comment:
Seems like integrating third party dependencies would be covered by integration
tests as part of the automation. But if they are not available I understand it
would be expensive, yes.
--
___
Python tracker
Arcadiy Ivanov added the comment:
Wow, the artifacts are built and posted by hand???
--
___
Python tracker
<https://bugs.python.org/issue45079>
___
___
Pytho
Arcadiy Ivanov added the comment:
Nevermind. Looks like the policy is not to build binaries once in security
fixes only mode. I guess the build bot gets tired or something...
--
resolution: not a bug -> wont fix
___
Python tracker
<
New submission from Arcadiy Ivanov :
The following versions only contain tarballs with no Windows artifacts
available. Is the build system OK?
https://www.python.org/ftp/python/3.8.12/
https://www.python.org/ftp/python/3.8.11/
.10 is fine:
https://www.python.org/ftp/python/3.8.10/
Latest 3.9
Arcadiy Ivanov added the comment:
I guess I'll work around this, thanks.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Change by Arcadiy Ivanov :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue44007>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Arcadiy Ivanov :
$ ~/.pyenv/versions/3.8.6/bin/python3.8
Python 3.8.6 (default, Oct 8 2020, 13:32:06)
[GCC 10.2.1 20200723 (Red Hat 10.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>&g
Arcadiy Ivanov added the comment:
>From what I understand an RC1 is being released for 3.9. This is a gentle
>reminder that there is no fix for this yet.
--
___
Python tracker
<https://bugs.python.org/i
Arcadiy Ivanov added the comment:
Nevermind, `ast`/`_ast` is not pre-loaded by default, so it's in fact getting
GC'ed after the first `run_path` is executed.
--
___
Python tracker
<https://bugs.python.org/issue41
Arcadiy Ivanov added the comment:
> If sys.modules['_ast'] is cleared and then _ast is imported again,
> _PyState_AddModule() is called to store the new _ast module instance which
> calls astmodule_clear() on the old module instance.
I'm confused about this. In the re
Arcadiy Ivanov added the comment:
Yes, indeed, please, because I don't know what I would do for 3.9 if this is
not fixed. :D
--
___
Python tracker
<https://bugs.python.org/issue41
Change by Arcadiy Ivanov :
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue41261>
___
___
Python-bugs-list mailing list
Unsubscribe:
Arcadiy Ivanov added the comment:
$ PYTHONWARNINGS=ignore gdb --args
/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python
./repro.py
GNU gdb (GDB) Fedora 9.1-5.fc32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL
Arcadiy Ivanov added the comment:
This is in the 3.9 branch as of a0a6f1167834c87f12e2eca11dd77143103e7691
--
___
Python tracker
<https://bugs.python.org/issue41
New submission from Arcadiy Ivanov :
"Short" reproducer:
repro.py:
```
import sys
from os import getcwd, chdir
from runpy import run_path
def smoke_test(script, *args):
old_argv = list(sys.argv)
del sys.argv[:]
sys.argv.append(script)
sys.argv.extend(args)
o
Arcadiy Ivanov added the comment:
Ok, then. I'll open a new bug.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Arcadiy Ivanov added the comment:
$ PYTHONWARNINGS=ignore gdb --args
/home/arcivanov/Documents/src/arcivanov/pybuilder/target/venv/test/cpython-3.9.0.beta.4/bin/python
./repro.py
GNU gdb (GDB) Fedora 9.1-5.fc32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL
Arcadiy Ivanov added the comment:
"Short" reproducer:
repro.py:
```
import sys
from os import getcwd, chdir
from runpy import run_path
def smoke_test(script, *args):
old_argv = list(sys.argv)
del sys.argv[:]
sys.argv.append(script)
sys.argv.extend(args)
o
Arcadiy Ivanov added the comment:
I'm working on a short reproducer, but otherwise reproducer is exactly the same
as described in https://bugs.python.org/issue41194#msg372854
The way I bumped into this is trying to confirm the fix in Beta 4 (which
apparently didn't make it, as you mentioned
Arcadiy Ivanov added the comment:
@vstinner, this is in the current 3.9 as of
a0a6f1167834c87f12e2eca11dd77143103e7691 (11hrs ago). We didn't get the actual
bug, we just got stopped by an assertion when python got built with debug.
--
___
Python
Arcadiy Ivanov added the comment:
> Program received signal SIGSEGV, Segmentation fault.
0x00623339 in _Py_IS_TYPE (ob=0x0, type=0x8609e0 ) at
./Include/object.h:128
128 return ob->ob_type == type;
(gdb) py-bt
Traceback (most recent call first):
File "/hom
Arcadiy Ivanov added the comment:
Confirmed not fixed.
Taken with 3.9 branch as of today.
(pyb-3.9-dev-d) [arcivanov@ai-karellen-lap pybuilder]$ abrt gdb 1f24453
GNU gdb (GDB) Fedora 9.1-5.fc32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <h
Arcadiy Ivanov added the comment:
I'm reopening this as the original SEGV didn't go away in 3.9 beta 4. It looks
like debug build caught an assertion and prevented the SEGV from triggering.
--
resolution: fixed ->
status: closed ->
Change by Arcadiy Ivanov :
--
nosy: -Digital India
___
Python tracker
<https://bugs.python.org/issue41194>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Arcadiy Ivanov :
--
components: +Interpreter Core
type: -> crash
___
Python tracker
<https://bugs.python.org/issue41194>
___
___
Python-bugs-lis
Arcadiy Ivanov added the comment:
> old_modules = dict(sys.modules)
> sys.modules.clear()
> sys.modules.update(old_modules)
--
___
Python tracker
<https://bugs.python.or
Arcadiy Ivanov added the comment:
That's not an entirely accurate reproducer as the references to the modules are
still held in the collection when the sys.modules.clear() is called.
--
___
Python tracker
<https://bugs.python.org/issue41
Arcadiy Ivanov added the comment:
So as soon as I started using CPython 3.9.0b3 with debug, the stack trace
changed and the corruption apparently occurs in the GC, probably because the
assertion is triggered vs release-style build:
Modules/gcmodule.c:114: gc_decref: Assertion
Arcadiy Ivanov added the comment:
To complete this report, this is a regression. This exact code runs perfectly
in 2.7, 3.5 - 3.8.
This is the PR in Travis:
https://travis-ci.org/github/pybuilder/pybuilder/builds/704312142
--
___
Python tracker
Arcadiy Ivanov added the comment:
My guess is that the issue is related to the sys.modules manipulation, i.e.
these parts of the integration test harness:
def smoke_test(self, *args):
old_argv = list(sys.argv)
del sys.argv[:]
sys.argv.append(self.build_py
Arcadiy Ivanov added the comment:
How to reproduce:
1. Clone github.com/pybuilder/pybuilder
2. Checkout https://github.com/pybuilder/pybuilder/pull/724
3. Run `PYTHONWARNINGS=ignore python ./build.py -v -X`
The failure occurs in the integration test smoke test in smoke_clean_tests.py
Arcadiy Ivanov added the comment:
Once any of the integration tests run, the integration test environment is
created and the test can be run directly from the command line via:
'.../pybuilder/target/venv/test/cpython-3.9.0.beta.3/bin/python'
'.../pybuilder/src/integrationtest/python
Arcadiy Ivanov added the comment:
No C extensions, working on giving you a reproducer.
--
___
Python tracker
<https://bugs.python.org/issue41194>
___
___
Pytho
Arcadiy Ivanov added the comment:
I can say that it is always reproduced, both in Travis environment (Ubuntu) and
in Fedora.
--
___
Python tracker
<https://bugs.python.org/issue41
Arcadiy Ivanov added the comment:
I'm right now rerunning the script with debug-level build of CPython and will
report as soon as I have more data.
Any word on limits for attaching core dump?
--
___
Python tracker
<https://bugs.python.
Arcadiy Ivanov added the comment:
I can't seem to be able to attach a gziped coredump (7MB)
--
___
Python tracker
<https://bugs.python.org/issue41194>
___
___
New submission from Arcadiy Ivanov :
Built with pyenv on Fedora 32. Discovered while testing PyBuilder for 3.9
compatibility.
$ abrt gdb e6ad9db
GNU gdb (GDB) Fedora 9.1-5.fc32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.
Arcadiy Ivanov added the comment:
@vstinner
> I'm not sure that I understand the bug.
The bug is, if a user makes an error and passes a Queue from context 'fork' to
a child that is spawned using 'spawn', the passed Queue is, for obvious
reasons, broken.
The 'print("Child r_q: %r
Change by Arcadiy Ivanov :
Added file: https://bugs.python.org/file47933/coredump
___
Python tracker
<https://bugs.python.org/issue33196>
___
___
Python-bugs-list mailin
Arcadiy Ivanov added the comment:
@taleinat The above has been reproduced on Fedora 29.
--
___
Python tracker
<https://bugs.python.org/issue33196>
___
___
Pytho
Arcadiy Ivanov added the comment:
@gus.goulart you have reproduced it. The screenshot showing `-11` means the
process dumped core. Because it's the child that dumps core, it's masked by
abrt.
Observe:
$ python3 --version
Python 3.7.1
$ python3 ~/Downloads/test_lock_sigsegv.py
Parent r_q
New submission from Arcadiy Ivanov <arca...@ivanov.biz>:
While working on GH gevent/gevent#993 I've encountered a stall trying to read
from an mp.Queue passed to mp.Process's target as an argument. Trying to print
out the lock state in child process I encountered as SEGV in Lock's __rep
Arcadiy Ivanov <arca...@ivanov.biz> added the comment:
Sorry about that! I'll be sure to refresh next time before posting a reply.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Arcadiy Ivanov <arca...@ivanov.biz> added the comment:
> Although general-purpose mechanism that would allow pluggable constructs like
> `sh`, `html`, `sql`
Strike that one, I didn't read into PEP-0501 deep enough before replying.
Yes, `i"format"` is
Arcadiy Ivanov <arca...@ivanov.biz> added the comment:
@eric.smith
Thanks! I was looking for such a general-purpose proposal but could not find
it.
Although general-purpose mechanism that would allow pluggable constructs like
`sh`, `html`, `sql` and the like is awesome and very des
Arcadiy Ivanov <arca...@ivanov.biz> added the comment:
@serhiy.storchaka Of course a similar pattern can be implemented via a class
(or even without one as I've shown below).
But you can clearly notice that in your example:
1) There are tons of boilerplate (as in mine with lambdas).
2
Arcadiy Ivanov <arca...@ivanov.biz> added the comment:
As an example this is the current state of affairs:
>>> def x():
... foo = "foo"
... s1 = f"S1 value {foo}"
... s2 = f"S2 value {s1}"
... print(s2)
...
>>> dis.d
New submission from Arcadiy Ivanov <arca...@ivanov.biz>:
I'd like to start a discussion on/gauge interest for introducing an enhancement
to PEP-498 in a form of delayed/lazy/lambda f-string.
The proposed change is, conceptually, minor and would not differ from PEP-498
syntactically
Arcadiy Ivanov added the comment:
gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
Fedora 25
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Arcadiy Ivanov:
Around line 1480 of configure.ac:
if test "$Py_DEBUG" = 'true' ; then
# Optimization messes up debuggers, so turn it off for
# debug builds.
if "$CC" -v --help 2>/dev/null |
50 matches
Mail list logo
