For the benefit of other [I]poor[/I] de[I]buggers[/I], let's cross-reference [URL="http://mersenneforum.org/showthread.php?t=12925"]the sqrt-crash thread here[/URL]. (you guys, of course, found it)

I never had a sqrt crash on me (out of hundreds, let's put a denominator), but it may support Tom's remark about compiler dependency: my gcc is 4.3.2.

[quote=Batalov;211035]For the benefit of other [I]poor[/I] de[I]buggers[/I] ...[/quote]

[b]Debugger[/b] ([i]n[/i]): De guy who built de computer.

Paul

Filtering woes
 

I know I've seen error reports like the one below but can't now find the resolution.

Briefly, C175 by SNFS is predicted to take 12.6M relations, in line with earlier successful runs. On the latest occasion filtering throws away all but a couple of thousand, even when more than 16M have been found by sieving. Sometimes over-sieving is itself problematic but the problem remains even if only the first 13M relations are fed into the filtering stages.

Any suggestions?

Paul

[QUOTE=xilman;212710]I know I've seen error reports like the one below but can't now find the resolution.

Briefly, C175 by SNFS is predicted to take 12.6M relations, in line with earlier successful runs. On the latest occasion filtering throws away all but a couple of thousand, even when more than 16M have been found by sieving. Sometimes over-sieving is itself problematic but the problem remains even if only the first 13M relations are fed into the filtering stages.

Any suggestions?

Paul[/QUOTE]

from your description, it looks like you're [B]under[/B]sieved rather than oversieved! could you post your log, please?

[quote=xilman;212710]I know I've seen error reports like the one below but can't now find the resolution.

Briefly, C175 by SNFS is predicted to take 12.6M relations, in line with earlier successful runs. On the latest occasion filtering throws away all but a couple of thousand, even when more than 16M have been found by sieving. Sometimes over-sieving is itself problematic but the problem remains even if only the first 13M relations are fed into the filtering stages.[/quote]Perhaps this may be relevant:[code]

Read 15855378 relations on 18243676 ideals in 50.160 seconds.
25 of these relations (in 25 sets) were discarded immediately.
Freeing hash table...
Total 14815720 relations in table after 50.170 seconds.
Starting factor base sort after 50.430 seconds
Polynomial 2 has too many ideals for p = 1698511
Try rerunning with -checknorms.
[/code]
That report is from the CWI filter program after converting the relations to its format. There are many more ideals than I expected and it looks like there's some kind of corruption, indicated by the "too many ideals" message.

Investigations are continuing.

Paul

[quote=xilman;212712]Investigations are continuing.[/quote]Yup, there are two corrupt relations:[code]
Discarding because primes don't divide polynomial 1 norm a = -1942067991, b= 2577558
Discarding because primes don't divide polynomial 1 norm a = -121555681, b= 4818350[/code] and there really are too few relations or, equivalently, too many ideals:[code]
Read 15855378 relations on 18243666 ideals in 89.610 seconds.
27 of these relations (in 27 sets) were discarded immediately.
2 sets were discarded because a prime did not divide the norm.
Freeing hash table...
Total 14815718 relations in table after 89.620 seconds.
Starting factor base sort after 89.870 seconds
Finishing factor base sort after 102.250 seconds
14900000 relations in in-memory table after 102.300 seconds.
157777 free relations.
Total 14973495 relations in table after 102.560 seconds.[/code]Okey-doke, more sieving is called for. Pity the estimated number of relations was so far adrift of what's required in reality but no harm done.


Paul

[QUOTE=xilman;212710]I know I've seen error reports like the one below but can't now find the resolution.

Briefly, C175 by SNFS is predicted to take 12.6M relations, in line with earlier successful runs. On the latest occasion filtering throws away all but a couple of thousand, even when more than 16M have been found by sieving. Sometimes over-sieving is itself problematic but the problem remains even if only the first 13M relations are fed into the filtering stages.

Any suggestions?

Paul[/QUOTE]

Is 175 your actual [B]SNFS[/B]-difficulty? Which parameters have you used for sieving?

BTW: I have seen a snfs-176 (12,11,163- by bsquared) which worked with 9.5M relations - maybe you try filtering with just the first 10M relations?

On the other hand, if you used 29 bit large primes, you might need as much as 20M relations.

[QUOTE=Andi47;212737]
On the other hand, if you used 29 bit large primes, you might need as much as 20M relations.[/QUOTE]

28-bit LPs will need around 24 million relations, and 29-bit LPs will need about 45 million relations

[quote=Andi47;212737]Is 175 your actual [B]SNFS[/B]-difficulty? Which parameters have you used for sieving?

BTW: I have seen a snfs-176 (12,11,163- by bsquared) which worked with 9.5M relations - maybe you try filtering with just the first 10M relations?

On the other hand, if you used 29 bit large primes, you might need as much as 20M relations.[/quote]Yes, it was the actual SNFS difficulty and 28-bit primes were used on both sides,

The factorization finished about an hour ago. It required 21.4M relations, compared with an estimate of 12.6M. It's this large discrepancy which perturbed me.

Anyway, panic over and the lesson I've learned is that the initial estimate can be wildly wrong.


Paul

[quote=xilman;212817]Yes, it was the actual SNFS difficulty and 28-bit primes were used on both sides,

The factorization finished about an hour ago. It required 21.4M relations, compared with an estimate of 12.6M. It's this large discrepancy which perturbed me.

Anyway, panic over and the lesson I've learned is that the initial estimate can be wildly wrong.


Paul[/quote]
it looks to me like the estimate was for a different large primes bound

[quote=henryzz;212850]it looks to me like the estimate was for a different large primes bound[/quote]Yup, that was my conclusion. Ah well.

Paul

I'm not sure if this problem is in msieve or gmp. But I'm posting here since I'm running msieve 1.44.

Trying to factor sigma(3158528101^18) I'm getting a segmentation fault in the square root phase. I've managed to get a core dump and tried to investigate with gdb:
[code] [chris@localhost o3158528101_18]$ gdb /home/chris/ggnfs/trunk/bin/msieve core.17435
GNU gdb Fedora (6.8-27.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(no debugging symbols found)
Reading symbols from /usr/lib64/libgmp.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libgmp.so.3
Reading symbols from /lib64/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libm.so.6
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2

Core was generated by `/home/chris/ggnfs/trunk/bin/msieve -s o3158528101_18.dat -l ggnfs.log -i o31585'.
Program terminated with signal 11, Segmentation fault.
[New process 17435]
#0 0x000000391fc0e9c5 in ?? () from /usr/lib64/libgmp.so.3
(gdb) bt
#0 0x000000391fc0e9c5 in ?? () from /usr/lib64/libgmp.so.3
#1 0x00000000004219da in gmp_poly_mul ()
#2 0x0000000000421e0e in multiply_relations ()
#3 0x000000000042242c in alg_square_root ()
#4 0x000000000042119c in nfs_find_factors ()
#5 0x00000000004149fb in factor_gnfs ()
#6 0x0000000000404605 in msieve_run ()
#7 0x0000000000402a8e in factor_integer ()
#8 0x0000000000403574 in main ()
[/code]
But I don't know enough to investigate further.

I've had several other problems with this number, mostly my mistakes. One caused a huge number of duplicate relations so I sorted the .dat file with sort -ur to get rid of them, could that upset msieve?

Chris K

What version of gcc are you using? Others have had this problem and it has disappeared when the version of gcc used was sufficiently modern.

On the system I'm having problems on gcc 4.1.2. I'll see what happens on a system with gcc 4.2.1.

Chris K

Success. msieve 1.44 compiled with gcc 4.2.1 completed the square root. Thanks for the hint.

Chris K