[QUOTE=jasonp;346099]Do you mean the 32-bit binary from sourceforge? My development machine is a core 2 so that's surprising. Or do you mean one of the binaries Jeff hosts?[/QUOTE]
Jeff's latest. The one compiled by Brian.

[QUOTE=jasonp;346095]The --large-address-aware option is only to get a 32-bit binary to have a 3GB virtual address space, it's useless if you want a full 64-bit binary. Filtering is not threaded, so that doesn't matter here.

If you're willing to use gdb, the core of the singleton removal is in a single function and I can try to help you figure out what's going on there. We can take it to email if you're game; if using MinGW64 is the problem, then it would be nice to have another working build option in windows. The other possibility is to try using one of Microsoft's free compilers to build the source without ECM; even if it still doesn't work, you have a nicer symbolic debugger that can help figure out what's going on.[/QUOTE]

Yeah, the single threaded case was the same. Also, even with the updated MinGW64 I just downloaded I still get the same problem. I'd definitely like to see if we can get this to work correctly with MinGW64. I'll send you a PM with my email address. Also, I hope we have access to a smaller example to try to help speed up the troubleshooting process. It takes about 25 minutes before this one starts "singleton removal, initial pass" and then it takes about another 25 minutes before it starts "in-memory singleton removal".

[QUOTE=henryzz;346098]Ecm crashes for me in the latest binary as well. I assume it tries to use an instruction that my core 2 doesn't support.[/QUOTE]

Are you sure that its not the assertion failure that I am seeing when msieve calls the ecm library (see my report earlier)?

EDIT: I have just compiled and run the latest version of msieve compiled without GMP-ECM on a small example and it runs fine. So we need to figure out why there is an assertion failure in GMP-ECM when called from msieve. I have not yet worked out the parameters that msieve uses to call GMP-ECM but it would be useful to call GMP-ECM natively with these inputs to see whether the problem still occurs.

[QUOTE=Brian Gladman;346105]Are you sure that its not the assertion failure that I am seeing when msieve calls the ecm library (see my report earlier)?

EDIT: I have just compiled and run the latest version of msieve compiled without GMP-ECM on a small example and it runs fine. So we need to figure out why there is an assertion failure in GMP-ECM when called from msieve. I have not yet worked out the parameters that msieve uses to call GMP-ECM but it would be useful to call GMP-ECM natively with these inputs to see whether the problem still occurs.[/QUOTE]
It might be.

Assertion failure in MSIEVE call to the GMP-ECM library
 

I have posted this on the GMP-ECM developers forum but I am duplicating it here in case anyone might be able to work out what is going wrong.

-----------------------------------------------------------------------------
I would appreciate advice on an assertion failure that is invoked when the GMP-ECM library is called from MSIEVE:

Assertion failed: __ecm_eulerphi (params->P) == params->s_1 * params->s_2, file
..\..\pm1fs2.c, line 2902

I have tracked this down to the parameters B2min_parm, B2_parm and B2scale in the call to pm1 on line 441 in the file pm1.c. These are respectively -1, -1 and 0.0

As a result of lines 476 ..482:

if (ECM_IS_DEFAULT_B2(B2))
mpz_set_d (B2, B2scale * pow (B1 * PM1FS2_COST,
PM1FS2_DEFAULT_B2_EXPONENT));

/* set B2min */
if (mpz_sgn (B2min) < 0)
mpz_set_d (B2min, B1);

B2 gets set to 0, whereas B2min gets set to 0x4e20. Now B2 is less than B2min and as a result the function choose_P on line 552 of pm1fs2.c does not set the P, s_1 and s_2 parameters in the faststage2_param_t structures. In consequence the call at line 708 in pm1.c

youpi = pm1fs2_ntt (f, x, modulus, &params);

is entered without the P, s_1 and s_2 set and the assertion failure is consequently raised.
-----------------------------------------------------------------------------

[QUOTE=Brian Gladman;346147]I have posted this on the GMP-ECM developers forum but I am duplicating it here in case anyone might be able to work out what is going wrong.[/QUOTE]

Hello Brian, I'm not sure if this is the correct fix for the problem, but I think it is worth trying out to see if it will work in general. In the file:
msieve-trunk/common/smallfact/gmp_ecm.c
[CODE]
Can you change the value on line 215 from:
tmp->stage_1_done = 1.0;
To:
tmp->stage_1_done = 1.001;[/CODE]
This change should allow B2scale to be > 0 and therefore give B2 a chance to be greater than 0. (You could also try 1.01 or 1.1)

I say this because of the following code in gmp-ecm\factor.c lines 133-137:
[CODE]
/* Ugly hack to pass B2scale to the library somehow. It gets piggy-backed
onto B1done. The next major release will have to allow for variable
length parameter structs. */
B1done = floor (p->B1done);
B2scale = (p->B1done - B1done) * 1048576.;[/CODE]

[QUOTE=WraithX;346156]Hello Brian, I'm not sure if this is the correct fix for the problem, but I think it is worth trying out to see if it will work in general. In the file:
msieve-trunk/common/smallfact/gmp_ecm.c
[CODE]
Can you change the value on line 215 from:
tmp->stage_1_done = 1.0;
To:
tmp->stage_1_done = 1.001;[/CODE]
This change should allow B2scale to be > 0 and therefore give B2 a chance to be greater than 0. (You could also try 1.01 or 1.1)

I say this because of the following code in gmp-ecm\factor.c lines 133-137:
[CODE]
/* Ugly hack to pass B2scale to the library somehow. It gets piggy-backed
onto B1done. The next major release will have to allow for variable
length parameter structs. */
B1done = floor (p->B1done);
B2scale = (p->B1done - B1done) * 1048576.;[/CODE][/QUOTE]

Thanks for your input WraithX - a value of 1.001 fixed it.

I had the feeling that B2scale ought to be greater than zero and the 'ugly hack' raised my suspicions still further :smile:

I'll wait for Jason to confirm this change before I update the msieve SVN, after whiich I will let Jeff have an updated binary.

Please do. I wonder if this change was made necessary by using a more recent release of GMP-ECM...

[QUOTE=jasonp;346182]Please do. I wonder if this change was made necessary by using a more recent release of GMP-ECM...[/QUOTE]

It is quite likely since a lot of work was done fairly recently.

I have now updated the msieve SVN and sent a new binary to Jeff to host.

If anyone is desperate to have a copy, I could post it as an attachment here but I am not sure how the the mods feel about fairly large attachments.

The new version is now available on my website:
[url]http://gilchrist.ca/jeff/factoring/[/url]

Don't forget to download the Visual C++ 2012 Redistributable binary first if you don't already have it. There is now a link to that too at the top of the page.

Jeff.

I downloaded the svn915 from Jeff's site a little while ago. Unfortunately, even this version of msieve crashed on me while working on L1911. This time it crashed on me in a slightly different place. I'm attaching the log to see if anyone can see what might have been the problem this time.

At this point, I'm not sure if the Windows builds can handle large jobs. I'm still trouble shooting my MinGW64 build. It turns out that it works just fine on a GNFS139 I had sitting on my hard drive. That only had a 3.02GB dat file. However, neither my MinGW64 nor Brian's Visual Studio build have worked on the L1911 24GB dat file. I think they read in all of the relations just fine, there just seem to be strange problems after that.

If anyone here has a 4.01GB, maybe up to 5-6GB, dat file (plus the .fb and .ini files too) laying around for a job they've done, I'd like to download it and do some testing locally to see how Windows msieve handles that. If someone does have something like that, can you post here where ever you upload it, or PM me details on where I can download it? That would be much appreciated.