Subject: ZPAQ compiles but segfaults at pthread() with musl

From: Vittorio Mori <[email-masked]>
Date: Fri, 19 Jul 2019 09:40:13 +0200

Hello everyone.

I have an issue compiling the ZPAQ compressor/archive utility from Matt Mahoney.

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)

(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.

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.

---

From: Natanael Copa <[email-masked]>
Date: Fri, 19 Jul 2019 16:54:08 +0200

On Fri, 19 Jul 2019 09:40:13 +0200

> 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?
 
> Adding 1326.112348 MB in 42966 files -method 14 -threads 1 at

I think this should be reported upstream.
 
> 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

---

From: Vittorio Mori <[email-masked]>
Date: Sat, 20 Jul 2019 17:40:45 +0200

That did the trick !

The problem was solved by adding the line:

LDFLAGS=-Wl,-z,stack-size=1048576

To the Makefile.

Thanks a million!