[QUOTE=Greebley;194858]I was trying 374 and got the following issue. Any idea why it would occur?
This is on windows 32 bit and I was running aliqueit.exe rather than entering in any commands myself.

<several successful runs with no problems - total yield about 124k each time>
[CODE]
...
milliseconds total: Sieve 89279 Sched 0 medsched 33745
TD 99343 (Init 7231, MPQS 16907) Sieve-Change 99240
TD side 0: init/small/medium/large/search: 992 7620 2092 2014 30515
sieve: init/small/medium/large/search: 5431 19946 3084 2552 13160
TD side 1: init/small/medium/large/search: 337 5993 2099 2069 38358
sieve: init/small/medium/large/search: 2567 11478 3171 2268 25622
=>"c:/bin/cat.exe" spairs.out >> test.dat
Found 1154434 relations, need at least 1936352 to proceed.
-> Q0=750001, QSTEP=40000.
-> makeJobFile(): q0=750000, q1=790000.
-> makeJobFile(): Adjusted to q0=750001, q1=790000.
-> Lattice sieving algebraic q-values from q=750001 to 790000.
=> "/aliquot/ggnfs/gnfs-lasieve4I11e.exe" -k -o spairs.out -v -n0 -a test.job
Cannot open spairs.out for output: m
-> Return value 256. Updating job file and terminating...
=>"c:/bin/cat.exe" spairs.out >> spairs.add
"c:/bin/cat.exe": spairs.out: No such file or directory
-> makeJobFile(): q0=750000, q1=790000.
-> makeJobFile(): Adjusted to q0=750001, q1=790000.
Terminating...
[/CODE][/QUOTE]

I've been getting the same thing, except without the "Cannot open spairs.out for output: m". This will be a big problem for people who don't always keep a close watch on their computer.

CRC errors in GGNFS .zip
 

Anyone else getting CRC errors downloading Jeff's GGNFS zip files?

In particular I get them for:
[URL]http://gilchrist.ca/jeff/factoring/ggnfs-svn374-win64-core2.zip[/URL]

when trying to extract. I also tried 7-zip with same result, although interestingly got warnings on different files the 2nd time I downloaded.

Thanks!

- Joe

[quote=JoeCrump;196233]Anyone else getting CRC errors downloading Jeff's GGNFS zip files?
[/quote]

File was downloaded and checked - CRC corect

Must have been a fluke on my part. Thanks for checking! It's working fine now. I'm really glad the noisy output in the 64-bit version was corrected!

one more crash (11e windows binary)
 

[QUOTE=Andi47;191285]For me it crashed again after repeating (windowd binary on a P4).
These kind of crashes seem to happen quite frequently (with the windows binaries) for composites <c90, so I prefer to set the crossover point in aliqueit.ini (I am doing automated factorizations using aliqueit.exe.) to c90 rather than c85 when I am NOT around to recover the run from crashes.

[SIZE="1"](if you want to have more testing cases: go to the [URL="http://www.mersenneforum.org/showthread.php?p=191273#post191273"]subproject thread[/URL] over there in the aliqueit forum, reserve a sequence or two and let them run for a day with the crossover point between MPQS and GNFS set to c85 in the aliqueit.ini.)[/SIZE][/QUOTE]

This one just crashed (reproducible crash) in a two-threaded run with FactMsieve.pl (started from aliqueit.exe):

[code]"C:/....../GGNFS/gnfs-lasieve4I11e.exe" -k -o spairs.out.T1 -v -n0 -a test.job.T1[/code]

[code]n: 72396580732662850641712560135491546637471639822952206518267820845960689787556845621930821
m:
Y0: -3166367803061133922436
Y1: 248239277251
c0: 123755134130653391452139001
c1: -3938673454661251975883
c2: 4436750873973386
c3: 2963085672
c4: 720
skew: 1369546.94
rlim: 600000
alim: 600000
lpbr: 25
lpba: 25
mfbr: 43
mfba: 43
rlambda: 2.2
alambda: 2.2
q0: 600001
qintsize: 4999
#q1:605000
[/code]

second thread:

[code]q0: 605000
qintsize: 4999
#q1:609999
[/code]

At least one of those crashed with the attached error message.

Someone else reported a crash with a 64bit Windows binary on the polynomial they had as well but in their case they found it did not crash if they ran the binary through Visual Studio. So I'm guessing VS must do something like set the memory space of variables to 0x00 first and there is some kind of pointer or memory access problem.

I don't really have time right now to try and track down this kind of bug in the ggnfs code. Maybe in the New Year.

You said it crashes with two-threaded run with FactMsieve.pl, does it not crash when using only 1 thread?

[QUOTE=Jeff Gilchrist;199226]Someone else reported a crash with a 64bit Windows binary on the polynomial they had as well but in their case they found it did not crash if they ran the binary through Visual Studio. So I'm guessing VS must do something like set the memory space of variables to 0x00 first and there is some kind of pointer or memory access problem.

I don't really have time right now to try and track down this kind of bug in the ggnfs code. Maybe in the New Year.

You said it crashes with two-threaded run with FactMsieve.pl, does it not crash when using only 1 thread?[/QUOTE]

I just tried on an other box, id didn't crash when using only 1 thread (BTW: it's a [B]32 bit[/B] windows binary). I'm not sure if this box has the same version of GGNFS. ([COLOR="Blue"]FEATURE REQUEST: PLEASE make the version number easily readable, for example by printing something like "GGNFS version xy, SVN xyz" to screen when starting up gnfs-lasieve4I1?e or pol51m0b / pol51opt[/COLOR])

[QUOTE=Andi47;199229]I just tried on an other box, id didn't crash when using only 1 thread (BTW: it's a [B]32 bit[/B] windows binary). I'm not sure if this box has the same version of GGNFS. ([COLOR="Blue"]FEATURE REQUEST: PLEASE make the version number easily readable, for example by printing something like "GGNFS version xy, SVN xyz" to screen when starting up gnfs-lasieve4I1?e or pol51m0b / pol51opt[/COLOR])[/QUOTE]

When you download the files you can hack FactMsieve.pl to print it.

[QUOTE=10metreh;199232]When you download the files you can hack FactMsieve.pl to print it.[/QUOTE]

how? Is this info contained in FactMsieve.pl? Or do you need to specify a flag when starting gnfs-lasieve4I1?e ?

[QUOTE=Andi47;199236]how? Is this info contained in FactMsieve.pl? Or do you need to specify a flag when starting gnfs-lasieve4I1?e ?[/QUOTE]

Change line 1470 in factMsieve.pl from [code]-> | This is the factMsieve.pl script for GGNFS. |[/code] to [code]-> | This is the factMsieve.pl script for GGNFS 0.77.1 SVN 374|[/code]
However, I don't know of a way to tell the version without just checking it when you download it.

The subversion client can tell you the revision level of the repository; if you want to modify the source, save the output in a file and cat the file within the perl script. Otherwise you can embed the revision number in each source file, but that only gets updated when the file is affected by a check-in, and so will potentially be different for every file.