-   GMP-ECM (
-   -   GMP-ECM 6.2.1 exit with 0xc00000fd (

yoyo 2009-03-26 21:59

GMP-ECM 6.2.1 exit with 0xc00000fd
on the Boinc ecm system I have now some ecm curves, which exit with above exit code. My impression is that this more often the case when I run big numbers. The below example run numbers with 58000 digits. I use the gmp-ecm 6.2.1 core2 win64 version from [url=]Jeff[/url] for this.

[url=]This workunit[/url] crashed until now on 2 systems, [url=]system1[/url], [url=]system2[/url]. Both system are running Microsoft Windows Server 2003 "R2".
[url=]Here you can see command line, input and generated output.[/url]

[url=]Here a second workunit[/url] which crashed in the same way on 2 systems. But now one system is Windows Vista.
The 2 systems:
Command line, input, output:

Any idea what can be the problem?
The output file of all 4 tries stopped at the same point, so it seems they crashed on the same step in phase 2.

kind regards,

akruppa 2009-03-26 22:43

Looks like it's crashing when it's trying to reduce the product polynomial... I think that's a point where a larger product is computed than during the other steps, so temporary memory allocation for Schönhage-Strassen may be the culprit. The systems are listed as having 8GB, which would be plenty, but not all of that may be available to the process. Is there a way of testing whether it works with a larger -k parameter, say -k 8?

I'm running it on my home machine in the meantime to see what happens, and how much memory it needs at least to run successfully (the estimate printed by GMP-ECM may be way off if the Kronecker-Schönhage trick with Schönhage-Strassen multiplication is used, as these functions allocate gobs of temp memory by themselves).


yoyo 2009-03-27 20:37

I made an request to my users in the forum that they should do some tests.
thanks for the hint.

akruppa 2009-03-28 00:53

I tested how much memory stage 2 for this number needs by gradually reducing the max VM size with ulimit. With 920MB it works, with 910MB it segfaults, but in the first "Computing G * H" step - earlier than the Windows binary did. Still, running out of memory seems like the most likely cause. The result from a test with larger k would be interesting.


yoyo 2009-03-28 08:55

Here are [url][/url] a first test result.
With -k 8 it seems to work and estimates only half of the memory before.

Andi47 2009-03-28 09:56


I just got this error when clicking the link:


There seems to be a problem with the security certificate (is this the correct translation for german "Sicherheitszertifikat"?) - it might have expired?

yoyo 2009-03-28 10:16

Just use it without 's'

Your browser does not have the CAcert root certifikate.

yoyo 2009-03-30 17:34

with -k 8 how much does it reduce the memory requirements in phase 2?

akruppa 2009-03-30 17:47

Pretty exactly by a factor of 2. The default value for k was 2, and if you want to reduce the polynomial degree (memory use is mostly proportional to that polynomial degree) by a factor of [I]x[/I], you need to multiply k by [I]x[/I][sup]2[/sup].


yoyo 2009-03-31 08:46

Hi Alex,
I'm wondering that for B1=50k and a number with 58000 digits where the memory estimation is ~ 1GB the application finishes with 0xc00000fd.
But with B1=43M and much shorter number where memory estimation is 2GB the application does not finish with 0xc00000fd.
Is there any explanation for it?
I'm asking because I'll try to figure out in which work units I should insert -k 8. My first idea is to make it in all workunits where the estimated memory is greater than 1GB.

akruppa 2009-03-31 10:47

With large numbers, stage 2 uses the Kronecker-Schönhage trick for reducing polynomial multiplication to integer multiplication, and Schönhage-Strassen for the integer multiplication. Unfortuantely both steps need a lot of temporary memory. With small numbers, stage 2 uses an NTT for the polynomial multiplication instead which uses far less memory, but (in its current implementation) is very slow when used with large input numbers. (Technical note: reduction wrt to the NTT primes and CRT is qudratic time atm, and initialisation of the NTT primes is cubic time! :redface: Yes, it's on our infinite TO-DO list, about half-way down)


All times are UTC. The time now is 18:53.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.