Re: [lmi] "Stack overflow" resolved

[Greg Chicares]

On 2019-02-23 13:53, Vadim Zeitlin wrote:
> On Sat, 23 Feb 2019 13:23:29 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Without testing under native msw, we can't know for sure whether the
> GC> "stack overflow" was in 'product_files.exe' or in 'wine'. But if it
> GC> was in 'product_files.exe' as I conjecture, then it's not at all the
> GC> kind of stack overflow I normally encounter (infinite recursion due
> GC> to a coding mistake)--instead, it's the result of pushing N bytes
> GC> onto an M-byte stack where N was just slightly less than M last week,
> GC> but exceeded M after I added new products this week. I think this
> GC> would be the first time I've ever seen a non-infinite stack overflow.
> 
>  It does happen when using huge arrays, are there any local variables of
> array types in this code?

That depends on whether "array types" include...
  - char const  a[] = "array of char";
  - char const* b   = "C string";
  - std::string c   = "C++ string-class instance";
I'd suppose that the first two are "arrays" in this sense, but that the
third is not because its memory is on the heap; but maybe the third
actually is, too, because its initializing literal, "C++ string-class
instance" above, occupies space in the program (even though I'd have
thought it occupied "const" space separate from the stack segment).

What I really observe is the transgression of two limits:

(1) In 'my_prod.cpp' only, the soft VTA limit is exceeded (causing the
compilation to restart without VTA, unless '-fno-var-tracking-assignments'
is specified) because of a large number of 'static' strings like this:
  static std::string const AgeDefinition = "Age at end of policy year.";
There are no large "arrays" other than such strings, in any of the
sources for this program.

(2) After the program is compiled and linked with no warnings, a hard
stack limit is exceeded, and there's no recourse except to use some
kind of optimization (i.e., the problem occurs only with '-O0'). The
stack overflow occurs only at run time, and I imagine that a single stack
limit applies to the totality of all linked object files.

>  FWIW, "huge" means "megabytes". MSVC is relatively stingy with its default
> size of only 1MB for the thread stack, but I believe gcc allocates more
> than that by default, although I can't find any confirmation to this right
> now. You could try using -Wl,--stack,XXX option to change the default to
> something bigger.
That's good to note in case such a problem reappears later. For now,
'-Os -fno-var-tracking-assignments' seems sufficient.