square root crash

[bsquared]

I'm getting a segmentation fault during the square root phase. It has been repeatable for at least one dependency; I'm trying other dependencies now.

This occurred during factorization of aliquot sequence 4788 at iteration 2503, on a c137. I still have all the data, matrix, and dependency files.

Msieve v. 1.44
Wed Dec 30 07:54:27 2009
random seeds: 924ede45 75091bcc
factoring 40749881176591001313668881738461183359103092070283580604476483864940722559707999223166066411471564908270442953165453791845420594628304571 (137 digits)
searching for 15-digit factors
commencing number field sieve (137-digit input)
R0: -186181968602879312631151995
R1:  2753343120517687
A0:  75928063558542655529864860597168
A1: -9182525920185050132113778204
A2: -16139511119661987272384
A3:  39176187555574241
A4: -418654113212
A5:  182160
skew 1.00, size 3.030638e-13, alpha -7.007098, combined = 6.732510e-13

commencing square root phase
reading relations for dependency 1
read 876854 cycles
cycles contain 2615106 unique relations
read 2615106 relations
multiplying 2615106 relations
Segmentation fault

[jasonp]

If on a linux system, can you rebuild with 'make x86_64 OPT_FLAGS=-g', then
PM me the output of 'bt full' from gdb after the segfault occurs in the debug binary? I hope building the debug code will be sufficient, otherwise you can mail me a DVD :)

[bsquared]

Dependency 2 has also just failed in the same way. I'll try a previous version of msieve...

I'll build the debug binary as well.

Interestingly, a previous version finds more unique relations in the first dependency, but multiplies the same number together in the end... and also works!

Msieve v. 1.42
Wed Dec 30 08:22:32 2009
random seeds: 749a61a9 ff6d6c87
factoring 40749881176591001313668881738461183359103092070283580604476483864940722559707999223166066411471564908270442953165453791845420594628304571 (137 digits)
no P-1/P+1/ECM available, skipping
commencing number field sieve (137-digit input)
R0: -186181968602879312631151995
R1:  2753343120517687
A0:  75928063558542655529864860597168
A1: -9182525920185050132113778204
A2: -16139511119661987272384
A3:  39176187555574241
A4: -418654113212
A5:  182160
skew 1.00, size 3.030638e-13, alpha -7.007098, combined = 6.732510e-13

commencing square root phase
reading relations for dependency 1
read 876854 cycles
cycles contain 3228004 unique relations
read 3228004 relations
multiplying 2615106 relations
multiply complete, coefficients have about 132.56 million bits
initial square root is modulo 57221
sqrtTime: 856
prp60 factor: 345904004092746503021088299379972074287902300978671971758577
prp78 factor: 117806907969948860631659379351218221407555470977030568931916016398691505794923
elapsed time 00:14:17

[Andi47]

Originally Posted by bsquared

Msieve v. 1.44

1.44? Has this version already been "officially" released?

[bsquared]

I'm not sure how the msieve version sync's with the SVN version. 1.44 is what I got when I built the trunk code about a month ago...

[henryzz]

Originally Posted by bsquared

I'm not sure how the msieve version sync's with the SVN version. 1.44 is what I got when I built the trunk code about a month ago...

i think jasonp increments the version number in the svn straight after a new release
since 1.44 is not yet released that means we are dealing with an svn version

[sleigher]

So I did post this in another thread before I saw this one.

I am getting a seg fault using msieve 1.45 from svn. Is it necessary to use a previous version of msieve for the square root part?

commencing square root phase
reading relations for dependency 1
read 2090616 cycles
cycles contain 5829738 unique relations
read 5829738 relations
multiplying 5829738 relations
Segmentation fault

[bsquared]

Save the data! As far as I know Jason is still working on a fix for this, and he may need/want the .mat, .dep and other files...

[fivemack]

I'm getting the same.

svn update (to revision 239), rebuilt, rerun under gdb, and

(gdb) bt
#0  0x00002b7d375fa67d in __gmpz_add_ui () from /usr/lib64/libgmp.so.3
#1  0x00000000004238ea in gmp_poly_mul (p1=0x7fff735d5260, p2=<value optimized out>, mod=0x7fff735d6040, free_p2=1)
    at gnfs/sqrt/sqrt_a.c:191
#2  0x0000000000423d2f in multiply_relations (prodinfo=0x7fff735d6360, index1=0, index2=2238503, prod=0x7fff735d5f20)
    at gnfs/sqrt/sqrt_a.c:368
#3  0x0000000000424365 in alg_square_root (obj=0x565250, mp_alg_poly=0x7fff735d7270, n=0x7fff735d9120, c=0x7fff735d7a80, 
    m1=0x7fff735d6504, m0=0x7fff735d6484, rlist=0x2b7d37bc1010, num_relations=2238504, check_q=2147483693, sqrt_a=0x7fff735d7b00)
    at gnfs/sqrt/sqrt_a.c:692
#4  0x0000000000423070 in nfs_find_factors (obj=0x565250, n=0x7fff735d9120, factor_list=0x7fff735d8810) at gnfs/sqrt/sqrt.c:407
#5  0x000000000041535f in factor_gnfs (obj=0x565250, n=0x7fff735d9120, factor_list=0x7fff735d8810) at gnfs/gnfs.c:160
#6  0x0000000000404a17 in msieve_run (obj=0x565250) at common/driver.c:151
#7  0x0000000000402e8e in factor_integer (
    buf=0x7fff735d9480 "33577312629044687322683253176370859946062994512713093161690045173177708208628447962919655873151495194809846780665350950840026037372937", flags=1027, savefile_name=0x0, logfile_name=0x0, nfs_fbfile_name=0x0, seed1=0x7fff735d963c, seed2=0x7fff735d9638, 
    max_relations=0, nfs_lower=0, nfs_upper=0, cpu=cpu_opteron, cache_size1=65536, cache_size2=1048576, num_threads=0, mem_mb=0, 
    which_gpu=0) at demo.c:186
#8  0x0000000000403974 in main (argc=3, argv=0x7fff735d9758) at demo.c:525

and the error is at

190			for (j = d1; j; j--) {
191				mpz_addmul(tmp[j], p1->coeff[j], p2->coeff[i]);
192			}

where for some reason i has acquired the value 13410016.

This is compiler-dependent: the build on an opteron machine with gcc-4.1.0 fails, a build on a core2 machine with gcc-4.3.2 and exactly the same makefile works.

[xilman]

Originally Posted by fivemack

This is compiler-dependent: the build on an opteron machine with gcc-4.1.0 fails, a build on a core2 machine with gcc-4.3.2 and exactly the same makefile works.

Now that is interesting!

I've been unable to get a usable build on any Unix-like system. The workaround in my case is to run the square root phase on a (virtual) WinXP machine.


Paul

[Batalov]

Originally Posted by fivemack

This is compiler-dependent: the build on an opteron machine with gcc-4.1.0 fails, a build on a core2 machine with gcc-4.3.2 and exactly the same makefile works.

I feel, too, that Tom is onto something here.
With gcc-4.3.2, I haven't seen any sqrt problems.
Possibly related: I have seen weird subtle bugs on 16e sievers built with gcc-4.1.2 and not with gcc-4.3.2.