PR #337 adds a –with-ecmult-gen-precision=8 which puts >672kb onto the stack during gen_context or at runtime in signing context creation if –disable-ecmult-static-precomputation is also used.
Default stacks being 8MB is mostly a 64-bit linux distroism.
I expect this gen_context and context create with no statick precomp now crashes with that config on some systems. I believe the default stack on Windows is 1MB, linux kernel code stack size is 8kb, 32-bit linux default stack size is 2MB. Lots of other systems have a modest default stack. IIRC firefox multimedia threads have a 128kb stack.
And, of course, whatever stack the library uses is added onto the caller, so it pays to be pretty conservative.
The commit message seems to indicate that valgrind was telling you that the stack was out of control. You probably don’t want to ignore that– the valgrind default setting is the amount needed for 32-bit linux to not barf, some other systems as I mention are even more constrained.
For normal usage this library shouldn’t put more than a few kilobytes onto the stack. There is an issue which specifies making the stack usage explicit (#188). I suppose allowances could be made for weird configs like –disable-ecmult-static-precomputation + –with-ecmult-gen-precision=8, but even there doing well over 100kb will probably start crashing real programs on real systems.
Tests could probably get away with a fair bit more, since they control the entire calling stack and aren’t going to cause mysterious runtime crashes– but it would still be nice to be able to run them directly on the sort of low memory devices that can run the library.