Free pointer in Helib

[lepro09]

i' using Helib to compute keys, encrypt and decrypt some vectors. I really appreciate the help of this library. I was just want to signal a small bug in it. Each time i use certain function s like encrypt, decrypt in Helib, the random access memory grows and even when i leave the context in which these operations are done, the memories are not release. I supposed, it is just some pointers which are not released after their use.

Greets, Gil

[TomMD]

"\forall code \exists space leak" isn't horribly useful from a debugging standpoint. To be honest, given the track-record of the bug reports on this repository my knee-jerk reaction is to assume a misuse of the library or C++ (which isn't very fair or charitable, I know). Could you provide us with a test case? Short of a starting point, such as code that should be constant space but continues to grow, I don't expect to see progress here.

[lepro09]

`

   // Encryption parameters
FHEcontext* aContext;
EncryptedArray* encArray;
FHESecKey* aSecKey;
FHEPubKey* aPubKey;

    for(int i = 0; i < 10; i++)
    {
    long m = 0, p = 2, r = 1;
    long w = 64;
    ZZX G;
    long L = 4;          // Levels
    long c = 3;           // Columns in key switching matrix
    long d = 0;
    long security = 128;
        // using the fucntion FindM(...) in the FHEContext module
    m = FindM(security, L, c, p, d, 0, 0);
        aContext = new FHEcontext(m, p, r);
    // initialize context
    buildModChain(*aContext, L, c);
    // modify the context, adding primes to the modulus chain
    G = aContext->alMod.getFactorsOverZZ()[0];

       encArray = new EncryptedArray(*aContext, G);
   aSecKey = new FHESecKey(*aContext);
   aSecKey->GenSecKey(w);
   addSome1DMatrices(*aSecKey);

   aPubKey = new FHEPubKey(*aSecKey);

      delete aContext;
      delete encArray;
      delete aSecKey;
      delete aPubKey; 
   }

` Insert the code above in a main. Set a break point at the for loop and start a task manager to control the memory space used by the code. You can now debug the code and see how even after deleting the pointer declared, the memory grows after each round.

[victorshoup]

That is more helpful. Perhaps you could help us by narrowing things down a bit more. For example, you build G and then build an EncryptedArray. What happens if you leave that out? Do you still see the same phenomenon?

To be honest, I think it is safe to say that most of our heavy testing was done with a single context and public key. So it would not be a complete shock if we overlooked something there.

On Aug 22, 2016, at 11:55 AM, lepro09 wrote:

`

// Encryption parameters FHEcontext* aContext; EncryptedArray* encArray; FHESecKey* aSecKey; FHEPubKey* aPubKey;

for(int i = 0; i < 10; i++)
{
long m = 0, p = 2, r = 1;
long w = 64;
ZZX G;
long L = 4;          // Levels
long c = 3;           // Columns in key switching matrix
long d = 0;
long security = 128;
    // using the fucntion FindM(...) in the FHEContext module
m = FindM(security, L, c, p, d, 0, 0);
    aContext = new FHEcontext(m, p, r);
// initialize context
buildModChain(*aContext, L, c);
// modify the context, adding primes to the modulus chain
G = aContext->alMod.getFactorsOverZZ()[0];

   encArray = new EncryptedArray(*aContext, G);

aSecKey = new FHESecKey(_aContext); aSecKey->GenSecKey(w); addSome1DMatrices(_aSecKey);

aPubKey = new FHEPubKey(*aSecKey);

  delete aContext;
  delete encArray;
  delete aSecKey;
  delete aPubKey; 

}

` Insert the code above in a main. Set a break point at the for loop and start a task manager to control the memory space used by the code. You can now debug the code and see how even after deleting the pointer declared, the memory grows after each round.

� You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[victorshoup]

OK. I ran your program on my linux machine, making the main loop run forever, and watching things using htop. VERT and RES bounce around a bit, but do not actually increase at all over time. There may be certain places in helib and NTL where small amounts of memory are allocated and will not be released until the thread is terminated, which is maybe what you are seeing. But I do not think this is a problem.

On Aug 22, 2016, at 11:55 AM, lepro09 wrote:

FHEcontext* aContext; EncryptedArray* encArray; FHESecKey* aSecKey; FHEPubKey* aPubKey;

for(int i = 0; i < 10; i++)
{
long m = 0, p = 2, r = 1;
long w = 64;
ZZX G;
long L = 4;          // Levels
long c = 3;           // Columns in key switching matrix
long d = 0;
long security = 128;
    // using the fucntion FindM(...) in the FHEContext module
m = FindM(security, L, c, p, d, 0, 0);
    aContext = new FHEcontext(m, p, r);
// initialize context
buildModChain(*aContext, L, c);
// modify the context, adding primes to the modulus chain
G = aContext->alMod.getFactorsOverZZ()[0];

   encArray = new EncryptedArray(*aContext, G);

aSecKey = new FHESecKey(_aContext); aSecKey->GenSecKey(w); addSome1DMatrices(_aSecKey);

aPubKey = new FHEPubKey(*aSecKey);

  delete aContext;
  delete encArray;
  delete aSecKey;
  delete aPubKey; 

}