Quote from: Wolf0 on June 07, 2016, 03:23:32 AM

Quote from: joblo on June 06, 2016, 06:53:08 PM

Quote from: hmage on June 06, 2016, 06:47:43 PM

Quote from: joblo on June 06, 2016, 06:46:19 PM

But the problem is only on Windows, oh well.

msys comes with gdb, it should be able to catch the segfault, then you can inspect the registers, stack and variables.

Compiling with "-O0 -g3" instead of "-O3" should help gdb give you more info.

Tried that. Compile fails in another algo with -O0 asm has impossible constraints.

Use -ggdb3 and step through it.

Progress. If ___chkstk_ms is checking for stackoverflow then I know what the problem is.

Looking for solutions, looks like a Makefile.am edit.

Edit: doubling the stacksize spec in Makefile.am didn't work.

if HAVE_WINDOWS
#cpuminer_CFLAGS += -Wl,--stack,10485760
cpuminer_CFLAGS += -Wl,--stack,20971520
endif

Edit2: I couldn't find any documentation for --stack so I don't know what makefile is doing.

I found -fno-stack-limit but it still crashes at the same place.

I know it's crashing in ___chkstak_ms and I assume that means a stack overflow. A corrupt stack
pointer should not occur in compiled code.

From my experience the stack limit is fixed when the process is created, I'm not aware of any way to
increase that after process creation so there must be some overriding limit beyond the scope of the compiler.

Most of the info I found deals with limiting the stack, not growing it. It seems infinite recursion is a bigger
issue than legitimate large stack use.