[GiNaC-devel] Crash during startup

[Qin An]

Hi,

   The patch  written by Chris can fix the problem that I posted on  28 Dec 2004, right?
   Because I found that the cause for that error is not only setting the compiler option -fexceptions...

Best wishes,
-Qin An

 
>On Thu, 6 Jan 2005, Chris Dams wrote:
>> > Chris, I'm afraid you introduced a new static initialization order problem
>> > when you sent us your integral.cpp file.  You cannot initialize static ex
>> > integral::relative_integration_error like you do in integral.cpp:206.
>>
>> Hmmm... Wait a minute... If I understand correctly, this means that
>> initialization of integral::relative_integration_error occurs before the
>> initialization of the library_init of the same file integral.o as well as
>> before the initialization of all other library_init objects in all GiNaCs
>> other object files. Isn't this a bit strange???
>
>Now that you mention it...
>
>>                                                 I mean, can't the runtime
>> environment (or whatever it is called) just initialize static objects in
>> the same order as they are defined in the preprocessed C++-code???
>
>Sure.  The language guarantees exactly that.
>
>>                                                                    If the
>> order of static initialization were the same as the order of definition
>> were the same, there would not be a problem, right?
>
>Right.
>
>But wait a minute!  The problem comes from ex::is_zero() const in
>ex.h:208:  There we have the inline member function
>
>    bool is_zero() const { extern const ex _ex0; return is_equal(_ex0); }
>
>But have a look at utils.cpp.  Initialization jumps from all the modules
>that include ex.h into the ctor of library_init and there all the numeric
>objects are initialized.  But _ex0 is declared above that ctor and it is
>not initialized until the module utils.o is initialized itself!  Just the
>jumps into that ctor do not as a by-product initialize all the static
>objects.
>
>If that analysis is correct there appears to be a loophole in the
>initialization order scheme.  I wonder how that can be fixed without
>creating a big mess in utils.cpp...
>
>> > Would you please be so kind and sent a patch to this list for my review?
>>
>> I would suggest the change in the attached patch, since the functions that
>> are used in this patch do not seem to involve any static variables.
>> Unfortunately I do not know how to test this, because at my place no crash
>> occured in the first place. Do you think this is sufficient to avoid a
>> crash in all cases?
>
>Your patch seems to work, thanks a lot!  The patch below seems to fix the
>problem just as well.  By virtue of ex::construct_from_double(double) it
>should be equivalent to your patch.  If you have no objections, I'll
>commit it.
>

>diff -a -u -r1.2 integral.cpp
>--- integral.cpp        14 Oct 2004 15:36:45 -0000      1.2
>+++ integral.cpp        6 Jan 2005 21:31:23 -0000
>@@ -203,7 +203,7 @@
> }
>
> int integral::max_integration_level = 15;
>-ex integral::relative_integration_error = power(10,-8).evalf();
>+ex integral::relative_integration_error = 1e-8;
>
> ex subsvalue(const ex & var, const ex & value, const ex & fun)
> {
>
>Best wishes
>  -richy.
>--