MIME-Version: 1.0
References: 
 <CAD4qdYDSYcp_mzBJXM6PFQsGA9xkR8_s+aWpgRTGkXwoPcx2-Q@mail.gmail.com>
 <20190719165408.6491577c@ncopa-desktop.copa.dup.pw>
 <CAD4qdYBKrSA4P6wu8SYqpdu3t+iO4sKTjXiTtUvTJ-Wwd02C0g@mail.gmail.com>
In-Reply-To: 
 <CAD4qdYBKrSA4P6wu8SYqpdu3t+iO4sKTjXiTtUvTJ-Wwd02C0g@mail.gmail.com>
From: Vittorio Mori <vittorio.mori@gmail.com>
Date: Fri, 19 Jul 2019 18:57:54 +0200
Message-ID: 
 <CAD4qdYBtKpT=aLP574FAD5KEHhEjmgosmyVQ7vvM9RPHpHUAJQ@mail.gmail.com>
Subject: Fwd: ZPAQ compiles but segfaults at pthread() with musl
To: alpine-user@lists.alpinelinux.org
Content-Type: text/plain; charset="UTF-8"

>
> 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?

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.