Bug 636045 - libtool --mode=execute sucks all memory, hangs machine, if a parameter is a large binary file
libtool --mode=execute sucks all memory, hangs machine, if a parameter is a l...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: libtool (Show other bugs)
23
All Linux
low Severity medium
: ---
: ---
Assigned To: Pavel Raiskup
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-21 08:17 EDT by Richard W.M. Jones
Modified: 2015-11-13 09:19 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-13 09:19:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Richard W.M. Jones 2010-09-21 08:17:06 EDT
Description of problem:

If a libtool --mode=execute parameter is a large file, then libtool
(specifically, 'sed') can suck up all memory and hang the machine.
The "hanging the machine" bit is probably due to the kernel, but
it definitely shouldn't be using so much memory.

Version-Release number of selected component (if applicable):

libtool-2.2.6-20.fc13.x86_64

How reproducible:

Very easily.

Steps to Reproduce:
1. truncate -s 10G bigfile
2. libtool --mode=execute /bin/ls bigfile
3.
  
Actual results:

Machine hangs(!)

top shows that 'sed' process is consuming lots of memory just
before the hang.

Expected results:

Really shouldn't hang.

Additional info:
Comment 1 Christofer C. Bell 2010-09-25 03:36:09 EDT
Are you able to reproduce this issue using a file that has been created with dd?  When I use your method to create the file, I end up with this stat information:

  File: `bigfile.truncate'
  Size: 10737418240	Blocks: 0          IO Block: 4096   regular file
Device: fd02h/64770d	Inode: 75628824    Links: 1
Access: (0664/-rw-rw-r--)  Uid: (  500/   cbell)   Gid: (  500/   cbell)
Access: 2010-09-25 02:13:41.441530507 -0500
Modify: 2010-09-25 02:13:41.441530507 -0500
Change: 2010-09-25 02:14:36.212526636 -0500

Note that while the file is 10 GB is size, the number of blocks is 0.  However, when I create this file with dd (dd if=/dev/zero of=bigfile.dd bs=1073741824 count=10):

  File: `bigfile.dd'
  Size: 10737418240	Blocks: 20971528   IO Block: 4096   regular file
Device: fd02h/64770d	Inode: 75628855    Links: 1
Access: (0664/-rw-rw-r--)  Uid: (  500/   cbell)   Gid: (  500/   cbell)
Access: 2010-09-25 02:15:21.101526579 -0500
Modify: 2010-09-25 02:17:09.113526173 -0500
Change: 2010-09-25 02:17:09.113526173 -0500

Note that the number of blocks is 20971528.  

I am not able to recreate this issue on a file created with dd:


[cbell@circe ~]$ libtool --mode=execute /bin/ls bigfile.dd
bigfile.dd
[cbell@circe ~]$ cat /etc/fedora-release 
Fedora release 13 (Goddard)
[cbell@circe ~]$ uname -a
Linux circe.inetdb.com 2.6.34.7-56.fc13.i686.PAE #1 SMP Wed Sep 15 03:27:15 UTC 2010 i686 i686 i386 GNU/Linux
[cbell@circe ~]$ 

The failure did not happen.
Comment 2 Richard W.M. Jones 2010-09-25 18:07:16 EDT
Very interesting.

I can easily reproduce the issue with a 10G sparse file.

But with a 10G fully allocate file, I cannot reproduce it.  (Although
libtool still takes a very long time, at no point is the machine
unresponsive)

So it has something to do with the sparse file ...

I should note that all the machines tested are using LUKS encrypted
drives.
Comment 3 Bug Zapper 2011-05-31 08:56:57 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Richard W.M. Jones 2011-05-31 09:32:26 EDT
Verifed that this still happens with:

libtool-2.4-4.fc15.x86_64

