[clug] lrzip crash

[Eyal Lebedinsky]

On 06/30/15 18:52, Paul Harvey wrote:
> 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?

This is the only plce where I use lrzip.

> 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 :)

See my other post - turns out to be a known 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.

This is repeatable, with identical (partial) results, so unlikely to be RAM or disk.

> Is there anything in dmesg?

Nothing more than the one line I showed.

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

At this point the list of guesses is endless.

cheers
	Eyal
> On 30 Jun 2015 18:06, "Eyal Lebedinsky" <eyal at eyal.emu.id.au> wrote:
>
>> On 06/30/15 17:50, Hlinux at lists.samba.orgal 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
>>

-- 
Eyal Lebedinsky (eyal at eyal.emu.id.au)