Date: Fri, 19 Jul 2019 16:54:08 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Vittorio Mori <vittorio.mori@gmail.com>
Cc: alpine-user@lists.alpinelinux.org
Subject: Re: ZPAQ compiles but segfaults at pthread() with musl
Message-ID: <20190719165408.6491577c@ncopa-desktop.copa.dup.pw>
In-Reply-To: 
 <CAD4qdYDSYcp_mzBJXM6PFQsGA9xkR8_s+aWpgRTGkXwoPcx2-Q@mail.gmail.com>
References: 
 <CAD4qdYDSYcp_mzBJXM6PFQsGA9xkR8_s+aWpgRTGkXwoPcx2-Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 19 Jul 2019 09:40:13 +0200
Vittorio Mori <vittorio.mori@gmail.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?
 
> 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.
 
> (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 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.