C176_3270_692 and C179_2340_732, both 32 bit jobs, will be done sieving soon. Are these cases potentially big enough to trigger the bug?

I call it the large dataset bug but I suspect it doesn't have much to do with the problem size; Lionel already saw it happen to him (and IIRC it's not the first time).

Anyway, if you could use SVN 967 just check the log to find out if if there are any complaints about relations with composite factors.

Nope, both (G)C_2_757 and GW_7_270 were done with msieve SVN r965 in the end, because of bugs in r966.
I've just restarted GW_7_270 from scratch, with r967.

EDIT:
[code]skipped 69 relations with b > 2^32
skipped 642 relations with composite factors
found 24480704 hash collisions in 129671815 relations
commencing duplicate removal, pass 2
found 23217839 duplicates and 106453976 unique relations
[/code]
So it looks like relations with composite factors are not really exceptional, at least in this dataset.

5748.1526 done
 

[code]
Sat Jun 28 01:45:49 2014 prp78 factor: 312935226620923943366796906694320131630742297293116531778729844839818946576767
Sat Jun 28 01:45:49 2014 prp97 factor: 4706148622674847377279670108472687483089920336495222703038330665692716768270924929192931822688829
[/code]

Log at [url]http://pastebin.com/3103seyV[/url]

This was substantially over-sieved, producing an 8.8M matrix which took 36 hours on six threads of i7/4930K.

3270.692 started
 

This was even more over-sieved and has produced an 8.6M matrix; I'm using SVN956 and (with target density 120) it does not appear to have triggered the bug. Expect factors Tuesday evening.

GC_3_478 done
 

[code]
Sat Jun 28 01:47:40 2014 prp84 factor: 419749724240264594750273462385802484149003953802414199316978290718145318035754042303
Sat Jun 28 01:47:40 2014 prp135 factor: 160624828002047087175210094855180374890231008589254196908646504295214859609172873184354004755088787137729480298753821480922392488663061
[/code]

57 hours for 7.9M matrix (target_density=120) on i7/2600 -t3

Log at [url]http://pastebin.com/vVf244Er[/url]

GW_11_219 slight delay
 

GW_11_219 failed to filter first time (target_density=120 was optimistic), so didn't run over the weekend. Refiltering at density 100 worked; 7.9M matrix, results Thursday morning.

GW_7_270 completed without a hitch with msieve SVN r967.

Great, thanks. Could you also rerun the filtering for GC_2_757, and just check that the LA starts? Did you change anything to get the postprocessing above to work correctly?

[quote]Could you also rerun the filtering for GC_2_757, and just check that the LA starts?[/quote]
Yes, I can do that. I haven't erased either dataset (raw + added free relations) on my side, though I'll do after the new run for GC_2_757 completes, as it's a shared server and I'm already by far the largest disk space user in my $HOME :smile:

[quote]Did you change anything to get the postprocessing above to work correctly?[/quote]
Nope, it was the same, standard msieve invocation each time:
[code]ionice -c3 ~/msieve/msieve -i GW_7_270.ini -s GW_7_270.dat.gz -nf GW_7_270.fb -nc target_density=90 -v -t 4[/code]
The msieve binary is built with MPI support, but that doesn't matter here.


I have just expanded the range for GC_7_292 even further up, but an additional 30M range could well still be insufficient, due to the expected high duplicate ratio being high indeed:
[code]...
found 35618667 duplicates and 75002098 unique relations
...
begin with 75002098 relations and 78568994 unique ideals
reduce to 33918994 relations and 31853499 ideals in 25 passes
...
begin with 33918994 relations and 40937480 unique ideals
reduce to 33818823 relations and 40837273 ideals in 18 passes
max relations containing the same ideal: 200
filtering wants 1000000 more relations
[/code]

What about the run for C_2_257 that succeeded above? The first attempt failed in a very characteristic way and then factors appeared :)