#18919 closed defect (fixed)
Interrupt in PARI's pari_malloc() hangs Sage
Reported by: | vbraun | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-6.8 |
Component: | interfaces | Keywords: | random_fail |
Cc: | jdemeyer | Merged in: | |
Authors: | Jeroen Demeyer | Reviewers: | Vincent Delecroix |
Report Upstream: | N/A | Work issues: | |
Branch: | f16032b (Commits, GitHub, GitLab) | Commit: | |
Dependencies: | Stopgaps: |
Description (last modified by )
This fails quite frequently:
sage: 0.binomial(1) ## line 6262 ## 0 sage: 0.binomial(-1) ## line 6264 ## 0 sage: 13.binomial(2r) ## line 6266 ## 78 sage: alarm(0.5); (2^100).binomial(2^22, algorithm='mpir') ## line 6271 ## sage: alarm(0.5); (2^100).binomial(2^22, algorithm='pari') ## line 6275 ## ********************************************************************** ---------------------------------------------------------------------- sage -t --long src/sage/rings/integer.pyx # Timed out (and interrupt failed) ----------------------------------------------------------------------
This is a consequence of a recent PARI upgrade, because malloc()
is used in a place where it wasn't used before. The cause is exactly the same as #16850.
For PARI, we should be able to fix this using PARI_SIGINT_block
which is like sig_block()
but for the PARI library.
Change History (9)
comment:1 Changed 7 years ago by
- Description modified (diff)
comment:2 Changed 7 years ago by
- Dependencies set to #18583
comment:3 Changed 7 years ago by
- Description modified (diff)
- Summary changed from random failure in integer.pyx interrupting pari to Interrupt in PARI's pari_malloc() hangs Sage
comment:4 Changed 7 years ago by
- Dependencies #18583 deleted
comment:5 Changed 7 years ago by
- Branch set to u/jdemeyer/interrupt_in_pari_s_pari_malloc___hangs_sage
comment:6 Changed 7 years ago by
- Commit set to f16032bad4ef8a9feeb2e3321b72b55555a32960
- Status changed from new to needs_review
New commits:
f16032b | Support PARI_SIGINT_block in interrupt framework
|
comment:7 follow-up: ↓ 9 Changed 7 years ago by
- Reviewers set to Vincent Delecroix
- Status changed from needs_review to positive_review
I am infinitely happy that you found out a solution for this annoying interrupt! Though, I do not like the fact that now the interrupt code depends explicitely on pari. In an ideal world, all this interrupt buisness should go in upstream Cython, don't you think? Do you have an idea whether it would be possible to have something modular for the interrupt code?
comment:8 Changed 7 years ago by
- Branch changed from u/jdemeyer/interrupt_in_pari_s_pari_malloc___hangs_sage to f16032bad4ef8a9feeb2e3321b72b55555a32960
- Resolution set to fixed
- Status changed from positive_review to closed
comment:9 in reply to: ↑ 7 Changed 4 years ago by
- Commit f16032bad4ef8a9feeb2e3321b72b55555a32960 deleted
Replying to vdelecroix:
Though, I do not like the fact that now the interrupt code depends explicitely on pari.
I understand your sentiment, but at least it fixes a bug which I don't know how to fix otherwise. You should also understand that I never claimed that cysignals is 100% bullet-proof. We try to fix most use cases but now and then something breaks (see #24986 for example).
In an ideal world, all this interrupt buisness should go in upstream Cython, don't you think?
Moving this to upstream Cython won't magically fix the PARI problem.
Besides, I don't think that there is much reason to push it to Cython now that we have cysignals.
It's the PARI library interface, so #10476 cannot be the cause. My bet would something in PARI itself.