That's what I thought, and this may be the cause of Serge's problem. The sanity check on the NFS square root computes relation product mod a prime > 2^31.

I'll give it a few more days for some 64-bit rework to trickle in, then will release v1.41 early with this fixed.

(Only 64-bit users have to worry about this)

That's good; yes, it was a 64-bit binary; I can rebuild with 1.39 definitions.
Looking back at the c244 report (done two days ago), I see why I haven't found it back then: the filtering was done with 1.40b2, but BL and sqrt with 1.39.

Just a positive check. In 1.40, replaced only the two definitions and finished the same sqrt ...and the c244 BL (from 90% up) and the sqrt.

Jason, did you find a probable cause for my crashing problems with poly-finding using 1.40b2 and fix it? I haven't had any problems with the final 1.40, but I haven't tried it much yet. I don't mean to pester you, I'd just really like to use msieve with automated ggnfs runs.

That problem should be solved in the 1.40 release.

[QUOTE=jasonp;167432]That problem should be solved in the 1.40 release.[/QUOTE]

Alas, it doesn't appear to be. Not completely anyway. I was greeted this morning with another "msieve.exe has stopped working" prompt:

[code]
Msieve v. 1.40
Wed Apr 01 07:14:32 2009
random seeds: 89561030 ce93ef86
factoring 11627701556692738259396298147662784143481181112717528822147060987383305345504070109018908333336385798122288875854831 (116 digits)
searching for 15-digit factors
commencing number field sieve (116-digit input)
commencing number field sieve polynomial selection
time limit set to 2.00 hours
searching leading coefficients from 1 to 18886
[...]
*crash*
[/code]

This was with the 32-bit msieve v1.40 downloaded from your site. It crashed after 1.3 hours.

I see the problem with this input, it was quite subtle. v1.41 will have a fix for it.

Honestly I find it difficult to work up the enthusiasm for aliquot sequences that many here have, but if it leads to my code getting pounded this hard then carry on with my blessings!

Just a question: Does v. 1.40 still have the built-in lower limit of 98 digits for GNFS? If yes: Can you please lower the limit in 1.41? (the crossover between QS and GNFS seems to be at ~95-96 digits - or with a good polynomial (found by msieve) maybe even a bit lower?)

[quote=Andi47;167719]Just a question: Does v. 1.40 still have the built-in lower limit of 98 digits for GNFS? If yes: Can you please lower the limit in 1.41? (the crossover between QS and GNFS seems to be at ~95-96 digits - or with a good polynomial (found by msieve) maybe even a bit lower?)[/quote]

It doesn't have the limit for postprocessing, but it still does for poly selection. My crossover is currently about 95 digits because of pol51 only having parameters for 98 digits and above. If there were lower parameters or msieve could do that size, then it would probably be around 93 digits.

I found the offending line of code. #define MIN_NFS_BITS = 320; I'm trying to recompile w/ 300 instead since I have visual studio, but it gets a bunch of build errors because I don't have gmp.h.
Edit: I can't really compile, would someone be a hero and compile a x64 bit for core2duo?

[QUOTE=Joshua2;167749]I found the offending line of code. #define MIN_NFS_BITS = 320; I'm trying to recompile w/ 300 instead since I have visual studio, but it gets a bunch of build errors because I don't have gmp.h.
Edit: I can't really compile, would someone be a hero and compile a x64 bit for core2duo?[/QUOTE]

1.41 is supposed to be out any day now so I can make your special build then.

If you have the full visual studio it is not hard to compile GMP. Well MPIR (a GMP fork) is much easier since it is designed to work with Windows from the beginning. You can download the tarball here: [url]http://mpir.org/[/url]

Follow the instructions in the build.vc9/ directory on how to build it in Windows (you need to install the free yasm assembler but it tells you how) and then you can build the whole thing if you want. The only trick is that *after* you build the libary in the build.vc9/ directory you need to run the batch file to_gmp.bat so it renames the library from mpir.lib and mpir.h to gmp.* for you before you build msieve.

Jeff.

Segmentation fault on x86_64 architecture
 

[QUOTE=jasonp;166758]In the factor base file, make the second line 'SKEW 1.00'

I could have sworn I made the default skew 1.0, but apparently did not in that code path. On line 80 of gnfs/poly/poly.c, change

[code]
if (buf[0] == 'S') {
if (skewness != NULL)
*skewness = atof(buf + 5);
fgets(buf, (int)sizeof(buf), fp);
}
[/code]
to
[code]
if (buf[0] == 'S') {
if (skewness != NULL)
*skewness = atof(buf + 5);
fgets(buf, (int)sizeof(buf), fp);
}
else if (skewness != NULL) {
*skewness = 1.0;
}
[/code][/QUOTE]

Uh-oh: I ran it with "SKEW 1.00" on the second line of the fb, but I still have a segmentation fault on filtering and snfs line sieving. Then I recompiled with the suggested change above and the results were the same.

I'm running on a 64-bit K10 system.

[QUOTE=FactorEyes;167859]Uh-oh: I ran it with "SKEW 1.00" on the second line of the fb, but I still have a segmentation fault on filtering and snfs line sieving. Then I recompiled with the suggested change above and the results were the same.
[/QUOTE]
<sigh>

I misplaced your PM; you could resend me the number and the polynomial you used? Looks like the v1.41 release will be tomorrow.

Now that v1.41 is out, please direct followups to some other thread.

==> [URL]http://mersenneforum.org/showthread.php?t=11687[/URL]