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

[Vadim Zeitlin]

On Fri, 22 Feb 2019 23:00:37 +0000 Greg Chicares <address@hidden> wrote:

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

 I didn't have time to try this yet, but if this is indeed the case, I
should be seeing it under native MSW, right? Would you like me to test this
assumption or is it better to skip testing it to avoid disappointment if
the result doesn't conform to our expectations? If so, could you please
make available your binary somewhere so that I could run it?

GC> The proprietary 'my_db.cpp' and 'my_prod.cpp' files are both
GC> enormous.

 Can I ask the obvious question: what prevents you from splitting them into
several parts?

GC> In the time of gcc-3.4.5, I saw this message:
GC>    warning: NULL pointer checks disabled:
GC>    39933 basic blocks and 167330 registers
GC> which I was able to suppress by specifying '-O0' (i.e., forbid
GC> optimization).
GC> 
GC> Now those files have grown even larger, and '-O0' failed with the
GC> "stack overflow" above. I tried '-Os' instead, and got:
GC> 
GC> .../src/my_prod.cpp:1362:6: note: variable tracking size limit
GC>  exceeded with -fvar-tracking-assignments, retrying without
GC>  void product_data::write_proprietary_policy_files()
GC>       ^~~~~~~~~~~~
GC> 
GC> Although a "note" isn't an error even with '-Werror', it still
GC> offends my sensibilities, so I used '-fno-var-tracking-assignments'
GC> to suppress it.

 OK, it looks -fvar-tracking-assigment (about whose existence I had been
blissfully unaware until today) is enabled by default by -Os and so it
makes sense to disable it if it doesn't work anyhow.

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

 It's a bit surprising that unoptimized code dies with a stack overflow,
which normally happens when there is deep recursion which the compiler
shouldn't be able to optimize anyhow, but I guess it may be possible...

 Regards,
VZ