Debug build CI job crashes on `stats._unuran` threading test
See original GitHub issueObserved in gh-14962 (unrelated PR). Details from the CI log:
sx...................................................................... [ 99%]
......................[gw0] node down: Not properly terminated
F
replacing crashed worker gw0
........................................................ss...ssssssssss. [ 99%]
.s...........................sssssssssssssssssssssssssssssssssssssssssss [ 99%]
ssssssssssssssssys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name=0 mode='r' encoding='UTF-8'>
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name=0 mode='r' encoding='UTF-8'>
=================================== FAILURES ===================================
_ build/testenv/lib/python3.8/site-packages/scipy/stats/tests/test_sampling.py _
[gw0] linux -- Python 3.8.0 /usr/bin/python3.8-dbg
worker 'gw0' crashed while running 'build/testenv/lib/python3.8/site-packages/scipy/stats/tests/test_sampling.py::test_threading_behaviour'
Likely a bug (threading behavior is something that could indeed cause this segfault), but it’s not happening on other PRs. Let’s just see if it happens again.
This test came in in commit 402ac3535b8c (main PR that added UNU.RAN, Cc @tirthasheshpatel).
Issue Analytics
- State:
- Created 2 years ago
- Comments:9 (9 by maintainers)
Top Results From Across the Web
c++ - Program only crashes as release build -- how to debug?
Through caveman debugging (ie, nasty printf() messages all over the place), I have determined the test method where the code is crashing, though ......
Read more >SciPy 1.8.0 Release Notes — SciPy v1.9.3 Manual
It contains many new features, numerous bug-fixes, improved test coverage and ... #14968: Debug build CI job crashes on `stats._unuran` threading test.
Read more >When C extensions crash: easier debugging for your Python ...
If your Python test suite segfaults in C code, debugging is difficult. But an easy configuration tweak can help you pinpoint the responsible ......
Read more >Diagnosing Native Crashes | Android Open Source Project
The following sections include common types of native crash, an analysis of a sample crash dump, and a discussion of tombstones.
Read more >Debug Android Crashes Faster With Datadog
You can also build crash reports using Datadog's RUM error dashboard in order to view all crashes or non-fatal errors at a glance,...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Hi @rgommers,
I noticed that I was still sometimes getting attribute lookup errors. I think this is happening because Cython looks up the class attributes to find the
release
method of the_lock
variable when I call_lock.release()
. At least, that’s what the generated C code says:Although the
_lock
variable is not destroyed, python doesn’t allow ANY attribute lookups when a live exception is set. The workaround is to fetch the error before calling_lock.release()
and restore the error once the lock has been released:I tried this and reran my experiment 100,000 times. It doesn’t give me an attribute lookup error anymore and I am confident this would resolve the issue.
Sorry for not noticing this before #15331 was merged! I will reopen this issue and submit another PR. At some point, it will be better to rewrite the base class in C.
This happened once more (log), again on the
Python38-dbg
job. Output:The crash seems to occur very infrequently.