[QUOTE=amphoria;442634]You are correct as I have just realised that the version number is also printed on every line in factor.log.

For completeness I have also built yafu and msieve using VS2013. Yafu and msieve were built from the latest trunk code. This built Yafu 1.34.5 also. However the issue with poly select deadline still exists, so it might be something related to "small" composites.[/QUOTE]

The latest trunk code has not changed; I've been doing all new development in \branches\wip, which should build as version "1.35-beta". You can get the latest by clicking on the code tab from the souceforge yafu home screen, then navigate to branches -> wip and click on download snapshot. I'm pretty sure it will build with VS2013; let me know if not.

Thanks for the info you posted. All I can say so far is that the newest code built for linux, with the latest msieve code also built for linux, works with no issues. I'll do some investigating and find out what is broken... maybe it is a windows thing.

Whatever the problem is, it is isolated to version 1.34.5 (or perhaps earlier) on windows systems:

v1.34.5
[CODE]09/15/16 11:18:01 v1.34.5 @ WINDOWS-SYSTEM, nfs: commencing nfs on c99: 741244879109376246366513985428555418845913568310626508732412421094649581664407020182598936240636611
09/15/16 11:18:01 v1.34.5 @ WINDOWS-SYSTEM, nfs: commencing poly selection with 4 threads
09/15/16 11:18:01 v1.34.5 @ WINDOWS-SYSTEM, nfs: setting deadline of 297 seconds
09/15/16 11:22:46 v1.34.5 @ WINDOWS-SYSTEM, nfs: completed 56 ranges of size 5 in 284.8455 seconds
09/15/16 11:22:46 v1.34.5 @ WINDOWS-SYSTEM, nfs: best poly = # norm 1.646415e-013 alpha -4.744248 e 1.356e-008 rroots 4
09/15/16 12:36:22 v1.34.5 @ LINUX-SYSTEM: commencing nfs on c99: 741244879109376246366513985428555418845913568310626508732412421094649581664407020182598936240636611
09/15/16 12:36:22 v1.34.5 @ LINUX-SYSTEM: commencing poly selection with 8 threads
09/15/16 12:36:22 v1.34.5 @ LINUX-SYSTEM: setting deadline of 148 seconds
09/15/16 12:38:53 v1.34.5 @ LINUX-SYSTEM: completed 9173 ranges of size 5 in 150.9921 seconds
09/15/16 12:38:53 v1.34.5 @ LINUX-SYSTEM: best poly = # norm 1.197408e-13 alpha -4.840726 e 1.182e-08 rroots 2
[/CODE]

v1.35-beta
[CODE]09/15/16 09:50:01 v1.35-beta @ WINDOWS-VERSION, nfs: commencing nfs on c99: 741244879109376246366513985428555418845913568310626508732412421094649581664407020182598936240636611
09/15/16 09:50:02 v1.35-beta @ WINDOWS-VERSION, nfs: commencing poly selection with 4 threads
09/15/16 09:50:02 v1.35-beta @ WINDOWS-VERSION, nfs: setting deadline of 297 seconds
09/15/16 09:55:00 v1.35-beta @ WINDOWS-VERSION, nfs: completed 1096 ranges of size 5 in 298.5198 seconds
09/15/16 09:55:00 v1.35-beta @ WINDOWS-VERSION, nfs: best poly = # norm 1.334633e-013 alpha -4.735009 e 1.235e-008 rroots 2
09/15/16 12:52:00 v1.35-beta @ LINUX-VERSION, nfs: commencing nfs on c99: 741244879109376246366513985428555418845913568310626508732412421094649581664407020182598936240636611
09/15/16 12:52:00 v1.35-beta @ LINUX-VERSION, nfs: commencing poly selection with 8 threads
09/15/16 12:52:00 v1.35-beta @ LINUX-VERSION, nfs: setting deadline of 148 seconds
09/15/16 12:54:30 v1.35-beta @ LINUX-VERSION, nfs: completed 11525 ranges of size 5 in 150.0306 seconds
09/15/16 12:54:30 v1.35-beta @ LINUX-VERSION, nfs: best poly = # norm 1.195023e-13 alpha -4.787281 e 1.173e-08 rroots 4[/CODE]

It looks like the problem is in whatever version of msieve was linked into the 1.34.5 executable because the problem doesn't exist in today's version on windows or linux. There are lots of benefits to building the new yafu version but to solve this problem what you really need to do is build the newest msieve first. You should be able to do that and then use either 1.34.5 or 1.35-beta.

[QUOTE=bsquared;442663]It looks like the problem is in whatever version of msieve was linked into the 1.34.5 executable because the problem doesn't exist in today's version on windows or linux. There are lots of benefits to building the new yafu version but to solve this problem what you really need to do is build the newest msieve first. You should be able to do that and then use either 1.34.5 or 1.35-beta.[/QUOTE]

Unfortunately if I link the latest version of msieve (trunk r993) against yafu 1.35-beta, msieve is crashing during the linear algebra phase. Strangely I was able to link the same version of msieve against yafu 1.34.5 without it crashing, but this does not fix the poly select deadline problem.

Solving the crash is beyond my capabilities. I thought that it might be related to the pthreads library. The latest compiled version I could find is from 2012.

Do you have a working version of yafu 1.35-beta for windows that you can post somewhere?

My msieve version, windows 64 bit.

[QUOTE=amphoria;442673]Unfortunately if I link the latest version of msieve (trunk r993) against yafu 1.35-beta, msieve is crashing during the linear algebra phase. Strangely I was able to link the same version of msieve against yafu 1.34.5 without it crashing, but this does not fix the poly select deadline problem.

Solving the crash is beyond my capabilities. I thought that it might be related to the pthreads library. The latest compiled version I could find is from 2012.

