Re: [lmi] product editor patch

[Greg Chicares]

On 2008-02-08 23:36Z, Vaclav Slavik wrote:
> Greg Chicares wrote:
>> another latent logic error. If you want to look into this
>> before I get the chance, then I bet you could reproduce the
>> error by adding a line like
>>   warning() << "You won't see this!" << std::flush;
>> anywhere that it's sure to be executed.
> 
> I tried putting this right under "Generating product files." in 
> generate_product_files.cpp, but with no luck.

Try this patch [0] instead, in your local copy. Mine should mirror
yours exactly except for this patch. From what I'm seeing [1], it
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.

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.

> It triggers the error 
> on Linux (because Automake makefiles don't link alert_cli.o in), but 
> everything still works correctly on Windows for me. Would you have a 
> backtrace showing where the error occurred (i.e. not where the 
> exception is reported in main())? I can only think of some global 
> object being initialized before alerts are, but I can't find 
> anything...

I felt sure it was a global-initialization-order problem, but I think
the patch below shows otherwise. I'll paste a backtrace below [2], but
I don't think it's helpful: gdb has a distressing habit of pointing
into standard headers when it can't figure out the real source line.

Everything "works" as expected if I revert 'stratified_charges.cpp'
to the HEAD revision (it remains compatible because you didn't alter
anything that was already in its header). So I tried narrowing the
issue down with {'#if 0', #endif} pairs, and the "problem" seemed
to be in
  stratified_entity::check_limits_non_decreasing_order()
on this line
        previous = *it;
which, however, looks perfect.

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.

---------

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

Index: my_tier.cpp
===================================================================
RCS file: /sources/lmi/lmi/my_tier.cpp,v
retrieving revision 1.10
diff -u -2 -r1.10 my_tier.cpp
--- my_tier.cpp 1 Jan 2008 18:29:51 -0000       1.10
+++ my_tier.cpp 10 Feb 2008 03:11:26 -0000
@@ -42,4 +42,5 @@
 #include "stratified_charges.hpp"

+#include "alert.hpp"
 #include "data_directory.hpp"

@@ -60,4 +61,14 @@

     // Another policy form....
+warning() << "If you see this, mustn't the fn ptrs have been set?" << 
std::flush;
+    stratified_charges goo(foo);
+  try
+    {
+    warning() << "First there is a mountain..." << std::flush;
+    goo.write(AddDataDir("goo.tir"));
+    warning() << "...then there is no mountain..." << std::flush;
+    }
+  catch(...)
+warning() << "...then there is" << std::flush;
 }

[1] My output with patch [0]: just a screen copy, not reformatted.

/lmi/src/lmi[0]$make product_files.exe && /lmi/src/build/lmi/CYGWIN_NT-5.1/gcc/s
hip/product_files.exe
/MinGW_/bin/g++ -MMD -MF my_tier.d0  -c -I /lmi/src/lmi -I /opt/lmi/wx-scratch/w
xWidgets-2.8.7/gcc344/lib/wx/include/msw-ansi-release-2.8 -I /opt/lmi/wx-scratch
/wxWidgets-2.8.7/include -I /opt/lmi/wx-scratch/wxWidgets-2.8.7/contrib/include
-I /opt/lmi/third_party/include -I /usr/local/include -I /usr/local/include/libx
ml2 -I /opt/lmi/third_party/include -I /opt/lmi/local/include -I /opt/lmi/local/
include/libxml2 -DLMI_WX_NEW_USE_SO  -DLIBXML_USE_DLL -DSTRICT    -DWXUSINGDLL -
D__WXMSW__ -mno-cygwin -DBOOST_STRICT_CONFIG   -pedantic-errors -Werror -Wall -W
cast-align -Wconversion -Wdeprecated-declarations -Wdisabled-optimization -Wimpo
rt -Wmultichar -Wpacked -Wpointer-arith -Wsign-compare -Wundef -Wwrite-strings
-Wno-long-long -std=c++98 -Wctor-dtor-privacy -Wdeprecated -Wnon-template-friend
 -Woverloaded-virtual -Wpmf-conversions -Wsynth  -W -Wcast-qual -Wredundant-decl
s  -Wno-uninitialized    -ggdb -O2   /lmi/src/lmi/my_tier.cpp -omy_tier.o
/bin/sed -e :a -e '/\\$/N; s/\\\n//; ta' -e 'h' -e 's/^[^:]*: *//' -e 's|$| :|'
-e 'G'   < my_tier.d0 > my_tier.d; /bin/rm my_tier.d0;
/MinGW_/bin/g++ -o product_files.exe alert.o alert_cli.o fenv_lmi.o main_common.
o main_common_non_wx.o sigfpe.o generate_product_files.o my_db.o my_fund.o my_pr
od.o my_rnd.o my_tier.o xenumtypes.o liblmi.dll -L . -L /opt/lmi/third_party/lib
 -L /opt/lmi/third_party/bin -L /usr/local/lib -L /usr/local/bin -L /opt/lmi/loc
al/lib -L /opt/lmi/local/bin   -lxslt.dll -lxml2.dll      -mno-cygwin    -Wl,-Ma
p,product_files.exe.map -Wl,--disable-auto-import
Generating product files.
If you see this, mustn't the fn ptrs have been set?
First there is a mountain...
Not all alert function pointers have been set.
...then there is

All product files written.

/lmi/src/lmi[0]$

[2] A gdb backtrace, from before patch [0]. Here I had changed
some other stuff (which I later reverted), like adding
  asm("int $3"); // trap to debugger
right before the
  "Not all alert function pointers have been set."
message. I didn't go back and redo the backtrace because I don't
think it'll be helpful, but I can redo it anyway if you want.

Program received signal SIGTRAP, Trace/breakpoint trap.
alert_buf (this=0x1045cb24)
    at C:/MinGW-20050827/bin/../lib/gcc/mingw32/3.4.4/../../../../include/c++/3.
4.4/ext/new_allocator.h:62
62            new_allocator() throw() { }
(gdb) bt
#0  alert_buf (this=0x1045cb24)
    at C:/MinGW-20050827/bin/../lib/gcc/mingw32/3.4.4/../../../../include/c++/3.
4.4/ext/new_allocator.h:62
#1  0x1002a343 in fatal_error () at /lmi/src/lmi/alert.cpp:188
#2  0x101dd929 in stratified_charges::write (this=0x22fe60,
    address@hidden)
    at C:/MinGW-20050827/bin/../lib/gcc/mingw32/3.4.4/../../../../include/c++/3.
4.4/ostream:193
#3  0x0047501e in stratified_charges::write_proprietary_stratified_files ()
    at C:/MinGW-20050827/bin/../lib/gcc/mingw32/3.4.4/../../../../include/c++/3.
4.4/ext/new_allocator.h:62
#4  0x00403d45 in try_main () at /lmi/src/lmi/generate_product_files.cpp:54
#5  0x0040392f in main (argc=0, argv=0x0)
    at /lmi/src/lmi/main_common_non_wx.cpp:56
(gdb)