[lmi] Restructuring code that generates '.database' files; and a 'wine' failure [Was: Why is this taxonomy not a DAG?]

[Greg Chicares]

On 2019-02-11 18:29, Vadim Zeitlin wrote:
> On Mon, 11 Feb 2019 15:12:20 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> I need to implement a set of products with an "inheritance" graph
> GC> like this (suspend any disbelief that we descend from fish):
> GC> 
> GC>           +Mermaid+
> GC>           |       |
> GC>        +Human+    Gills
> GC>        |     |
> GC>      +Fish+  Lungs
> GC>      |    |
> GC>   Animal  Gills

Having spent most of the last two weeks refactoring a five-thousand-line C++
function that generates over one hundred '.database' files, I've come to
suspect that multiple inheritance isn't the most appropriate technique.

The original monolithic code had evolved linearly as products were added since
1998--e.g., for one particular subgroup (proprietary names obfuscated):

 --2001-2003--   ----------2006---------    -----2009----- ...
 tier2   tier1   tier1    tier2    tier3    tier1    tier2
  w00  -> x1 -> x06t1 -> x06t2 -> x06t3 -> x09t1 -> x09t2 ...

However, the evolution is not linear: it's a tree, not a chain, and I've
broken it into classes like this:

 ----2001-2003---      --2006-      --2009-       --2013-    2017
  w00  -> x01base  ->  x06base  ->  x09base   ->  x13base ->  y00
             |            |            |              |        |
 tiers:   x01,x03t1    x06t1,2,3    x09t1-3,x12t1-4  ...      ...

You can see a similar though tinier restructuring in commit 2f458a6779.

> GC> I can see many ways to get the desired result. I was just hoping that
> GC> C++'s multiple inheritance would work because it affords such a compact,
> GC> readable framework for expressing the graph.
> 
>  Well, I'd like to mildly but decisively disagree with this. I could go
> into more details if you'd like but to summarize, I think that using
> inheritance is good for simple class hierarchies and the above is already
> not really simple and I suspect that the actual thing you're trying to
> model is even more complicated. So it certainly looks to me that something
> more flexible, i.e. composition/aggregation, would be more suitable here.
A single-inheritance tree has worked quite well so far--though I've yet to
restructure the most complex product group, for which something like
composition or aggregation might prove helpful.

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)'.

I'm confident that there's nothing wrong with the new products that I just
added, because I can reproduce the error if I remove all that new code and
then duplicate an older line in that proprietary code (which corresponds to
this line:
    sample2xyz  ().WriteDB(AddDataDir("sample2xyz.database"));
in commit 2f458a6779) about half a dozen times. However, I can't reproduce
it by duplicating that 'sample2xyz' line in the public code, even if I
duplicate it one hundred times. (By "duplicate", I really do mean
  yy
  100p
in 'vim' terms.)

Tonight I upgraded to "wine-4.0 (Debian 4.0-1)" (the latest in debian-buster)
from the old "rc6" that I had been using, but the error still occurs.

An online search for the error message finds many articles, most of which
pertain to graphical games and video drivers. Only this one seems applicable:
  https://bugs.winehq.org/show_bug.cgi?id=45199
but I tried some of its suggestions, and the error still occurs:
 - I'm already compiling this TU with '-O0'
 - 'WINEDEBUG=relay' doesn't help either
Even this debug setting:
  WINEDEBUG=warn+all wine /opt/lmi/bin/product_files.exe
doesn't show anything that seems useful--but then again it wouldn't, not if
the problem is a defect in 'wine' itself.

Using 'winecfg' to choose a different msw version for this binary also
doesn't help. (I didn't test every one, but I tried {XP, 7, 8, 8.1, 10}).

I speculate that the program might run without error on native msw, but that
can't be tested until next week; and it wouldn't be much comfort anyway,
because I'm not putting any proprietary OS on my machine.

I think the next step is to try a 64-bit msw build. Any better ideas?