Do you have a working version of yafu 1.35-beta for windows that you can post somewhere?[/QUOTE]

You are right, it does crash in LA. I had never run a NFS job to completion on windows with the new version. Well... one more thing to work out.

I'm having a problem that may be related, but not sure. I'm limited for time right now. I was going to wait until I could gather some more data, but since it might be relative, here's some of what I have:

I have a number that won't factor on four different linux machines using the newest versions of all the packages. The runs seem to drop out with no messages, all the way to the command prompt (edit - YAFU was started from the command prompt.):
[code]
12936 45949468771135 4360973942040003788613537
12936 8626660180883 4360973941819841271959991
12936 32826124443295 4360973940891776402571718
12936 58188657626405 4360973941635782096255512
save 1.835027e-14 -4.6541 3235478.33 4.963615e-09 rroots 2
save 1.734181e-14 -4.5970 3434628.62 4.825250e-09 rroots 2
hashtable: 1024 entries, 0.02 MB
elapsed time of 905.3081 seconds exceeds 803 second deadline; poly select done
nfs: commencing algebraic side lattice sieving over range: 1120000 - 1130000
nfs: commencing algebraic side lattice sieving over range: 1110000 - 1120000

...(lines removed for efficiency)

nfs: commencing algebraic side lattice sieving over range: 1480000 - 1490000
nfs: commencing algebraic side lattice sieving over range: 1470000 - 1480000
nfs: commencing msieve filtering
4678794529377765619886998533986913620849434520921582732844299916951588150985105814225896836243076543231
nfs: commencing algebraic side lattice sieving over range: 1500000 - 1510000
nfs: commencing algebraic side lattice sieving over range: 1490000 - 1500000
nfs: commencing msieve filtering
4678794529377765619886998533986913620849434520921582732844299916951588150985105814225896836243076543231[/code]I have all the files that were created as well as a file of the YAFU output which I redirected. (Some of that file, including the end is shown above.) I can zip them up and put them on SendSpace if someone would like to see them, but it wouldn't be until tomorrow night.

BTW, I do have the factors. One of my machines found them with ECM:
[code]
prp45 = 508796826600370749062703008999220415547332823
prp58 = 9195801319438410752790284108566289031895884501156735887897
[/code]

[QUOTE=bsquared;442684]You are right, it does crash in LA. I had never run a NFS job to completion on windows with the new version. Well... one more thing to work out.[/QUOTE]

If I have manged to debug it correctly, the crash is caused by a divide by zero error on line 526 of msieve\common\lancsoz\lancsoz_matmul0.c. Basically superblock_size is being set to 0 on line 496. obj->cache_size to is set to 6 on my PC (an i7-5960X) which seems very low. On the version of msieve linked to yafu 1.34.5 the processor cache size is 20480 kB according to nfs.log.

I am going to try building yafu 1.34.5 with the latest msieve again as it appeared to work last time. It it does, then the problem would appear to lie with yafu, otherwise it would appear to be a msieve problem.

If it works on linux, then may be msieve has a problem detecting the L3 cache size on windows.

[QUOTE=amphoria;442722]If I have manged to debug it correctly, the crash is caused by a divide by zero error on line 526 of msieve\common\lancsoz\lancsoz_matmul0.c. Basically superblock_size is being set to 0 on line 496. obj->cache_size to is set to 6 on my PC (an i7-5960X) which seems very low. On the version of msieve linked to yafu 1.34.5 the processor cache size is 20480 kB according to nfs.log.

I am going to try building yafu 1.34.5 with the latest msieve again as it appeared to work last time. It it does, then the problem would appear to lie with yafu, otherwise it would appear to be a msieve problem.

If it works on linux, then may be msieve has a problem detecting the L3 cache size on windows.[/QUOTE]

Thanks for looking into this. We'll see how your test goes, but I'm guessing that something in the interface changed in msieve so that memory allocations are getting corrupted between yafu/msieve. That happened once before and is a consequence of my shoddy half-way merge/link of the two programs. I will go and look at the revision log of msieve.

[QUOTE=amphoria;442722]I am going to try building yafu 1.34.5 with the latest msieve again as it appeared to work last time. It it does, then the problem would appear to lie with yafu, otherwise it would appear to be a msieve problem.

If it works on linux, then may be msieve has a problem detecting the L3 cache size on windows.[/QUOTE]

It looks I did something wrong last time or, less likely, msieve is behaving differently now that I am building debug versions. If I link msieve r993 against yafu 1.34.5, then I still get the crash in LA. I didn't run it inside the VS debugger but nfs.log shows a superblock size of 0. Also the poly select deadline works correctly, so that must have been due to an old version of msieve linked to the windows binary on SourceForge.

This (the LA problem) is starting to look like a problem with msieve on windows detecting the L3 cache size.

[QUOTE=amphoria;442742]This (the LA problem) is starting to look like a problem with msieve on windows detecting the L3 cache size.[/QUOTE]

OK the problem is with yafu calling the msieve library. I tested this by running poly select and sieving phases only from yafu, and then using the msieve binary to run filter, LA and sq root phases. Using msieve.exe the L3 cache size was correctly identified as 20480 kB and the superblock size calculated to be 1966080, and the LA ran successfully.

[QUOTE=amphoria;442756]OK the problem is with yafu calling the msieve library. I tested this by running poly select and sieving phases only from yafu, and then using the msieve binary to run filter, LA and sq root phases. Using msieve.exe the L3 cache size was correctly identified as 20480 kB and the superblock size calculated to be 1966080, and the LA ran successfully.[/QUOTE]

My suspicions confirmed. Thank you for your testing - I'll get it fixed.