GNU bug report logs - #16951
zless error under ulimit -v

Previous Next

To reply to this bug, email your comments to 16951 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jaroslaw Weglinski <jaroslaw.weglinski <at> atendesoftware.pl>
To: bug-gzip <at> gnu.org
Subject: zless error under ulimit -v
Date: Thu, 06 Mar 2014 16:16:39 +0100

Greetings!
gzip 1.3.5 (Scientific Linux release 5.6), when using zless under
virtual memory limit, gzip teminates and goes defunc when hitting limit,
and then less does not propagate error (from user's perspective it looks
like proper end of decompression).

> [test <at> esb-dev ~]$ ulimit -v 100000
> [test <at> esb-dev ~]$ ulimit -v
> 100000

> $ ps -ef| grep ^test
> test     31062 27.4  0.2  99968 37292 pts/5    S+   16:11   0:15 less /tmp/pomiary.txt.gz
> test     31063 15.8  0.0      0     0 pts/5    Z+   16:11   0:08 [gzip] <defunct>

and less's output (no sign of error):
> 12285443946;13/11/15 10:15:00,000;198591;
> 12285443946;13/11/15 10:30:00,000;199028;
> 12285443946;13/11/15 10:45:00,000;199223;
> 12285443946;13/11/15 11:00:00,000;199342;
> 12285443946;13/11/15 11:15:00,000;199395;
> 12285443946;13/11/15 11:30:00,000;199420;
> 12285443946;13/11/15 11:45:00,000;199443;
> 12285443946;13/11/15 12:00:00,000;199769;
> /tmp/pomiary.txt.gz lines ?-?/? (END)


regards,
J. Weglinski

Message #8 received at 16951 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jaroslaw Weglinski <jaroslaw.weglinski <at> atendesoftware.pl>, 
 16951 <at> debbugs.gnu.org
Cc: bug-less <at> gnu.org
Subject: Re: bug#16951: zless error under ulimit -v
Date: Thu, 06 Mar 2014 13:48:35 -0800

Thanks for the bug report.  This bug occurs because 'less' ignores the 
exit status of gzip.  That is, 'less' uses the LESSOPEN environment 
variable to discover that gzip is the input processor, and uses gzip, 
but when it calls pclose on the resulting stream it discards the exit 
status returned by pclose.  'less' should inspect the exit status and 
report an error in that case.

I'll CC: this email to bug-less <at> gnu.org to give its developer a 
heads-up.  Mark, the original bug report is here:

http://bugs.gnu.org/16951

Message #11 received at 16951 <at> debbugs.gnu.org (full text, mbox):

From: Mark Nudelman <markn <at> greenwoodsoftware.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 
 Jaroslaw Weglinski <jaroslaw.weglinski <at> atendesoftware.pl>,
 16951 <at> debbugs.gnu.org
Subject: Re: bug#16951: zless error under ulimit -v
Date: Thu, 06 Mar 2014 14:35:23 -0800

Hi Paul,
Since less-451, if LESSOPEN starts with two pipe chars, less does
examine the exit status of the preprocessor.  Is this what you're
looking for?

--Mark


On 3/6/2014 1:48 PM, Paul Eggert wrote:
> Thanks for the bug report.  This bug occurs because 'less' ignores the
> exit status of gzip.  That is, 'less' uses the LESSOPEN environment
> variable to discover that gzip is the input processor, and uses gzip,
> but when it calls pclose on the resulting stream it discards the exit
> status returned by pclose.  'less' should inspect the exit status and
> report an error in that case.
> 
> I'll CC: this email to bug-less <at> gnu.org to give its developer a
> heads-up.  Mark, the original bug report is here:
> 
> http://bugs.gnu.org/16951

Message #14 received at 16951 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Mark Nudelman <markn <at> greenwoodsoftware.com>, 
 Jaroslaw Weglinski <jaroslaw.weglinski <at> atendesoftware.pl>,
 16951 <at> debbugs.gnu.org
Subject: Re: bug#16951: zless error under ulimit -v
Date: Thu, 06 Mar 2014 17:39:55 -0800

[Message part 1 (text/plain, inline)]

Mark Nudelman wrote:
> Since less-451, if LESSOPEN starts with two pipe chars, less does
> examine the exit status of the preprocessor.

Thanks, I didn't know that, and I have installed the attached patch to 
the gzip master on savannah to take advantage of it.  Unfortunately the 
patch doesn't suffice, because 'less' examines the preprocessor's exit 
status only when the preprocessor generates no output.  In the case 
we're talking about, the preprocessor generates some output, but then 
runs out of memory and exits with nonzero status.

You can reproduce the 'less' problem by creating a large text file 't', 
compressing it with 'gzip t', running the following shell command in one 
window:

LESSOPEN='||-gzip -cdfq -- %s' less t.gz

When you see the first screenful, go to another window and kill the gzip 
process that's waiting for 'less' to read more input.  'less' won't 
notice or report the gzip failure.

[0001-zless-improve-gzip-failure-checking-and-port-to-new-.patch (text/plain, attachment)]

Message #19 received at 16951 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Mark Nudelman <markn <at> greenwoodsoftware.com>
Cc: Jaroslaw Weglinski <jaroslaw.weglinski <at> atendesoftware.pl>,
 16951 <at> debbugs.gnu.org
Subject: Re: bug#16951: zless error under ulimit -v
Date: Fri, 1 Apr 2022 19:57:15 -0700

On 3/6/14 17:39, Paul Eggert wrote:

> You can reproduce the 'less' problem ...

I followed up this old Gzip bug report by writing a proposed patch for 
'less' and filing a 'less' bug report here:

https://github.com/gwsw/less/issues/258

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.