Re: Error while opening libgcrypt key handle to check password strength: gcrypt/Out of memory

Hello,

> [...]
> > Aborting due to exception: Error creating archive layers: Error while 
> > opening libgcrypt key handle to check password strength: gcrypt/Out of 
> > memory
> > Final memory cleanup
> > Error creating archive layers: Error while opening libgcrypt key handle 
> > to check password strength: gcrypt/Out of memory
> > 
> > ---
> > 
> > With the standard version installed on my linux opensuse 16.0 (dar 
> > 2.7.15) I have no problems.
> > 
> > Any suggestion?
> > Thanks in advance
> 
> Yes, this looks like the know problem reported at github and currently 
> still under investigations:
> 
> https://github.com/Edrusb/DAR/issues/70
> 
> This is not simple: at first I had to increase the stack size because of 
> the musl library I used to build dar_static (musl replacing the glibc 
> which does not well support static library, for that I had to use 
> voidLinux distro). This solved some issues, but still remains the 
> twofish algorithm that does not work using several thread, but works 
> when using only a single thread. Thus if you are using this encryption 
> algo with dar_static you currently need to add "-G 1,n" option, where n 
>  >=1 and is the number of thread you want to use for 
> compression/decompression. What encryption algo are you using?
> 
> I added a parameter to specify the amount of secured memory reserved by 
> dar at library initialization, as well as another to specify the stack 
> size to use for libdar threads... depending on the outcome of problem I 
> will merge these "features" either to the branch_2.8.x or to the master 
> (dev) code... Anyway adding ashamed big amount of secured memory and 
> stack size does not solve the issue, but helps on some points.
> 
> Currently I moved to a fresh Debian trixie install (thus using glibc as 
> standard C library) and found yesterday that libssh should not be 
> compiled relying on libcrypto to solve this issue. But I have still to 
> add some other dependencies, one by one, then test, eventually recompile 
> them... so it takes time.
> 
> Can you try -G 1,n option and tell me if that workaround works for you?
> 
> Thanks,
> Denis

I'm using aes256 (-K aes:...) compression.
I just tried with -G 1,6 and worked. If I set -G 2,2 the "Out of memory" error occours.
Many thanks for the quick solution!