lrzip dies on ppc64el when using zpaq

Bug #1669069 reported by Mario Splivalo
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
lrzip (Debian)
New
Unknown
lrzip (Ubuntu)
New
Undecided
Unassigned

Bug Description

When I try to compress a file using lrzip's -z option (use zpaq compressinon) I get 'Illegal instruction':

mario@diamond:/tmp/mario$ dd if=/dev/zero of=file bs=1024 count=300000
300000+0 records in
300000+0 records out
307200000 bytes (307 MB, 293 MiB) copied, 0.764671 s, 402 MB/s
mario@diamond:/tmp/mario$ lrzip -vz file
The following options are in effect for this COMPRESSION.
Threading is ENABLED. Number of CPUs detected: 20
Detected 1097149841408 bytes ram
Compression level 7
Nice Value: 19
Show Progress
Verbose
Temporary Directory set as: .//
Compression mode is: ZPAQ. LZO Compressibility testing enabled
Heuristically Computed Compression Window: 6975 = 697500MB
Output filename is: file.lrz
File size: 307200000
Will take 1 pass
Beginning rzip pre-processing phase
Illegal instruction99%
mario@diamond:/tmp/mario$
mario@diamond:/tmp/mario$ uname -a
Linux diamond 4.4.0-64-generic #85-Ubuntu SMP Mon Feb 20 17:05:51 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux
mario@diamond:/tmp/mario$ apt-cache policy lrzip
lrzip:
  Installed: 0.621-1
  Candidate: 0.621-1
  Version table:
 *** 0.621-1 500
        500 http://ports.ubuntu.com/ubuntu-ports xenial/universe ppc64el Packages
        100 /var/lib/dpkg/status
mario@diamond:/tmp/mario$

I repeated this locally on my amd64 workstation, inside ppc64el lxc container (trusty container as xenial container fails to start):

root@lrzip:/# dd if=/dev/zero of=file bs=1024 count=300000
300000+0 records in
300000+0 records out
307200000 bytes (307 MB) copied, 0.612377 s, 502 MB/s
root@lrzip:/# lrzip -vz file
The following options are in effect for this COMPRESSION.
Threading is ENABLED. Number of CPUs detected: 8
Detected 33551245312 bytes ram
Compression level 7
Nice Value: 19
Show Progress
Verbose
Compression mode is: ZPAQ. LZO Compressibility testing enabled
Heuristically Computed Compression Window: 213 = 21300MB
Output filename is: file.lrz
File size: 307200000
Will take 1 pass
Beginning rzip pre-processing phase
Invalid instruction99%
NIP 00000040ffb19004 LR 00000000100333e8 CTR 00000040ffb19000 XER 0000000020000000 CPU#2
MSR 8000000002806001 HID0 0000000000000000 HF 0000000002806001 idx 0
TB 00426606 1832260385397170
GPR00 0000000010033444 0000004081dde250 00000000100690e8 0000004081dde420
GPR04 0000000000000006 0000000000000bb4 0000000000000007 000000000000001c
GPR08 0000000000000006 00000040ffb19000 ffffffffffffffc3 000000000000004c
GPR12 00000040ffb19000 0000004081e018d0 0000000010067950 0000000000000001
GPR16 0000000000000060 000000001004c9f8 000000001004cae8 0000000010067dd0
GPR20 00000040c2087010 000000000208d556 000000001004c0a0 0000000000000000
GPR24 0000000000000000 00000000100679b0 000000001004bd80 0000000000000000
GPR28 0000004081dde420 0000000000000bb9 0000004081dfe420 0000004081dde420
CR 48004444 [ G L - - G G G G ] RES ffffffffffffffff
FPR00 0000000000007fff 3ff000000000003a 4030000000000000 3bbcc86800000000
FPR04 3fc5555555555a0f 3d6a63f14df01aa8 3fe000004d7e6bb1 3ff0000eae18ac9f
FPR08 3ff0000400000000 3da0000155556aab 3e20f4bb065ef979 beaa5f1e88400000
FPR12 3ff0000000000000 3d2ef35793c76730 0000000000000000 0000000000000000
FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR28 0000000000000000 0000000000000000 3ff0000000000000 0000000000000000
FPSCR 0000000082004000
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
Illegal instruction (core dumped)
root@lrzip:/#

This container is running on trusty machine using 3.13.0-110 kernel, and I've created it like this:

lxc-create -n lrzip -t ubuntu -- -a ppc64el -r trusty

summary: - ltzip dies on ppc64el when using zpaq
+ lrzip dies on ppc64el when using zpaq
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I found that this is size dependent, but not in the gigabytes.
This is the first that fails:
$ rm file.lrz; dd if=/dev/zero of=file bs=1 count=64; lrzip -z file
While this still works
$ rm file.lrz; dd if=/dev/zero of=file bs=1 count=63; lrzip -z file

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Thread 3 "lrzip" received signal SIGILL, Illegal instruction.
[Switching to Thread 0x3fffb312f180 (LWP 130922)]
0x00003fffb7f70000 in ?? ()
(gdb) bt
#0 0x00003fffb7f70000 in ?? ()
#1 0x00000000100363f8 in libzpaq::Predictor::predict (this=0x3fffb3113430) at libzpaq/libzpaq.cpp:3140
#2 0x000000001003792c in libzpaq::Encoder::compress (this=0x3fffb3113420, c=<optimized out>)
    at libzpaq/libzpaq.cpp:1409
