[CLN-list] Segfault when using univpoly

Richard B. Kreckel kreckel at ginac.de
Tue Mar 8 16:13:53 CET 2005


On Tue, 8 Mar 2005, Ralf Goertz wrote:
> > What system is this?  Please submit the output of `uname -a', the output
> > of `g++ -v' and also the way you configured CLN (CXXFLAGS and such).
>
> I would have given the details in my previous mail, but I thought I could
> figure out myself what the problem was. But I failed... :-(
>
> -------
> uname -a
> Linux big 2.6.8-24.11-default #1 Fri Jan 14 13:01:26 UTC 2005 i686 athlon i386
> GNU/Linux
>
> g++ -v
> Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.4/specs
> Configured with: ../configure --enable-threads=posix --prefix=/usr
> --with-local-prefix=/usr/local --infodir=/usr/share/info
> --mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada
> --disable-checking --libdir=/usr/lib --enable-libgcj
> --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib
> --with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux
> Thread model: posix
> gcc version 3.3.4 (pre 3.3.5 20040809)
>
> CXXFLAGS="-Wall -O2 -fno-exceptions" ./configure --with-gmp
>
> but also
>
> ./configure --with-gmp
>
> ----------------------
>
> SuSE has a history of prematurely using new versions of gcc. But I haven't
> been coding very much lately, therefore I'm not up to date with the current
> development.

Yes, I vaguely remember a problem of this kind.  But I am under the
impression that it was with an earlier compiler.  Which version of SuSE is
this?

Anyway, regarding your original problem: I've been chasing my tail for a
while to find the memory leak that making the dtor non-virtual must surely
introduce (because those objects _are_ deleted by base-pointer).  Well, it
turns out there isn't one, because none of the dtors seems to be doing
something special and simply freeing the memory is enough.  Still, I would
like that to be _really_ fixed.

I think the final patch will just make cl_heap_modint_ring and
cl_heap_univpoly_ring (and their subclasses) nonvirtual, too.  But in
addition I'll introduce an additional cl_class object for each of those
subclasses and store it in the type field (just as usual) while taking
care that the dtor is hooked in the cl_class objects.  That should cure
it.

I have no idea why the vptr was introduced.  We have all the
infrastructure we need by virtue of cl_class.  Why not use it?

Regards
  -richy.
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>





More information about the CLN-list mailing list