> > On Fri, 19 Jul 2019 09:40:13 +0200 > Vittorio Mori <email@example.com> wrote: > > > Hello everyone. > > Hi! > > > I have an issue compiling the ZPAQ compressor/archive utility from Matt Mahoney. > > Do we have this package in our repository or is it something you built > yourself? The program is distributed just as source for Linux. There is a windows executable in the archive. I've compiled it with the usual tools/compilers I've found in the Alpine packages. > > It seems there are problems with pthread() function: the program > > compiles correctly, but segfaults at some point. > > > > This is what I get from GDB: > > > > Starting program: /root/zpaq a test / > > zpaq v7.15 journaling archiver, compiled May 3 2019 > > test.zpaq: 0 versions, 0 files, 0 fragments, 0.000000 MB > > Updating test.zpaq at offset 0 + 0 > > Adding 1326.112348 MB in 42966 files -method 14 -threads 1 at > > 2019-05-03 12:12:34. > > [New LWP 2317] > > [New LWP 2318] > > 1.27% 0:00:27 [1..236] 16754818 -method 14,97,0 > > > > Thread 2 "zpaq" received signal SIGSEGV, Segmentation fault. > > [Switching to LWP 2317] > > 0x00007ffff7fac5c0 in libzpaq::Predictor::Predictor(libzpaq::ZPAQL&) () > > (gdb) > > I think this should be reported upstream. I tried to contact the author, but never got an answer. Asked for help in their main forum, but to no avail. > > > (gdb) backtrace > > #0 0x00007ffff7fac5c0 in libzpaq::Predictor::Predictor(libzpaq::ZPAQL&) () > > #1 0x00007ffff7fc7122 in > > libzpaq::compressBlock(libzpaq::StringBuffer*, libzpaq::Writer*, char > > const*, char const*, char const*, bool) () > > #2 0x00007ffff7f83284 in compressThread(void*) () > > #3 0x00007ffff7fdd2c6 in start (p=<optimized out>) at > > src/thread/pthread_create.c:147 > > #4 0x00007ffff7fddd11 in __clone () at src/thread/x86_64/clone.s:21 > > Backtrace stopped: frame did not save the PC > > (gdb) > > > > (gdb) frame 3 > > #3 0x00007ffff7fdd2c6 in start (p=<optimized out>) at > > src/thread/pthread_create.c:147 > > 147 src/thread/pthread_create.c: No such file or directory. > > > > > > I wonder if there is a trivial solution to this problem. > > The usual suspect is that ZPAQ is allocating big buffer on stack. The > default thread stack size is significantly smaller with musl than glibc. > > You can try increase the default thread stack size. there are a couple > of ways to do so: > > - use phtread_attr_setstacksize to set the stacksize when calling pthread_create > - there is a way to initialize the pthread stack size. can be done from > main(), or from a ctor (but does not work if library is dlopened > iirc). I don't remember the details how that is done. > - Pass linker flag: -Wl,-z,stack-size=1048576 I've already tried, but with no luck. It crashes. I'll try again maybe tonight. It's an amazing compression/deduplication archiver, I use it for huge backups (like lots of terabytes of virtual machines virtual hdds) and never failed me. > > I've found a (kinda ugly, but useful) workaround for this installing > > the glibc binaries from sgerrand repository on github > > and using a binary compiled from another distro (with glibc).. > > > > Any help appreciated.