Date: Tue, 27 Apr 2021 19:22:03 +0000 From: bugzilla-noreply@freebsd.org To: python@FreeBSD.org Subject: [Bug 255445] lang/python 3.8/3.9 SIGSEV core dumps in libthr TrueNAS Message-ID: <bug-255445-21822-RMBZePUsqU@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-255445-21822@https.bugs.freebsd.org/bugzilla/> References: <bug-255445-21822@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255445 --- Comment #2 from yocalebo@gmail.com <yocalebo@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 t= he SIGSEV :(. I can, however, confirm that stock 12.2 has a regression with threads on py3.8.7. You can use this script to test it. from multiprocessing.pool import ThreadPool from datetime import datetime class Broken(object): def __init__(self): self.pool =3D ThreadPool() def __del__(self): self.pool.close() self.pool.join() ohno =3D Broken() date =3D datetime.now() print(str(date), ohno) 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 t= he "hangs". It never did reproduce a core dump. Anyways, I'll keep trying to write a program that tickles the problem. If y= ou or anyone has any ideas reading this, I'm all ears at this point and will happily try anything at this point :) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-255445-21822-RMBZePUsqU>