Tag: NTL

Be ware of HElib and corresponding NTL versions

Today I tested an old HElib version (back to mid-2017), but met following compile errors:

......
In file included from EncryptedArray.cpp:15:
EncryptedArray.h:301:19: error: ‘FHE_DEFINE_LOWER_DISPATCH’ has not been declared
  301 |   NTL_FOREACH_ARG(FHE_DEFINE_LOWER_DISPATCH)
      |                   ^~~~~~~~~~~~~~~~~~~~~~~~~
EncryptedArray.h:303:3: error: ISO C++ forbids declaration of ‘NTL_FOREACH_ARG’ with no type [-fpermissive]
  303 |   const RX& getG() const { return mappingData.getG(); }
      |   ^~~~~
......

After some investigation, I found the problem was the NTL on my system is too new (version is 11.3.2). So I downloaded an old NTL version, and specified using this version in Makefile:

CFLAGS = -g -O2 -std=c++11 -I../../ntl-10.5.0/include ......

Then it worked like a charm!

Linking error of _ntl_gbigint_body in using NTL

I use NTL on ArchLinux, and there is a struct _ntl_gbigint_body which is actually not defined (refer this post):

/*
 * This way of defining the bigint handle type is a bit non-standard,
 * but better for debugging.
 */

struct _ntl_gbigint_body;
typedef _ntl_gbigint_body *_ntl_gbigint;

You should pay attention to functions who depend on this struct, such as:

void _ntl_gcopy(_ntl_gbigint a, _ntl_gbigint *bb)

Because for old NTL library, the function prototype generated by compiler is _ntl_gcopy(void*, void**):

$ readelf -sW libntl.so | c++filt | grep ntl_gcopy
2511: 000000000012b750   184 FUNC    GLOBAL DEFAULT   12 _ntl_gcopy(void*, void**)

While for new one it is _ntl_gcopy(_ntl_gbigint_body*, _ntl_gbigint_body**):

$ readelf -sW libntl.so | c++filt | grep ntl_gcopy
615: 0000000000148500   202 FUNC    GLOBAL DEFAULT   11 _ntl_gcopy(_ntl_gbigint_body*, _ntl_gbigint_body**)

So if you meet linking error as following:

undefined reference to `_ntl_gcopy(void*, void**)'

It should be NTL header files and library mismatch. The header files are old, while library is new.

A performance issue about copy constructor

These two day, I debugged a performance issue which is related to copy constructor: the class A has a member b which is NTL::ZZX type:

class A
{
    enum class type {zzx_t, ...} t;
    NTL::ZZX b;
    ......
}

When member t‘s value is zzx_t, b is valid. Otherwise b‘s content should be outdated.

There are 2 methods of implementing A‘s copy constructor:
(1)

A(const A& other) : t(other.t), b(other.b)
{
    ......
}

In this method, NTL::ZZX‘s copy constructor is called in spite of anything.

(2)

A(const A& other) : t(other.t)
{
    ......
    if (t == zzx_t)
    {
        b = other.b;
    }
    .....
}

In this case, NTL::ZZX‘s default constructor is called first. NTL::ZZX‘s copy assignment operator is invoked only if “t == zzx_t” condition is met.

NTL::ZZX‘s default constructor nearly does nothing, and copy constructor does approximate work as copy assignment operator. But in our scenario, t‘s value is not zzx_t at 80 percent of the time. So the second implementation of copy constructor gets a big performance boost compared to first one.

Postmortem of NTL::Vec type

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 …