(using a sparse 10G file).
Comment 5 Richard W.M. Jones 2011-10-20 10:17:03 EDT
Still happening with
libtool-2.4-6.fc16.x86_64
sed-4.2.1-7.fc16.x86_64
Comment 6 Pavel Raiskup 2013-01-09 05:19:25 EST
(In reply to comment #2)
> Very interesting.
>
> I can easily reproduce the issue with a 10G sparse file.
>
> But with a 10G fully allocate file, I cannot reproduce it.  (Although libtool
> still takes a very long time, at no point is the machine unresponsive)
>
> So it has something to do with the sparse file ...
>
> I should note that all the machines tested are using LUKS encrypted drives.

I have made some observation around libtool regarding this problem.  This is
not about sparse file and also not about encrypted drives.  It is just because
'libtool' calls sed in this way:

  sed -e 4q BIGFILE

.. which is 'head' utility alternative (there are probably some reasons not
using head directly, but I don't see it now).

As for 'dd'ed big files, you have probably generated random sparse file
containing randomly generated newlines.  So sed is is probably happy in this
case.  Try to do 'dd if=/dev/zero of=noNewLines ..', it should cause the same
results.

Unresponsiveness of computer is caused due to sed's unlimited memory
consumption && enabled swap (just as a side note, head has probably better
space complexity — seems it is not reading whole line).

----

I will probably contact upstream if there is not possible to use 'head' utility
for this purpose.  I would go also for the size check before running sed,
because 'sed' is run just because libtool tries to recognize, whether this file
is not '*.lo' or '*.la'-like file (text files, they should be IMO much ≪ 1MB).

CC'ing Martin, Is this sed's behaviour expected?  Isn't there possible to
specify some (portable) option to speed this sed operation up?

Thanks,
Pavel
Comment 7 Paolo Bonzini 2013-01-15 12:07:04 EST
sed -e 4q should probably be replaced by

   dd if=BIGFILE bs=16K count=1

or something like that.  I don't know if dd is within the portability limitations of libtool.
Comment 8 Pavel Raiskup 2013-01-17 07:38:59 EST
(In reply to comment #7)
> sed -e 4q should probably be replaced by
> 
>    dd if=BIGFILE bs=16K count=1
> 
> or something like that.  I don't know if dd is within the portability
> limitations of libtool.

Thanks, I forwarded your suggestion to upstream mailing list.

http://lists.gnu.org/archive/html/bug-libtool/2013-01/msg00005.html

Pavel
Comment 9 Fedora End Of Life 2013-04-03 16:12:09 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 10 Pavel Raiskup 2013-04-25 08:18:45 EDT
Upstream proposal:

    http://lists.gnu.org/archive/html/bug-libtool/2013-04/msg00005.html

Anyway, I will probably adopt this patch partially in Fedora before this (or
something else) gets upstream (it will take some time).  In Fedora, we are not
afraid of whether the 'dd' utility exists:

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 2641327..22f032d 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -83,6 +83,9 @@ PROGRAM=libtool
 PACKAGE=@PACKAGE@
 VERSION=@VERSION@
 TIMESTAMP="@TIMESTAMP@"
+
+: ${DD=dd}
+
 package_revision=@package_revision@

 # Be Bourne compatible
@@ -437,6 +440,18 @@ M4SH_VERBATIM([[
 ##    Main.    ##
 ## ----------- ##

+# func_try_sizelim file n
+# try to write at most the first N bytes from FILE to the standard output when
+# possible, otherwise put whole file
+func_try_sizelim ()
+{
+  if test -n "$DD"; then
+    $DD if="$1" bs=$2 count=1 2>/dev/null
+  else
+    cat "$1"
+  fi
+}
+
 # func_lalib_p file
 # True iff FILE is a libtool `.la' library or `.lo' object file.
 # This function is only a basic sanity check; it will hardly flush out
@@ -444,7 +459,7 @@ M4SH_VERBATIM([[
 func_lalib_p ()
 {
     test -f "$1" &&
-      $SED -e 4q "$1" 2>/dev/null \
+      func_try_sizelim "$1" 4096 | $SED -e 4q 2>/dev/null \
         | $GREP "^# Generated by .*$PACKAGE" > /dev/null 2>&1
 }

Pavel
Comment 11 Pavel Raiskup 2013-04-26 13:15:12 EDT
Fix is in rawhide/f19, any comment welcome:

  http://pkgs.fedoraproject.org/cgit/libtool.git/commit/?id=b6164b7e355ea9a11948fe24e6196590ed3d0c2c
Comment 12 Fedora Update System 2013-04-26 14:12:05 EDT
libtool-2.4.2-14.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/libtool-2.4.2-14.fc19
Comment 13 Fedora Update System 2013-04-27 13:27:46 EDT
Package libtool-2.4.2-14.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libtool-2.4.2-14.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-6802/libtool-2.4.2-14.fc19
then log in and leave karma (feedback).
Comment 14 Paolo Bonzini 2013-05-06 13:14:12 EDT
> In Fedora, we are not afraid of whether the 'dd' utility exists:

Actually you should be, because the ltmain.sh file that you create on Fedora is then used when building the package on all other systems.

Was the patch committed upstream in the end?
Comment 15 Pavel Raiskup 2013-05-07 02:16:06 EDT
Paolo, thanks a lot for your comment - reverted (this is so obvious, can't
believe I forgot about it).

This must really wait for upstream and the check for DD must be done during
configure phase (as proposed) before 'libtool' is generated.
Comment 16 Jan Kurik 2015-07-15 11:18:41 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Comment 17 Pavel Raiskup 2015-11-13 09:19:52 EST
https://lists.gnu.org/archive/html/libtool-commit/2014-05/msg00001.html

Fix is already in f23+.

Note You need to log in before you can comment on or make changes to this bug.