Skip Menu |

This queue is for tickets about the Compress-LZ4 CPAN distribution.

Report information
The Basics
Id: 77574
Status: resolved
Priority: 0/
Queue: Compress-LZ4

People
Owner: Nobody in particular
Requestors: perl-bugs [...] o.ewheeler.net
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



CC: bug-Compress-LZ4 [...] rt.cpan.org
Subject: Memory leak in LZ4
Date: Thu, 31 May 2012 20:10:50 -0700 (PDT)
From: Eric Wheeler <perl-bugs [...] o.ewheeler.net>
Hello Gray, It looks like +8MB of virtual memory is allocated (but never used) when Compress::LZ4 attempts to decompress an invalid stream, thus leading to a huge VM overcommit. Here's a short exmple: use Compress::LZ4; foreach (1..100) { system("ps -p $$ -o vsz"); # VM commit size in kB $a = decompress('xxx'); } system("ps -p $$ -o vsz"); # VM commit size in kB Most systems will kill a process when it attempts to overcommit memory beyond a certain point. For now I've set /proc/sys/vm/overcommit_limit=1 as a bandaid. Is there a way to have decompress check the magic bits before attempting to decompress? I didn't see an obvious "islz4()"-like function in LZ4.xs, but please point me in the right direction if such a thing exists. Right now the only way I can test if a stream is LZ4 is to decompress and check for undef. Thanks for your help! -Eric -- Eric Wheeler 888-LINUX26 (888-546-8926) www.GlobalLinuxSecurity.pro President eWheeler, Inc. dba Global Linux Security PO Box 14707 Portland, OR 97286
On Thu May 31 23:10:59 2012, perl-bugs@o.ewheeler.net wrote: Show quoted text
> It looks like +8MB of virtual memory is allocated (but never used) when > Compress::LZ4 attempts to decompress an invalid stream, thus leading to a > huge VM overcommit. Here's a short exmple: > > use Compress::LZ4; > > foreach (1..100) > { > system("ps -p $$ -o vsz"); # VM commit size in kB > $a = decompress('xxx'); > } > system("ps -p $$ -o vsz"); # VM commit size in kB > > Most systems will kill a process when it attempts to overcommit memory > beyond a certain point. For now I've set /proc/sys/vm/overcommit_limit=1 > as a bandaid. > > Is there a way to have decompress check the magic bits before attempting > to decompress? I didn't see an obvious "islz4()"-like function in
LZ4.xs, Show quoted text
> but please point me in the right direction if such a thing exists. Right > now the only way I can test if a stream is LZ4 is to decompress and check > for undef.
I'm not seeing a memory leak on Mac OS X. Can you provide version info for Perl and Compress::LZ4 you have tested and if you see a leak on any other OSs besides Linux. LZ4 does not currently have have any magic bits to check. The author is trying to come up with some all-encompassing solution so it might not be anytime soon. See http://fastcompression.blogspot.fr/2012/04/file-container-format-for-lz4.html and newer blog entries. All the various language interfaces to LZ4 currently add a 4 byte length header when compressing, and when decompressing they blindly accept the first 4 bytes as the length header, so the user is responsible for maintaining the integrity of any compression stream.
On Fri Jun 01 12:55:12 2012, GRAY wrote: Show quoted text
> I'm not seeing a memory leak on Mac OS X.
I take that back. Copy paste error resulted in conversion of double quotes to single quotes. I'm seeing the leak now.
Subject: Re: [rt.cpan.org #77574] Memory leak in LZ4
Date: Fri, 1 Jun 2012 10:49:03 -0700 (PDT)
To: gray via RT <bug-Compress-LZ4 [...] rt.cpan.org>
From: perl-bugs [...] o.ewheeler.net
On Fri, 1 Jun 2012, gray via RT wrote: Show quoted text
> Can you provide version info for Perl and Compress::LZ4
Versions: Compress::LZ4 0.12 from CPAN the otherday. This is perl, v5.10.1 (*) built for x86_64-linux-gnu-thread-multi Show quoted text
> you have tested and if you see a leak on any > other OSs besides Linux.
I have not. Show quoted text
> LZ4 does not currently have have any magic bits to check. The author is > trying to come up with some all-encompassing solution so it might not be > anytime soon. See > http://fastcompression.blogspot.fr/2012/04/file-container-format-for-lz4.html > and newer blog entries. All the various language interfaces to LZ4 > currently add a 4 byte length header when compressing, and when > decompressing they blindly accept the first 4 bytes as the length > header, so the user is responsible for maintaining the integrity of any > compression stream.
I was afraid of that. Perhaps it allocates memory based on the header and never decompresses into the buffer when the stream fails. (I'm just guessing here, but that would explain VSZ leakage.) I tried Compress::Snappy, it doesn't memory leak (at least not using the test above). Does Snappy have better magic-bit checking? -Eric
On Fri Jun 01 13:49:32 2012, perl-bugs@o.ewheeler.net wrote: Show quoted text
> I was afraid of that. Perhaps it allocates memory based on the header > and > never decompresses into the buffer when the stream fails. (I'm just > guessing here, but that would explain VSZ leakage.)
It turned out to be an issue with reference counting. The fix is in 0.13 which I just pushed to CPAN. Show quoted text
> I tried Compress::Snappy, it doesn't memory leak (at least not using > the > test above). Does Snappy have better magic-bit checking?
Yes.