GMP-ECM crash

[Jeff Gilchrist]

Originally Posted by ATH

That's great! You found the cause of the bug. When you are done I'll try to get the latest SVN and compile. Last program I tried for windows to get SVN repository wasn't so good. Can I use msys/mingw to get latest SVN?

The Windows tool that I use and find very useful is TortoiseSVN, a nice GUI and everything: http://tortoisesvn.net/downloads.html

I'm not sure if there is svn for mingw, but you can get it for cygwin so you could do it that way as well.

[rogue]

Originally Posted by Jeff Gilchrist

The Windows tool that I use and find very useful is TortoiseSVN, a nice GUI and everything: http://tortoisesvn.net/downloads.html

I'm not sure if there is svn for mingw, but you can get it for cygwin so you could do it that way as well.

I use RapidSVN for OpenPFGW on Windows. It has a usable U/I.

[Jeff Gilchrist]

Ok, looks like I found some values that work with -k1 so now I will do a bit more testing with some Release mode binaries to make sure it still works with all three -k values and if yes, let you know what the stack size settings are and release a new binary for people.

[henryzz]

What is the disadvantage in increasing the stack size? If nothing then we should increase well above what we need as we will just run into the problem again.

[Jeff Gilchrist]

Originally Posted by henryzz

What is the disadvantage in increasing the stack size? If nothing then we should increase well above what we need as we will just run into the problem again.

The program needs more memory to run, which might be noticeable if you are using small inputs for ECM but large ones where ECM is using hundreds or thousands of MB of RAM I doubt it would have much effect.

It seems to be stable with -k1 using 32KB commit, and 6MB reserve. To give some extra room for other inputs, I could use 64K commit and 8MB reserve. I will try to see if I can actually measure any memory usage differences between them.

[Jeff Gilchrist]

Ok, so it looks like everything is running fine now and there wasn't any real measurable difference between the 32KB/6MB and 64KB/8MB stack sizes (maybe 100K difference) so these are the settings I'm using:

Stack Reserve Size: 8388608
Stack Commit Size: 65536

Brian, can you please update the VS project file to use those stack sizes to put in gmp-ecm's SVN repository?

I will release a new set of binaries soon.

Jeff.

[ATH]

Is this only fixed for the Visual Studio project files? or can I compile it with mingw64 as well?

[Jeff Gilchrist]

Originally Posted by ATH

Is this only fixed for the Visual Studio project files? or can I compile it with mingw64 as well?

It is a compiler issue so my changes are only "fixing" the Visual Studio project. Considering your mingw64 builds worked with -k3 by default, gcc probably uses a larger stack size than VS by default. You would have to look up in the gcc manual to see what the defaults are and how to set a larger stack size.

In UNIX, you can actually set the stack use using ulimit -s right inside the shell, not sure if you can do the same in the msys shell or not, so don't need to recompile, just change the shell parameters before you run.

Jeff.

[Jeff Gilchrist]

Before I make a full release, can a couple of you (especially lavalamp and ATH) please try this Windows 64bit Core2 based binary to make sure it also works fine for you?

You can download it from here:
http://gilchrist.ca/jeff/factoring/ecm_test.zip

Thanks,
Jeff.

[ATH]

I'll test it tonight when I get home.

Can anyone with a deeper understanding of gcc help me with how to increase stack size as Jeff suggest in post #39.

Is it these 2 options I need to use?

-mpreferred-stack-boundary=num
Attempt to keep the stack boundary aligned to a 2 raised to num byte boundary.
If ‘-mpreferred-stack-boundary’ is not specified, the default is 4 (16 bytes or
128 bits).
-mincoming-stack-boundary=num
Assume the incoming stack is aligned to a 2 raised to num byte boundary.
If ‘-mincoming-stack-boundary’ is not specified, the one specified by
‘-mpreferred-stack-boundary’ will be used.
On Pentium and PentiumPro, double and long double values should be
aligned to an 8 byte boundary (see ‘-malign-double’) or suffer significant run
time performance penalties. On Pentium III, the Streaming SIMD Extension
(SSE) data type __m128 may not work properly if it is not 16 byte aligned.
To ensure proper alignment of this values on the stack, the stack boundary must
be as aligned as that required by any value stored on the stack. Further, every
function must be generated such that it keeps the stack aligned. Thus calling
a function compiled with a higher preferred stack boundary from a function
compiled with a lower preferred stack boundary will most likely misalign the
stack. It is recommended that libraries that use callbacks always use the default
setting.
This extra alignment does consume extra stack space, and generally increases
code size. Code that is sensitive to stack space usage, such as embedded systems
and operating system kernels, may want to reduce the preferred alignment to
‘-mpreferred-stack-boundary=2’.

[WraithX]

Originally Posted by ATH

I'll test it tonight when I get home.

Can anyone with a deeper understanding of gcc help me with how to increase stack size as Jeff suggest in post #39.

Is it these 2 options I need to use?

I don't think those are the options you need. I found online that you can increase the stack size of an application at compile time with an appropriate option passed to gcc's linker (ld). It looks like this for a regular compile:
gcc -Wl,--stack,16777216 -o file.exe file.c

Or, with gmp-ecm, you can configure it with LDFLAGS like so:
./configure CFLAGS="options" LDFLAGS="-Wl,--stack,16777216"

These commands increase the Stack Reserve Size of the compiled application to 16MB. Unfortunately, this command line option (-Wl) can't change the Stack Commit Size. I'm not 100% sure the LDFLAGS option is correct. I tried it two different ways and make and 'make check' passed both times. Maybe both ways work, or maybe only one is correct, I'm not sure how to check the stack size of an executable, and I have to leave for work. So, the two different LDFLAGS to try are:
LDFLAGS="-Wl,--stack,16777216"
LDFLAGS="-Wl,--stack=16777216"

Hopefully we can find out which way is correct and how to find out what the actual stack size of an executable is.