Re: [GiNaC-devel] Crash during startup
Dear Chris, On Thu, 20 Jan 2005, Chris Dams wrote: [...]
Okay, I can reproduce it now. The placement news that occured in my last patch appears to solve something, but not everything. Another problem are the refences _num_25 and so on. When are these going to be initialized? By the linker, I suppose.
Hmmm, good question.
At least that would explain the point at which I am seeing segfaults now.
Are you saying your patch still segfaults?
But how is the linker supposed to know where memory is going to be allocated? Here's a patch that also throws the references out of the library.
Could you please explain what you're doing in plain English? I'm sure we'll all get some better understanding of the issues this way. Anyways, you got me slabbing my forehead really hard with your way of cheerfully writing (_num0_p = new numeric(0))->setflag(status_flags::dynallocated); instead of the more convoluted _num0_p = static_cast<const numeric*>(&((new numeric(0))->setflag(status_flags::dynallocated))); This looks good. Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Dear Richy, On Sun, 23 Jan 2005, Richard B. Kreckel wrote:
At least that would explain the point at which I am seeing segfaults now.
Are you saying your patch still segfaults?
No, fortunately, I do not see segfaults at the moment.
But how is the linker supposed to know where memory is going to be allocated? Here's a patch that also throws the references out of the library.
Could you please explain what you're doing in plain English? I'm sure we'll all get some better understanding of the issues this way.
Well, the idea is of course that after the constructor of libary_init has done its job all the _num_whatever_p's, _num_whatever's and _ex_whatever's are in a usable state and are not touched again. Since the _ex_whatever's are made during static initialization of utils.o, this is not the case for these. Therefore we need placement new as in new((void*)&_ex_120) ex(*_num_120_p); inside the libary_init constructor to produces usable exes. Then, when the time comes that utils.o gets initialized, it would be best if these exes were not touched. I do this by the dirty trick of self-asignment (or rather, construction from self) as in const ex _ex120 = _ex120 Of course, now the number of references to these exes will be 2, but never mind, the OS will hopefully reclaim memory at program exit. After I had this, I still saw segfaults. Debugging told me that the point where the segfault occured was the use of one of the references such as _num_120. (I do not remember anymore where it was precisely.) This made me wonder when these are initialized. I concluded that this would most likely be done by the linker, since this is possible in cases like the one in utils.cpp. Unfortunately it will make the references refer to the numeric located at NULL. Furthermore, even if they are initialized during static initialization, this is too late, because they should be initialized by the constructor of libary_init. I decided to throw the references out alltogether, since it is quite possible to write *_num_120_p instead of the reference. This leads to a zillion rewrites everywhere. Best wishes, Chris
Dear Chris, On Mon, 24 Jan 2005, Chris Dams wrote: [...]
inside the libary_init constructor to produces usable exes. Then, when the time comes that utils.o gets initialized, it would be best if these exes were not touched. I do this by the dirty trick of self-asignment (or rather, construction from self) as in
const ex _ex120 = _ex120
Hmm, so this is not DR 363 because _ex120 has been initialized before? <http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_closed.html#363>. Anyway, I'm getting convinced that your code is valid... Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Dear Richy, On Tue, 1 Feb 2005, Richard B. Kreckel wrote:
const ex _ex120 = _ex120
Hmm, so this is not DR 363 because _ex120 has been initialized before?
Well it looks like this "DR 363" to me. With the small detail that _ex120 has sneakily been initialized before... ;-).
<http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_closed.html#363>. Anyway, I'm getting convinced that your code is valid...
Well, I had some doubts about const ex _ex120 = _ex120; myself but the compiler did not mind. Now looking at this link, it appears that even the standardization committee likes it :-). Best wishes, Chris
participants (2)
-
Chris Dams
-
Richard B. Kreckel