https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
Victor Stinner changed:
What|Removed |Added
Flags|maintainer-feedback?(victor |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #19 from Kubilay Kocak ---
(In reply to Victor Stinner from comment #17)
Thank you for the feedback Victor. Does this also mean (in your opinion) that
carrying local patches for these commits in FreeBSD Ports is not a wise
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #18 from yocal...@gmail.com ---
(In reply to Victor Stinner from comment #17)
Thanks for the tips and the links to your notes. However, the panics are still
happening on py3.9.4. Unfortunately, I've analyzed 11 core dumps at
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #17 from Victor Stinner ---
Backporting "bpo-19466: Py_Finalize() clears daemon threads earlier (GH-18848)"
sounds dangerous. This fix relies on many other fixes. Without the other fixes,
clearing daemon threads earlier can
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #16 from Victor Stinner ---
I can reproduce the issue with Python 3.8 on Linux.
Well, first, don't rely on implicit resource management: don't rely on
__del__() destructor.
You should use "with pool:" and then call
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #15 from yocal...@gmail.com ---
(In reply to Victor Stinner from comment #14)
Hi Victor, thanks for testing it out. Your results are expected since the 2
commits that fix the problem were included with python3.9. Have you
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #14 from Victor Stinner ---
Using the script of Comment 2, I cannot reproduce the hang with Python 3.9.4 on
FreeBSD 13. I used:
for i in $(seq 1 100); do python3.9 script.py || break; done
--
You are receiving this mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #13 from yocal...@gmail.com ---
Maybe some progressnot sure but I'm cautiously optimistic.
I analyzed 7 core dumps again to see if I spotted anything interesting. 6 of
them were py3.8 and 1 was py3.9.
100% of them have a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
Kai Knoblich changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment #12
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #11 from yocal...@gmail.com ---
Update on the matter. I was able to analyze a python3.9.4 core dump and I've
narrowed the fact down that the thread on CPU that crashed is in
concurrent.future._base.Executor class.
Core was
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #10 from yocal...@gmail.com ---
(In reply to Kubilay Kocak from comment #8)
I was quite surprised at the regression with py3.8 as well. But that was before
I started looking at some of the changes from py3.7 to 3.8. Some of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #9 from yocal...@gmail.com ---
(In reply to Kubilay Kocak from comment #7)
Hi Kubilay, thanks for adding Victor Stinner to this. Victor will more than
likely be able to give a more definitive reason on why those 2 commits did
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
Kubilay Kocak changed:
What|Removed |Added
CC||victor.stin...@gmail.com
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #8 from Kubilay Kocak ---
(In reply to yocal...@gmail.com from comment #6)
I run FreeBSD 12.x and CURRENT for upstream Cpython, which tests all non EoL
branches (latest-and-back-2-versions), so I'm surprised with this report.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #7 from Kubilay Kocak ---
(In reply to yocal...@gmail.com from comment #4)
Upstream has a latest minor and back 2 minors merge policy. If you can identify
the issues and/or PR's associated with those two missing merge commits,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #6 from yocal...@gmail.com ---
(In reply to Li-Wen Hsu from comment #5)
Unfortunately, I'm not sure why they did not include the threading patch in
python 3.8. I suspect because the use-case is relatively small (daemon=True
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #5 from Li-Wen Hsu ---
(In reply to yocal...@gmail.com from comment #4)
Thanks for the numbers and it sounds we should have those patches included. Do
you think you can ask if they also want to backport to 3.8, or do you mean
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #4 from yocal...@gmail.com ---
(In reply to Li-Wen Hsu from comment #3)
Upstream python 3.9 includes these patches by default already, they were never
backported to 3.8. I'm fairly confident there are no regressions because:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #3 from Li-Wen Hsu ---
(In reply to yocal...@gmail.com from comment #2)
> Running that 52 times caused an indefinite hang ~19.2% of the time. After
> cherry-picking the 2 commits I linked above, I confirmed that it resolved
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Comment #2 from yocal...@gmail.com ---
(In reply to Li-Wen Hsu from comment #1)
Hi Li-Wen Hsu, thanks for the feedback. I will definitely use stock GENERIC
freeBSD 12.2 kernel. The hard part is instrumenting a program that causes the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
Li-Wen Hsu changed:
What|Removed |Added
CC||lw...@freebsd.org
Bugzilla Automation has asked freebsd-python (Nobody)
for maintainer-feedback:
Bug 255445: lang/python 3.8/3.9 SIGSEV core dumps in libthr TrueNAS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
--- Description ---
Seeing many TrueNAS (previously FreeNAS) users dump core on the main
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445
Bug ID: 255445
Summary: lang/python 3.8/3.9 SIGSEV core dumps in libthr
TrueNAS
Product: Ports & Packages
Version: Latest
Hardware: amd64
OS: Any
23 matches
Mail list logo
