Re: [lmi] product editor patch

[Greg Chicares]

On 2008-02-10 03:36Z, Greg Chicares wrote:
[...]
> looks almost as though
>  - first the "alert" function pointers must have been set,
>  - then somehow they "became unset",
>  - then they became set again.
> But that strains belief. It seems more like they're set when we're in
> the app, but not when we're in the dll--yet they reside in the dll.

Unless they reside in both places.

They reside in 'alert.o'. It looks like we're linking that object
file in the dll as well as in the app. Then, I guess, the app
initializes the pointer in its own copy of the object file, and
the dll tries to report runtime errors by dereferencing the
pointer in its own copy of the object file.

> This is a command-line app. In the wx app, "alert" messages like these
> are displayed okay--that has worked great for years--and the dll is
> shared by both command-line and wx apps.

The wx app has only one copy of the object file, in a dll.

>> It triggers the error 
>> on Linux (because Automake makefiles don't link alert_cli.o in), but 

Is that the old problem where, IIRC, the linker optimizes it out
of existence?

>> everything still works correctly on Windows for me.

Because you're linking the public version, and I'm linking a
proprietary version, of 'my_tier.cpp'. That's okay under the GPL,
BTW, because the resulting binary is never distributed. So your
binary has no runtime error to report, but mine does.

I think this also explains your earlier observation that using
an "alert" in the app's main module failed to reproduce the
problem: I guess I should have suggested doing that in the dll.

> Everything "works" as expected if I revert 'stratified_charges.cpp'
> to the HEAD revision

Because the HEAD revision lacks the extra consistency checks that
you've added, so it has no runtime error to report.

> So now I'm wondering whether we've got a libstdc++ problem: e.g.,
> failure to copy an empty std::map. I seem vaguely to recall a case
> where a default ctor for some container produced an object that
> was not empty, but actually uninitialized.
         ^merely

Nope. I had thought it might be the copy ctor...

> [0] Patch to make problem reproducible. In essence: copy an
> object, then call its write() function.

...but that's not the explanation for the immediate issue.
It might help explain why the program desires to report a
runtime error, but not why the attempt to report it failed.

> /MinGW_/bin/g++ -o product_files.exe alert.o alert_cli.o fenv_lmi.o 
> main_common.
                                       ^^^^^^^

There's the app's extra copy of the object file.

Before moving on, I'd like to consider whether we might have
similar problems elsewhere, and whether we can turn this into
a link-time error so that we'll never meet it at run time again.
But right now I must turn to some high-priority tax stuff that
might take a few more days.