msieve QS segfault when given large worktodo.ini

[fivemack]

I injudiciously ran gnfs-lasieve4I16e with mfba greater than 96, which gives thousands of 'trying MPQS on too large a number' errors. So I grepped out the numbers into worktodo.ini and ran msieve current-svn on my Mac, to see if that might be a realistic work of getting round the limitations of lasieve4.

This is five thousand 30-digit numbers; it happily factors one every 150 milliseconds or so, but segfaults after a few minutes. Not always on the same number.

Rerunning under gdb, it ends with

sieving in progress (press Ctrl-C to pause)
333 relations (167 full + 166 combined from 1171 partial), need 382
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x000000010002affc in check_sieve_val ()
(gdb) bt
#0  0x000000010002affc in check_sieve_val ()
#1  0xf57bc009387903be in ?? ()

worktodo.ini.gz is attached. I've run this on a Linux PC and get a crash in the same place, with more of an indication of stack corruption

(gdb) bt
#0  0x0000000000410843 in check_sieve_val ()
#1  0x205d053b7e8bf7b9 in ?? ()
#2  0x1205d053b7e8beb1 in ?? ()
#3  0x601f01be7f840d2b in ?? ()
#4  0x0601f01be7f83f90 in ?? ()
#5  0xc481742dbc2c2f3d in ?? ()
#6  0xac4817414edfa2fa in ?? ()
#7  0xfac4817414edfa2f in ?? ()
#8  0x2fac4817414edfa2 in ?? ()
#9  0xa2fac4817414edfa in ?? ()
#10 0xe449a43d3d0b6eff in ?? ()

with the code around the crash-point being

   0x0000000000410823 <+2467>:	test   %ecx,%ecx
   0x0000000000410825 <+2469>:	je     0x4107c8 <check_sieve_val+2376>
   0x0000000000410827 <+2471>:	sub    $0x2,%esi
   0x000000000041082a <+2474>:	mov    0x624(%rsp,%rsi,4),%eax
   0x0000000000410831 <+2481>:	jmp    0x410810 <check_sieve_val+2448>
   0x0000000000410833 <+2483>:	mov    0x6f8(%rsp),%rax
   0x000000000041083b <+2491>:	mov    0x6f8(%rsp),%rdx
=> 0x0000000000410843 <+2499>:	mov    0x8(%rax),%rax
   0x0000000000410847 <+2503>:	mov    %rax,0x28(%rsp)
   0x000000000041084c <+2508>:	mov    0x4(%rdx),%eax

(gdb) info registers
rax            0x601f01be7f840d2b	6926256669613886763
rbx            0x16d	365
rcx            0x46f	1135
rdx            0x601f01be7f840d2b	6926256669613886763
rsi            0xbed	3053
rdi            0x7fffffffc030	140737488338992
rbp            0x7fffffffc520	0x7fffffffc520
rsp            0x7fffffffba10	0x7fffffffba10

Happy to run any tests you might want.

[bsquared]

[useless] My first thought was that this is related to the known tinyqs bug. But the cutoff for sending composites to that routine is 85 bits, so that's not it. [/useless]

If you want to get the list done, yafu's smallmpqs routine burns through your list in 30 seconds on my machine.

./yafu "smallmpqs(@)" -batchfile worktodo.ini -silent > out.log

[davidknippers]

While I'm not going to contribute anything necessarily useful right at this moment, it might confort you to know that I observed a similar segmentation fault in my own application using the msieve library when factoring many numbers in the same size range in a single run.

After enabling debugging, I ended up being confused - while my code is not beyond bugs, all the evidence was pointing to check_sieve_val() being the culprit.

I could not reproduce it consistently, leading me to believe it was dependent on seed values. I considered playing around with some constant seeds, but in the end, I found it easier to just restart it. I managed to reproduce the errors in a few versions of msieve, from 1.45 all the way to 1.49. If I have some free time in the coming days I'll explore the issue again.