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:
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.
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.
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
Verifed that this still happens with: libtool-2.4-4.fc15.x86_64 (using a sparse 10G file).
Still happening with libtool-2.4-6.fc16.x86_64 sed-4.2.1-7.fc16.x86_64
(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
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.
(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
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
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
Fix is in rawhide/f19, any comment welcome: http://pkgs.fedoraproject.org/cgit/libtool.git/commit/?id=b6164b7e355ea9a11948fe24e6196590ed3d0c2c
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
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).
> 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?
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.
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
https://lists.gnu.org/archive/html/libtool-commit/2014-05/msg00001.html Fix is already in f23+.