Re: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP
Hi Christian, I second your doubts. I think that the problem is a little more hidden. After I added some print statements into the library_init's constructor I could confirm that this function is called before the call of function_options::initialize() function, as it was intended. However, the initilaization of the const _num0 reference happens at some time later. Therefore it is undefined at the point of usage in the ex::construct_from_int(int i) call from function_options::initialize(). At the point of _num0 initialization the counter has already a value of count == 33. I still think that the problem lies in the initialization order of statics defined in different translation units. Unfortunately, I couldn't find an exact explanation of my guess. With best regards Johannes
Hi! On Wed, Apr 07, 2004 at 01:28:29PM +0200, Johannes Brunen wrote:
However, the initilaization of the const _num0 reference happens at some time later. Therefore it is undefined at the point of usage in the ex::construct_from_int(int i) call from function_options::initialize().
Ah, of course. This explains it. The ex() default ctor uses _num0_bp directly, so static ex objects are always initialized correctly as long as you're only using the default ctor. Maybe the ex::construct_from_*() functions should also use the _num*_bp pointers instead of the references? Bye, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/
Hi! On Thu, 8 Apr 2004, Christian Bauer wrote:
On Wed, Apr 07, 2004 at 01:28:29PM +0200, Johannes Brunen wrote:
However, the initilaization of the const _num0 reference happens at some time later. Therefore it is undefined at the point of usage in the ex::construct_from_int(int i) call from function_options::initialize().
Ah, of course. This explains it. The ex() default ctor uses _num0_bp directly, so static ex objects are always initialized correctly as long as you're only using the default ctor.
The joy of the initializion order! It all looks so correct until you realize that the const references themselves aren't initialized yet while the objects they're supposed to reference are already initialized. This is pervert. I still do hope that the C++ Committee does see the light some lucky day and realize that they can do a great favor to the language and its community by simply demanding that if dependencies form a DAG, then that DAG shall be established by the linker. AIX seems to do it. Patches for GNU ld to that effect have been suggested. It's so obviously the correct thing to do! Rather, they say nothing. The GNU folks then say the order is determined by the link line. Hahaha! Very funny. I have 855 modules in CLN. Under no circumstances am I going to manually arrange that link line. This problem is definitely the most irritating issue of C++. It is also the issue most insistently dodged by the Standard Committee.
Maybe the ex::construct_from_*() functions should also use the _num*_bp pointers instead of the references?
Definitely. Basically, this was the situation in the GiNaC 1.1 tree. I have applied a patch on GiNaC-1.2 and HEAD to that effect. FYI: I've also undone the previous patch in function.pl, since it isn't needed anymore and the original version (albeit equivalent) seems to make the intent clearer. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
"Richard B. Kreckel" <kreckel@ginac.de> writes: | Hi! | | On Thu, 8 Apr 2004, Christian Bauer wrote: | > On Wed, Apr 07, 2004 at 01:28:29PM +0200, Johannes Brunen wrote: | > > However, the initilaization of the const _num0 reference happens at some | > > time later. Therefore it is undefined at the point of usage in the | > > ex::construct_from_int(int i) call from function_options::initialize(). | > | > Ah, of course. This explains it. The ex() default ctor uses _num0_bp | > directly, so static ex objects are always initialized correctly as long | > as you're only using the default ctor. | | The joy of the initializion order! | | It all looks so correct until you realize that the const references | themselves aren't initialized yet while the objects they're supposed to | reference are already initialized. This is pervert. :-/ | I still do hope that the C++ Committee does see the light some lucky day | and realize that they can do a great favor to the language and its | community by simply demanding that if dependencies form a DAG, then that | DAG shall be established by the linker. AIX seems to do it. Patches for | GNU ld to that effect have been suggested. It's so obviously the correct | thing to do! Rather, they say nothing. The GNU folks then say the order | is determined by the link line. Hahaha! Very funny. I have 855 modules | in CLN. Under no circumstances am I going to manually arrange that link | line. This problem is definitely the most irritating issue of C++. It is | also the issue most insistently dodged by the Standard Committee. I think that the committee level, the question is what can we do about this without falling into describing a particular implementation. At the "GNU folks" level, I think the issue is different :-) You said, patches have been suggested for GNU ld, do you have some reference handy? -- Gaby
On 14 Apr 2004, Gabriel Dos Reis wrote:
"Richard B. Kreckel" <kreckel@ginac.de> writes: [...] | I still do hope that the C++ Committee does see the light some lucky day | and realize that they can do a great favor to the language and its | community by simply demanding that if dependencies form a DAG, then that | DAG shall be established by the linker. AIX seems to do it. Patches for | GNU ld to that effect have been suggested. It's so obviously the correct | thing to do! Rather, they say nothing. The GNU folks then say the order | is determined by the link line. Hahaha! Very funny. I have 855 modules | in CLN. Under no circumstances am I going to manually arrange that link | line. This problem is definitely the most irritating issue of C++. It is | also the issue most insistently dodged by the Standard Committee.
I think that the committee level, the question is what can we do about this without falling into describing a particular implementation.
At the "GNU folks" level, I think the issue is different :-) You said, patches have been suggested for GNU ld, do you have some reference handy?
Bruno, may I ask if you still have that old patch for GNU ld mentioned in the cln/modules.h comment lying around somewhere? If so, it would be interesting to have a look at it and see if it is still useful. Luck -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Richard B. Kreckel wrote:
Bruno, may I ask if you still have that old patch for GNU ld mentioned in the cln/modules.h comment lying around somewhere? If so, it would be interesting to have a look at it and see if it is still useful.
The patch is certainly outdated; however the comments at the end of Ian Lance Taylor's reply should still be useful. What is the "full runtime dependency analysis, done by the compiler", that he is talking about? Bruno
participants (5)
-
Bruno Haible
-
Christian Bauer
-
Gabriel Dos Reis
-
Johannes Brunen
-
Richard B. Kreckel