[GiNaC-devel] Crash during startup
Chris Dams
C.Dams at science.ru.nl
Fri Jan 7 11:14:04 CET 2005
Dear Richy,
On Thu, 6 Jan 2005, Richard B. Kreckel wrote:
> 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.
Ah! Now, after some thinking, I think I understand it. _ex0 is initialized
at the point when utils.o is initialized, which may well be after
integral::relative_integration_error is intialized.
> 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...
Well, it makes me wonder why there is such a thing as a library_init.
After all, it appears that just writing
ex integral::relative_integration_error = 1e-8;
is also allowed. Why is not that done for all static objects, such as
_ex0? The only thing is that other static objects, should not be using
_ex0, as I did with my .evalf(). As far as I understand library_init was
introduced to solve this "problem", however is the problem solvable at
all? After all, _ex0 exists because it is initialized in some *.o file
and, I think, it should not be initialized in multiple *.o files, because
that would cause errors for multiple definitions. Since nobody appears to
be guaranteeing anything about the order in which the different *.o files
are intialized, _ex0 should not be used in a static object anywhere, no
matter what kind of initialization gymnastics you are going to add to
this.
> 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.
>
> +ex integral::relative_integration_error = 1e-8;
Fine with me!
Best wishes,
Chris
More information about the GiNaC-devel
mailing list