[clug] lrzip crash

[Paul Harvey]

Do you normally compress such large archives with it? I've never used lrzip
before, but reading the documentation it looks like it normally does
multiple passes over the input, but pipes can't seek backwards. The
documentation mentions that working on pipes is limited to input roughly
25% of available RAM, and there are other changes the algorithm must make
which sacrifices some efficiency. Is this particular archive the only one
giving trouble? Have similar operations succeeded before?

Informal hunch: the lrzip authors are obsessed with output size, and given
the sacrifices the software must make to work from piped input that can't
seek properly, I bet this code path just isn't as well tested/used - I.e.
you have discovered a bug :)

It's stating the obvious of course, but the only other things I can think
of are faulty RAM, bad disks (or some other unhandled exception), or you're
running a binary that's been compiled with buggy toolchain.

Is there anything in dmesg?

I've managed to make the venerable RCS sefault too; I bet the original
authors never envisaged ,v files growing beyond the ~2GB 32-bit signed int
limit :)

I bet there's a bug which mishandled some assumption about mmap'd files
which doesn't hold for the piped io (off by one, final read asks for some
fixed number of bytes instead of however many are actually remaining; etc.)
On 30 Jun 2015 18:06, "Eyal Lebedinsky" <eyal at eyal.emu.id.au> wrote:

> On 06/30/15 17:50, Hal Ashburner wrote:
>
>> run it in gdb and get a backtrace, file & line number? install debug info?
>> objdup -Dl /path/to/lrzip and find out what function is at
>> 000000000040ed58
>>
>> Hopefully send fedora/upstream an obvious and trivial patch?
>>
>
> Thanks. Failing to find related posts in a search I was asking for
> people's experience
> to shortcut going through a full investigation - in case anyone already
> came across
> this issue.
>
> cheers
>         Eyal
>
>  On 30 June 2015 at 17:02, Eyal Lebedinsky <eyal at eyal.emu.id.au> wrote:
>>
>>> I use lrzip to compress backups. I recently had a few crashed. The crash
>>> is
>>> repeatable when
>>> decompressing stdin. Here is an example run:
>>>
>>> $ lrzip -t vms.tar.lrz
>>> Decompressing...
>>> 100%      83.88 /     83.88 GB
>>> Average DeCompression Speed: 28.144MB/s
>>> [OK] - 90067507200 bytes
>>> Total time: 00:50:53.00
>>>
>>> Good, now through stdin:
>>>
>>> $ cat vms.tar.lrz | lrzip -tf -
>>> Decompressing...
>>> Segmentation fault (core dumped)
>>>
>>> dmesg shows:
>>>
>>> lrzip[13579]: segfault at 7f31b76d3000 ip 000000000040ed58 sp
>>> 00007fff878124e0 error 6 in lrzip[400000+41000]
>>>
>>> The archive was created with
>>>
>>> $ TMP="/backup/room" lrzip -b vms.tar
>>>
>>> This is on fedora 22 (latest and up-to-date).
>>>
>>> Any suggestions?
>>>
>>> TIA
>>>
>>> --
>>> Eyal Lebedinsky (eyal at eyal.emu.id.au)
>>>
>>
> --
> Eyal Lebedinsky (eyal at eyal.emu.id.au)
> --
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux
>