#18919 closed defect (fixed)
Interrupt in PARI's pari_malloc() hangs Sage
Reported by:  vbraun  Owned by:  

Priority:  major  Milestone:  sage6.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 followup: ↓ 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% bulletproof. 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.