Re: [lmi] Possible bug with configurable_settings and --data_path option

[Greg Chicares]

Some prefatory comments may be in order. It's imperative that lmi produce
the same numerical output from the same input on different machines, as
much as is feasible. I rather doubt that FYL2XP1 produces perfectly
identical results for all arguments on all intel chips, but overcoming the
silicon is not feasible. However, with at least some msw versions, loading
a "foreign" dll can cause the FPU control word to change; controlling
that is feasible, so we must control it. This problem has occurred in at
least one real-world case.

On 2014-12-16 21:11, Vadim Zeitlin wrote:
> 
>  This is a minor problem, which is probably not very important in practice,
> but I just wanted to describe it here for future reference in case anybody
> else (or maybe I myself, after forgetting everything about this) runs into
> it again.
> 
>  So, the bug happens if:
> 
> 1. The file /etc/opt/lmi/configurable_settings.xml doesn't exist.
> 2. The --data_path option is used on the command line.
> 
> Then, and, AFAICS, contrary to the expectations, the program looks for the
> file configurable_settings.xml in the current directory and not in the
> directory specified by the --data_path option.

Yes, I've observed that. My brute-force workaround was to copy it from the
expected directory to the one where it works. I always suspected it was a
static-initialization problem; but "the work of science is to substitute
facts for appearances and demonstrations for impressions", so I'm glad to
learn your findings.

>  This happens because configurable_settings object is initialized before
> the command line option processing takes places. To be precise, it
> is instantiated by MswDllPreloader::PreloadDesignatedDlls() which is itself
> called before wxEntry() (both in the main application and in the GUI test).
> 
>  Does MswDllPreloader::PreloadDesignatedDlls() really need to be called at
> this early stage? If this isn't a hard requirement, I could provide a
> simple patch postponing the call to it until the command line options are
> parsed, but if it is I don't see any way to fix this easily and so, taking
> into account that it's not really a big problem in practice, I won't try to
> fix this in the latter case.

I'm afraid it's an instance of the "which came first, the chicken or the egg"
problem. We want MswDllPreloader to do its work before any "foreign" dll can
be loaded. We want its list of dlls-to-preload to be configurable. We chose
to use 'configurable_settings.xml' for that purpose. Therefore, we wind up
with this problem.

My "impression" (cf. the Ruskin quote above) is that the FPU control-word
problem has arisen because of some "foreign" dll unknown to lmi that hooks
the system file-open dialog. But I don't know where else such a beast could
inject itself, so I invoke MswDllPreloader before wxEntry(): that's the
only safe assumption AFAICS.

We don't have a reproducible test case. The only concrete test case we have
is to run lmi on a particular w2k machine that belonged to another company
that's a thousand miles away. Thus, we can't readily test changes. Any
change we make would have to pass a rigid code inspection. The only way I
can see to do that is to choose a different file to hold the list of dlls
to preload. Arguably we should have done it that way years ago, but we
didn't, and now it seems like a daunting job of refactoring.

But maybe you're less easily daunted, and I don't want to discourage you
from trying to fix this. I suppose we could create a 'dll_preload.xml'
file in the same place as 'configurable_settings.xml' and use it instead.
Kim's out until after Christmas, and I can't be sure about this without
asking her, but I *think* our binary distributions always create a
"C:\etc\opt\lmi" directory, and if so it would be good enough to look
there only, and not in any alternative location. So maybe this isn't so
daunting after all. And it would be nice to fix this problem. What do
you think?