bug-libtool
[Top][All Lists]
Advanced

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

Re: libtoolize 2.2.7a is a fork bomb under OpenSolaris


From: Peter Rosin
Subject: Re: libtoolize 2.2.7a is a fork bomb under OpenSolaris
Date: Wed, 25 Nov 2009 12:38:05 +0100
User-agent: Thunderbird 2.0.0.23 (Windows/20090812)

Den 2009-11-24 14:33 skrev Ralf Wildenhues:
Hello Vadim,

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

Thanks for the report.  Which autoconf version are you using?

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

Can you work around this issue by something like
  CONFIG_SHELL=/bin/bash
  export CONFIG_SHELL

(adjust path to bash if necessary) and then using
  $CONFIG_SHELL ./libtoolize ...

?

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

so that subsequent re-spawns should die from the SIGPIPE?

I suffered from something that looks similar, my underlying
cause is that ECHO is not set properly leading to big trouble
when func_dirname_and_basename "$progpath" is executed.

this line:
func_dirname_result=`$ECHO "${1}" | $SED -e "$dirname"`
expands to the following for me
func_dirname_result=`"./libtoolize" | /bin/sed -e "s,/[^/]*$,,"`

leading to lots of forks.

my libtoolize as this line before the above
: ${ECHO=$as_echo}
but as_echo is not assigned anywhere in my libtoolize.

I'm on debian squeeze, autoconf 2.64, automake 1.11 but
testing the pr-msvc-support branch.

Huh?

Cheers,
Peter

--
They are in the crowd with the answer before the question.
> Why do you dislike Jeopardy?




reply via email to

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