SNFS crash during sieving

[lavalamp]

Not sure what's going on here, but I've come across an issue during sieving that causes an immediate crash with two different p^7-1 numbers I've been working on.

I'm running this on Windows 10 on an i5 3570k (Ivy Bridge). Using binaries compiled quite some time ago by Jeff Gilchrist for this architecture. Not sure what version gnfs-lasieve4I14e is as it doesn't report it.

Here's the setup if anyone wants to try it. I'm using factmsieve.py with the following poly:

n: 971666989432985861438307125484123140925670597585594036480384648135507133303956446922912100021034526243538926163942190374778730570382786092317017893535902546203811531071728511879512377154370751
deg: 6
type: snfs
c6: 1
c5: 1
c4: 1
c3: 1
c2: 1
c1: 1
c0: 1
Y1: 1
Y0: -440089295235970403642553674737477
skew: 1
lss: 0
q0: 4000000

If I edit factmsieve.py to only run a single thread, these are the values of q0 that cause the crash:

q0: 3932210 <-- works
q0: 3932211 <-- fails
...
fails
...
q0: 4056138 <-- fails
q0: 4056139 <-- works

Here is the job.T0 file:

n: 971666989432985861438307125484123140925670597585594036480384648135507133303956446922912100021034526243538926163942190374778730570382786092317017893535902546203811531071728511879512377154370751
c6: 1
c5: 1
c4: 1
c3: 1
c2: 1
c1: 1
c0: 1
Y1: 1
Y0: -440089295235970403642553674737477
skew: 1.00      
rlim: 12900000
alim: 3999999
lpbr: 28
lpba: 28
mfbr: 56
mfba: 56
rlambda: 2.5
alambda: 2.5
q0: 4000000
qintsize: 100000
#q1:4100000

Here is the log output:

Sun Sep 22 19:47:47 2019 -> factmsieve.py (v0.86)
Sun Sep 22 19:47:47 2019 -> This is client 1 of 1
Sun Sep 22 19:47:47 2019 -> Running on 1 Core with 1 hyper-thread per Core
Sun Sep 22 19:47:47 2019 -> Working with NAME = fail
Sun Sep 22 19:47:47 2019 -> Selected lattice siever: gnfs-lasieve4I14e
Sun Sep 22 19:47:47 2019 -> Creating param file to detect parameter changes...
Sun Sep 22 19:47:47 2019 -> Running setup ...
Sun Sep 22 19:47:47 2019 -> Estimated minimum relations needed: 2.51189e+07
Sun Sep 22 19:47:47 2019 -> cleaning up before a restart
Sun Sep 22 19:47:47 2019 -> Running lattice siever ...
Sun Sep 22 19:47:47 2019 -> entering sieving loop
Sun Sep 22 19:47:47 2019 -> making sieve job for q = 4000000 in 4000000 .. 4100000 as file fail.job.T0
Sun Sep 22 19:47:47 2019 -> Lattice sieving algebraic q from 4000000 to 4100000.
Sun Sep 22 19:47:47 2019 -> gnfs-lasieve4I14e -k -o spairs.out.T0 -v -n 0 -a fail.job.T0
Sun Sep 22 19:47:52 2019 -> Return value 3221225477. Updating job file and terminating...
Sun Sep 22 19:47:52 2019 LatSieveTime: 5.01

I have attached a screenshot of the console output, though it is very similar to the log.

[chris2be8]

I don't use Windows so I can't offer much more help.

Are there any errors logged when it happens? I don't know what logs Windows keeps or where it keeps them though.

Chris

[Alfred]

Maybe rlim = alim = 4000000 will help.

[lavalamp]

Originally Posted by chris2be8

Are there any errors logged when it happens? I don't know what logs Windows keeps or where it keeps them though.

There is an error in Windows Logs -> Application. However, a similar error also occurs when I ctrl+c the python script to stop a job running. It seems like this might just be what Windows does when a program quits early. Having said that, the "Exception code" and "Fault offset" are different when it crashes so they might be diagnostically relevant.

Faulting application name: gnfs-lasieve4I14e_argfix.exe, version: 0.0.0.0, time stamp: 0x51567554
Faulting module name: gnfs-lasieve4I14e_argfix.exe, version: 0.0.0.0, time stamp: 0x51567554
Exception code: 0xc0000005
Fault offset: 0x0000000000020a71
Faulting process ID: 0x1a04
Faulting application start time: 0x01d5725ddfe91176
Faulting application path: E:\OPN\bin\gnfs-lasieve4I14e_argfix.exe
Faulting module path: E:\OPN\bin\gnfs-lasieve4I14e_argfix.exe
Report ID: 6db5123e-4645-4ff2-8cba-760c1b85cd6b
Faulting package full name: 
Faulting package-relative application ID:

Can you reproduce the crash on Linux with the job file in my previous post?

Alfred, I don't really have control over those values as factmsieve.py creates the job.Tn files itself. What is confusing to me is that there is only a crash in a (relatively) small range of q0 values. I can get around this issue by simply starting my sieve at q0=5000000, but perhaps there is a bug in the underlying code?