[lmi] "Stack overflow" resolved [Was: Restructuring code that...]

[Greg Chicares]

On 2019-02-22 03:12, Greg Chicares wrote:
[...]
> Unfortunately, I've run into a problem. Today I added a couple dozen new
> products that are to be introduced later this year, and now 'make install'
> fails as follows on this line
>       @cd $(datadir); $(PERFORM) $(bindir)/product_files$(EXEEXT)
> of its recipe:
> 
> wine: Unhandled stack overflow at address 0x6d0d37fc (thread 01db), starting 
> debugger...
> 01db:err:seh:setup_exception_record stack overflow 880 bytes in thread 01db 
> eip 7bc2baed esp 007b0f
> 
> 'product_files$(EXEEXT)' is a 32-bit msw binary that doesn't use SEH, so I
> think the "seh:setup_exception_record" part must indicate a defect in 'wine'
> rather than in 'product_files$(EXEEXT)'.

My current theory is that this was an actual overflow in my 32-bit
msw binary (obscured by being wrapped in a 'wine' SEH message).

The proprietary 'my_db.cpp' and 'my_prod.cpp' files are both
enormous. In the time of gcc-3.4.5, I saw this message:
   warning: NULL pointer checks disabled:
   39933 basic blocks and 167330 registers
which I was able to suppress by specifying '-O0' (i.e., forbid
optimization).

Now those files have grown even larger, and '-O0' failed with the
"stack overflow" above. I tried '-Os' instead, and got:

.../src/my_prod.cpp:1362:6: note: variable tracking size limit
 exceeded with -fvar-tracking-assignments, retrying without
 void product_data::write_proprietary_policy_files()
      ^~~~~~~~~~~~

Although a "note" isn't an error even with '-Werror', it still
offends my sensibilities, so I used '-fno-var-tracking-assignments'
to suppress it.

Now here's something weird. The diagnostics for each file were
  my_db.cpp  : "stack overflow"
  my_prod.cpp: "variable tracking size limit exceeded"
with '-O0'; but with '-O2 -fno-var-tracking-assignments', there
are no diagnostics at all. Which of those two flags prevented
the stack overflow at run time? Testing both separately shows
that it's '-O2'. Thus, '-O2' or '-Os' (above) prevent the stack
overflow, which occurs only with '-O0'. Thus, for gcc-3.4.5
(with an older version of this code), forbidding optimization
('-O0') was a necessary workaround; but today that workaround
has become the real problem ("stack overflow"), and the new
workaround is to *require* optimization.