[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: libtoolize 2.2.7a is a fork bomb under OpenSolaris

From: Vadim Zeitlin
Subject: Re[2]: libtoolize 2.2.7a is a fork bomb under OpenSolaris
Date: Wed, 25 Nov 2009 16:49:34 +0100

On Tue, 24 Nov 2009 14:33:41 +0100 Ralf Wildenhues <address@hidden> wrote:

RW> Hello Vadim,

 Hello Ralf and thanks for your reply!

RW> * Vadim Zeitlin wrote on Fri, Nov 20, 2009 at 06:20:42PM CET:
RW> >  This is another bug report about latest git version of libtool under
RW> > OpenSolaris. Running libtoolize from this version seems to spawn an 
RW> > number of libtoolize and gsed processes. I don't have much details about
RW> > the bug because I really don't want to try it again after rebooting the
RW> > machine twice (it brings my poor VM to its knees pretty quickly) but it's
RW> > probably due to re-exec logic in the beginning of the script. All I can 
RW> > is that it creates plenty of conf*.sh files and that it happens even if I
RW> > just do "libtoolize --help" and that running "libtoolize --debug" is not
RW> > helpful because there is a huge amount of output from all the copies of
RW> > itself that it launches all scrambled together. I'd be willing to debug it
RW> > more if I could just find some way to do it safely (i.e. without rebooting
RW> > every time) but I don't know how to do it and I don't see anything
RW> > obviously wrong in (convoluted) shell code in the script so unfortunately 
RW> > can't help further with this bug.
RW> Thanks for the report.  Which autoconf version are you using?

 Sorry for forgetting to mention this, I use 2.61 even though the required
version is 2.62. I changed configure.ac to require only 2.61 as this is the
latest version available as a package for OpenSolaris and I thought that if
any 2.62 features were required I'd get errors when bootstrapping. But I
didn't and then promptly forgot about this change, sorry again. Do you
think this could explain this problem? Maybe it was all my own fault after

 Anyhow, just for completeness here are all my local changes:

% git diff
diff --git a/configure.ac b/configure.ac
index 56325f7..0b877b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -23,7 +23,7 @@

-AC_PREREQ(2.62)dnl Some m4sh scripts use $as_echo
+AC_PREREQ(2.61)dnl Some m4sh scripts use $as_echo
 dnl Oldest automake required for bootstrap is below in AM_INIT_AUTOMAKE.

@@ -122,7 +122,7 @@ AC_SUBST([package_revision])

 dnl These are bootstrap requirements! Once built, libtool may work with
 dnl much older releases of autoconf and automake.  See release notes.
-AM_INIT_AUTOMAKE([1.10.1 gnu subdir-objects dist-lzma])
+AM_INIT_AUTOMAKE([1.10 gnu subdir-objects])

 dnl We use m4sh to generate libtool's portable shell scripts
 AC_SUBST([M4SH], ['$(AUTOM4TE) --language=m4sh'])

RW> I would like to ask a few more questions, but addressing them might
RW> require you to reboot a couple more times, so please judge for yourself.

 Actually I decided to look into Solaris zones as I thought this would
allow me to limit the number of processes -- and it indeed did. So now I
can set the max number of LWPs for my sandbox zone to some not too large
number and only reboot this zone (which takes a couple of seconds) instead
of rebooting the entire machine and hence can do more tests.

RW> Can you work around this issue by something like
RW>   CONFIG_SHELL=/bin/bash
RW> (adjust path to bash if necessary) and then using
RW>   $CONFIG_SHELL ./libtoolize ...
RW> ?

 Unfortunately this doesn't change anything. FWIW /bin/sh is ksh93 under
OpenSolaris. And while my login shell is zsh, I did try running libtoolize
under bash with exactly the same result.

RW> Can you try to catch a (partial) trace log of your fork bomb by adding
RW>   set -x
RW> as second line in the libtoolize script, and, without above CONFIG_SHELL
RW> setting, maybe running something like
RW>   ./libtoolize 2>&1 | sed 300q
RW> so that subsequent re-spawns should die from the SIGPIPE?

 Ah, I didn't think about this, thanks for the hint!

 I now see the problem better: the function func_dirname_and_basename()
relaunches libtoolize instead of just extracting its dir and base names.
And this happens because ECHO variable is empty because as_echo is not
defined. So it looks like it _was_ my own fault after all, sorry for the
trouble :-( I guess as_echo is only defined by autoconf 2.62, isn't it?

 Anyhow, replacing as_echo with just "echo" makes libtoolize work for me.
Sorry again if this problem was due to using a wrong version of autoconf
and thanks for your hint about sed/SIGPIPE!

Attachment: pgpfVpaaQRZtn.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]