las_descent sometimes looks up primes outside the renumber table
This bug is connected to the reopening of #30058 (closed) by @x-cbouil
The following command line:
./build/localhost.debug/sieve/las_descent --allow-largesq --never-discard --renumber $WORKDIR/p80.renumber.gz --log $WORKDIR/p80.dlog --fb1 $WORKDIR/p80.roots1.gz --poly $WORKDIR/p80.poly --descent-hint-table /tmp/hint --I 12 --lim0 125000 --lim1 125000 --lpb0 19 --mfb0 38 --lpb1 19 --mfb1 38 -t 1 --todo /tmp/todo2
The todo2 file is just one special-q
The hint file is distorted to yield a super large estimation of the remaining smoothing time, forcing the special-q to be investigated for much longer.
As a result, las_descent
eventually examines the relation:
88738405157,1843714:3,3,13,2b,3c7,5139b3,22b3fe36c9:2,2,5,5,7,b,17,17,1f,29,c1,259,2b4b,15cf77,8000047cd,7c6a431a53
and crases as follows:
terminate called after throwing an instance of 'renumber_t::corrupted_table'
what(): Renumber table is corrupt: cannot find p=0x47cd, r=0x15bc44f7 on side 1 ; NOTE that this p is not prime, which is very unexpected. See bug #30048