#3 0x0000000010037c9c in libzpaq::Compressor::postProcess (this=0x3fffb3113360, pcomp=0x0, len=<optimized out>)
    at libzpaq/libzpaq.cpp:1548
#4 0x000000001003826c in libzpaq::compress (in=0x3fffb312e508, out=0x3fffb312e4f0, level=<optimized out>)
    at libzpaq/libzpaq.cpp:1597
#5 0x0000000010038424 in zpaq_compress (c_buf=0x3fffac0008c0 "zPQ\001\001E", c_len=0x3fffb312e708,
    s_buf=0x100a3270 "", s_len=<optimized out>, level=<optimized out>, msgout=<optimized out>,
    progress=<optimized out>, thread=<optimized out>) at libzpaq/libzpaq.h:526
#6 0x0000000010014a98 in zpaq_compress_buf (thread=<optimized out>, cthread=0x10092a68,
    control=0x10070c50 <local_control>) at stream.c:184
#7 compthread (data=0x0) at stream.c:1296
#8 0x00003fffb7e58070 in start_thread (arg=0x3fffb312f180) at pthread_create.c:335
#9 0x00003fffb7a73230 in clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:96

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

They really do JIT in there with a "A ZPAQL virtual machine"

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Found in the code:
const int S=sizeof(char*); // 4 = x86, 8 = x86-64
if (*(char*)&t!=0x78 || (S!=4 && S!=8))
    error("JIT supported only for x86-32 and x86-64");

Yet the arch check code is not strong, it lets ppc through and then fails.
It also seems to have "invalid instruction" code detection but that only works on x86 as well.

TL;DR Jit in zpac isn't good for non x86.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Here from the header libzpaq/libzpaq.h

By default, LIBZPAQ uses JIT (just in time) acceleration. This only
works on x86-32 and x86-64 processors that support the SSE2 instruction
set. To disable JIT, compile with -DNOJIT. To enable run time checks,
compile with -DDEBUG. Both options will decrease speed.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Even guaranteeing SSE2 is not sure on old machines or some virtual machines.
Usually runtime detection has to be used on those.

I think the only real "safe" option is to build with -DNOJIT on all architectures.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hmm a simple override of this did not pass down.
So the following did not help.

diff -Nru lrzip-0.631/debian/changelog lrzip-0.631/debian/changelog
--- lrzip-0.631/debian/changelog 2016-11-14 01:20:43.000000000 +0100
+++ lrzip-0.631/debian/changelog 2017-03-02 09:40:03.000000000 +0100
@@ -1,3 +1,9 @@
+lrzip (0.631-1ubuntu1~ppa2) xenial; urgency=medium
+
+ * Experimental build for ppc to check JIT disabling
+
+ -- Christian Ehrhardt <email address hidden> Thu, 02 Mar 2017 09:35:06 +0100
+
 lrzip (0.631-1) unstable; urgency=low

   * New upstream release.
diff -Nru lrzip-0.631/debian/rules lrzip-0.631/debian/rules
--- lrzip-0.631/debian/rules 2014-03-28 19:08:25.000000000 +0100
+++ lrzip-0.631/debian/rules 2017-03-02 09:35:02.000000000 +0100
@@ -12,6 +12,10 @@
 CFLAGS += -Wall -pedantic
 LDFLAGS += -Wl,--as-needed

+# Disable Jit as it is x86 >=sse2 only which can not be guaranteed
+# https://bugs.launchpad.net/cloud-images/+bug/1668876
+CFLAGS += -DNOJIT
+
 override_dh_auto_configure:
        # With pristine tarballs from version control, there is no ./configure
        [ -f configure ] || autoreconf -vfi

It seems https://launchpadlibrarian.net/309385381/buildlog_ubuntu-xenial-ppc64el.lrzip_0.631-1ubuntu1~ppa2_BUILDING.txt.gz that the build of libzpaq/ completely ignores the extra CFLAGS

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Well that is CPP

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

This is working now just fine:
--- lrzip-0.631/debian/rules 2014-03-28 19:08:25.000000000 +0100
+++ lrzip-0.631/debian/rules 2017-03-02 10:23:30.000000000 +0100
@@ -10,8 +10,13 @@

 include /usr/share/dpkg/buildflags.mk
 CFLAGS += -Wall -pedantic
+CXXFLAGS += -Wall -pedantic
 LDFLAGS += -Wl,--as-needed

+# Disable Jit as it is x86 >=sse2 only which can not be guaranteed
+# https://bugs.launchpad.net/cloud-images/+bug/1668876
+CXXFLAGS += -DNOJIT
+

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I reported a fix to Debian, linking as soon as I have a bug #.

Changed in lrzip (Debian):
status: Unknown → New
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.