[GiNaC-devel] Crash during startup

Chris Dams C.Dams at science.ru.nl
Mon Jan 24 11:35:04 CET 2005


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




More information about the GiNaC-devel mailing list