odd segmentation fault

[ChristianB]

Hi,

I have an odd segmentation fault with the current yafu from svn (r342). Here is the problem:

./yafu "factor(123456789009876543211234567890098765432112345678900987654321333)"


fac: factoring 123456789009876543211234567890098765432112345678900987654321333
fac: using pretesting plan: normal
fac: using tune info for qs/gnfs crossover
div: primes less than 10000
rho: x^2 + 3, starting 10000 iterations on C60 
rho: x^2 + 2, starting 10000 iterations on C60 
rho: x^2 + 1, starting 10000 iterations on C60 
nfs: couldn't find special form
Speicherzugriffsfehler

The last line means "segmentation fault" in German.
running the same number using siqs directly gives me the factors:

$ ./yafu "siqs(123456789009876543211234567890098765432112345678900987654321333)"



starting SIQS on c60: 370741108137767397030734438108404700997334371408111074037001
using sse4.1 with med_sieve
using sse4.1 with med_sieve
using sse2 with tdiv_medprimes

==== sieving in progress ( 4 threads):    3552 relations needed ====
====            Press ctrl-c to abort and save state            ====
3699 rels found: 1805 full + 1894 from 16596 partial, (36425.79 rels/sec)

SIQS elapsed time = 0.5595 seconds.


***factors found***

P1 = 3
P1 = 3
P2 = 37
P17 = 28596344498792569
P44 = 12964632880031966906598999600889772386272529
1

I can also reproduce with numbers from FDB that should trigger a siqs factorization. Using a C98 and above uses nfs and does not throw the segfault.

I compiled yafu with:

make x86_64 USE_SSE41=1 NFS=1

What can I do to debug this? I still have an older version of yafu that works but I don't know the svn version of this. I'd like to get the current code working. I'm on Debian testing using the latest released ecm and gmp libraries.

[axn]

Apparently on this tiny number, yafu wants to do nfs, not SIQS. Perhaps some setting is preventing selection of siqs. Time to retune?

[ChristianB]

This is my current tune_info:

tune_info=Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz,LINUX64,1.18706e-05,0.204099,0.324344,0.0997272,97.8757,3199.98

I will retune as soon as aliqueit finishes the current sequence.

The segfault also happens with C97 from FDB but not with a C98 (which is my crossover point exactly)

Here is with a C97 (should use siqs):

./yafu "factor(1346890506266962133588620189606901951267040142442737102201365939343891347202689878898996138897973)"


fac: factoring 1346890506266962133588620189606901951267040142442737102201365939343891347202689878898996138897973
fac: using pretesting plan: normal
fac: using tune info for qs/gnfs crossover
div: primes less than 10000
rho: x^2 + 3, starting 10000 iterations on C97 
rho: x^2 + 2, starting 10000 iterations on C97 
rho: x^2 + 1, starting 10000 iterations on C97 
nfs: couldn't find special form
Speicherzugriffsfehler

And here a C98 (should use nfs and is using nfs):

./yafu "factor(19368533560477550795984783104796436186904996663790040806670180091266794230924763204502549642766057)"


fac: factoring 19368533560477550795984783104796436186904996663790040806670180091266794230924763204502549642766057
fac: using pretesting plan: normal
fac: using tune info for qs/gnfs crossover
div: primes less than 10000
rho: x^2 + 3, starting 10000 iterations on C98 
rho: x^2 + 2, starting 10000 iterations on C98 
rho: x^2 + 1, starting 10000 iterations on C98 
nfs: searching for brent special forms...
nfs: searching for homogeneous cunningham special forms...
nfs: searching for XYYXF special forms...
nfs: couldn't find special form
pm1: starting B1 = 150K, B2 = gmp-ecm default on C98
ecm: 30/30 curves on C98, B1=2K, B2=gmp-ecm default
ecm: 74/74 curves on C98, B1=11K, B2=gmp-ecm default
ecm: 216/216 curves on C98, B1=50K, B2=gmp-ecm default, ETA: 0 sec  
pm1: starting B1 = 3750K, B2 = gmp-ecm default on C98
ecm: 404/404 curves on C98, B1=250K, B2=gmp-ecm default, ETA: 0 sec c 
nfs: commencing nfs on c98: 19368533560477550795984783104796436186904996663790040806670180091266794230924763204502549642766057
nfs: searching for brent special forms...
nfs: searching for homogeneous cunningham special forms...
nfs: searching for XYYXF special forms...
nfs: couldn't find special form
nfs: commencing polynomial search over range: 8192 - 8442
nfs: commencing polynomial search over range: 8692 - 8942
nfs: commencing polynomial search over range: 8442 - 8692
nfs: commencing polynomial search over range: 8942 - 9192

[bsquared]

I don't have a complete answer just yet. However, the message doesn't necessarily indicate that it is doing NFS... just that it tried to find a NFS form. I added this check early in the factor algorithm because if there is an NFS form then the amount of ECM scheduled is reduced.

This helps pinpoint where the problem might be but I won't have time to look for it for the next few days at least.

[pakaran]

It may be worth mentioning that I encountered a similar issue when yafu was run on the small, but not unNFSably small, composite 194417753850401901402207205967096376638960217120756813979312551274352249332562607796084956616283 from my current aliquot work. It was called by the aliqueit binary. Running ./yafu 'nfs(num)' directly from the shell worked fine.