I am playing with NTL, and come across a core dump issue which is related with NTL::ZZX
variable:
(gdb) p msg
$2 = (NTL::ZZX &) @0x7fff680601f0: {rep = {_vec(long double,...)( *) = {rep = 0xab629d0}}}
The NTL::ZZX
actually contains one member, rep
:
class ZZX {
public:
vec_ZZ rep;
......
ZZ& operator[](long i) { return rep[i]; }
const ZZ& operator[](long i) const { return rep[i]; }
......
}
The vec_ZZ
is a vector (not std::vector
, NTL::Vec
instead) in fact:
typedef Vec<ZZ> vec_ZZ;
The error occurs when getting the 8191-st
element. Unfortunately, I can’t use gdb
to access the element in vector directly:
(gdb) p i
$3 = 8191
(gdb) p msg[i]
You can't do that without a process to debug.
After referring this doc, it gives me the idea that seems be the gdb
‘s limitation of accessing container. So I try to access the member straightaway.NTL::Vec
is just a template class containing one public member:
template<class T>
class Vec {
public:
......
WrappedPtr<T, _vec_deleter> _vec__rep;
......
};
While WrappedPtr
is nothing but another template class:
template<class T, class Deleter>
class WrappedPtr {
......
public:
typedef T * raw_ptr;
raw_ptr rep;
......
}
We can see the rep
member in WrappedPtr
points to the start address of the content in vector. Read the 8191-st
element’s value:
(gdb) p sizeof(*msg.rep._vec__rep.rep)
$23 = 8
(gdb) x/16xb msg.rep._vec__rep.rep+8191
0xab729c8: 0x77 0x01 0x00 0x00 0x00 0x00 0x00 0x00
0xab729d0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
The valid value should be a memory address, 0x177
is definitely not. So the next thing is to find out why this isn’t correct …
NTL::ZZX does not store leading ‘0’s.
Try to access the coefficient with ‘NTL::coeff(ZZX, index)’ (I hope I type it right)