Date: Thu, 29 Apr 2021 18:03:25 +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-whZ5DF3hXy@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/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255445 --- Comment #13 from yocalebo@gmail.com <yocalebo@gmail.com> --- Maybe some progress....not 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 common pattern. The threads *tstate has lxml.etree._ParserDictionaryContext in the frames. Either the thread that was on CPU when it core dumped or some other thread. Since this is seemingly memory corruption, lxml has become my suspect since it uses it's own C bindings for the libxml2 and libxslt libraries. I've instrumented a somewhat complicated script that daemonizes, creates a concurrent.futures._base.Executor class and calls methods that use lxml library to parse geom xml information in a while true loop. Am I looking at a red herring?? Idk but this grabbed my attention so I'm running the script to see if it'll tickle the problem. Maybe the version of py-lxml we're using has a subtle issue with py3.8+. (Queue my overly dramatic rant about py3.8 changes to PyGC_Head struct.) -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-255445-21822-whZ5DF3hXy>