On Thursday, May 9, 2013 4:46:02 AM UTC+1, William wrote: > > On Wed, May 8, 2013 at 7:33 PM, Francois Bissey > <francoi...@canterbury.ac.nz <javascript:>> wrote: > > On 09/05/13 14:27, leif wrote: > >> Kwankyu Lee wrote: > >>> For example, can you stop everything on the computer and remote > log > >>> in to it from another machine, so you're hardly running anything > on > >>> it? If not, quit all possible applications and try building again. > >>> By the way, how much RAM does this machine have (this may not be > >>> relevant, but just in case)? > >>> > >>> > >>> There were running two virtual machines. So I rebooted the computer, > and > >>> opened just a terminal, and in the pristine state issued the command > >>> "./sage -i zn_poly". To my surprise, it still fails. It has 16GB ram. > >> > >> Well, that still doesn't imply the machine isn't loaded otherwise. > >> > >> > >> -leif > >> > >> P.S.: I strongly doubt GCC's version matters here. > >> > > > > I f I were you I wouldn't be o sure. I became involved in that bug > > when I stumbled on a similar one porting to power7 > > http://trac.sagemath.org/sage_trac/ticket/14098 > > the version of gcc on that platform had an impact. The main > > problem here is that zn_poly tuning parameters are completely > > wrong. zn_poly is abandoned upstream and the tunning routines > > are probably not aging well to support new cpu, compilers and OS. > > It might not exactly be totally abandoned upstream (it's more "done"): > Here's what the author (David Harvey) wrote to me offlist earlier > today about this thread: "Hi, Not obvious to me what the problem is > from reading the thread. Probably a bug in zn_poly. I'm about to > leave on a camping trip.... I will take a look next week." > > > > > Francois > > > > -- > > You received this message because you are subscribed to the Google > Groups "sage-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to sage-devel+...@googlegroups.com <javascript:>. > > To post to this group, send email to > > sage-...@googlegroups.com<javascript:>. > > > Visit this group at http://groups.google.com/group/sage-devel?hl=en. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > I think we came to the conclusion that some algorithms (KS or FFT, do not really remember) can segfault when they are used in some ranges where they were not expected to be used (let's say the FFT for small degree polys with small coeffs, although I'm not saying that is the problem). And it seems that in some cases (loaded system for example), the tuning process gets completely wrong results and tries such combination (i.e. FFT for really small stuff and bang!). (If KS is the problem, it might also be the case that such FFT/small integers combination is not supported in MPIR rather than some buggy combination in zn_poly itself.)
IIRC such problematic tuning parameters, which lead to systematic segfaults during the test suite of zn_poly have been collected on the Sage's trac ticket in cas David reads this thread. > > > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
