segmentation fault on GiNaC-1.2.0 using MinGW on Win XP
Hi, I'm not subscribed to this list, but I have detected a problem with the new release of GiNaC, which I would like to report. After properly building GiNaC-1.2.0 on windows XP using the MinGW / MSYS platform I got a segmentation fault on starting my demo application. This didn't happen with GiNaC-1.1.7. After looking to the source code I found a problem with the current implementation: In file uitils.cpp the following constants are defined: _num0_p _num0 _ex0 These are initialized on behalf of constructor library_init() which is called by statement static library_init library_initialize from file ex.h (line 53). The constructor function_options::function_options(std::string const & n, std::string const & tn) in file function.cpp (line 56) calls function initialize() (line 67 )which has a statement symtree = 0; in its implementation (line 82). Symtree is of type ex which is initialized by ex(int) which calls basic & ex::construct_from_int(int i) in file ex.cpp (line 329). The relevant line is case 0: return const_cast<numeric &>(_num0); Reference counting, now, forces usage of operator-> on the _num0 object. Now, here is the problem: It may happen that the construtor of function_options() is called before the call of library_init(). function_options() is called during registration of class container by statement GINAC_DECLARE_REGISTERED_CLASS(container, basic) in file container.h (line 130). The construction order of static objects in different translation units is undefined in C++. Therefore the problem may or may not show up. With kind regards and a lot of respect Johannes
On Mon, 5 Apr 2004, Johannes Brunen wrote:
I'm not subscribed to this list, but I have detected a problem with the new release of GiNaC, which I would like to report.
After properly building GiNaC-1.2.0 on windows XP using the MinGW / MSYS platform I got a segmentation fault on starting my demo application. This didn't happen with GiNaC-1.1.7.
After looking to the source code I found a problem with the current implementation:
In file uitils.cpp the following constants are defined: _num0_p _num0 _ex0
These are initialized on behalf of constructor library_init() which is called by statement static library_init library_initialize from file ex.h (line 53).
The constructor function_options::function_options(std::string const & n, std::string const & tn) in file function.cpp (line 56) calls function initialize() (line 67 )which has a statement symtree = 0; in its implementation (line 82).
Symtree is of type ex which is initialized by ex(int) which calls basic & ex::construct_from_int(int i) in file ex.cpp (line 329). The relevant line is case 0: return const_cast<numeric &>(_num0);
Reference counting, now, forces usage of operator-> on the _num0 object. Now, here is the problem: It may happen that the construtor of function_options() is called before the call of library_init(). function_options() is called during registration of class container by statement GINAC_DECLARE_REGISTERED_CLASS(container, basic) in file container.h (line 130).
The construction order of static objects in different translation units is undefined in C++. Therefore the problem may or may not show up.
Congratulations on your excellent analysis. Well, the fix has been applied to CVS already: <http://down.physik.uni-mainz.de/cgi-bin/viewcvs.cgi/GiNaC/ginac/function.pl.diff?r1=1.86&r2=1.86.2.1&cvsroot=ThEP> Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi! On Mon, Apr 05, 2004 at 10:32:03PM +0200, Richard B. Kreckel wrote:
Congratulations on your excellent analysis. Well, the fix has been applied to CVS already: <http://down.physik.uni-mainz.de/cgi-bin/viewcvs.cgi/GiNaC/ginac/function.pl.diff?r1=1.86&r2=1.86.2.1&cvsroot=ThEP>
I'm beginning to have doubts whether this is the proper fix, because:
On Mon, 5 Apr 2004, Johannes Brunen wrote:
It may happen that the construtor of function_options() is called before the call of library_init(). function_options() is called during registration of class container by statement GINAC_DECLARE_REGISTERED_CLASS(container, basic) in file container.h (line 130).
Isn't library_init() supposed to solve all problems of this kind by being the first static object to appear in any compilation unit? library_init() is declared in ex.h which is the first file included from container.h, so it can't come from there. And the GiNaC class registry doesn't use function_options, so I don't understand why the declaration of container<> would create a function_options object. The only compilation units creating function_options are the various inifcns*.cpp files which include inifcns.h -> function.h -> exprseq.h -> container.h -> ex.h and should see library_init() before any function_options. Did I overlook something? Bye, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/
participants (3)
-
Christian Bauer
-
Johannes Brunen
-
Richard B. Kreckel