-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Yang Tse on 7/30/2008 11:17 AM: | The reported error is: | | /opt/csw/bin/gm4: memory exhausted | autom4te: /opt/csw/bin/gm4 failed with exit status: 1 | aclocal: autom4te failed with exit status: 1 Ouch. Debugging out-of-memory conditions can be a bit difficult. First, have you tried commenting out sections of your configure.ac, to see if one section in particular seems to be the culprit? | If instead of using GNU m4 version 1.4.5 on the Solaris box we use GNU | m4 version 1.4.11 the failure is not triggerred. Part of the problem | is that we have to make it work with gm4 1.4.5 on this system. The NEWS for m4 mentions a couple of memory leaks that have been resolved since 1.4.5; one in regexp/patsubst handling, and one in diversion number handling. Perhaps you are using a construct that repeatedly creates new regexp and thus leaks, or which uses insanely large diversion numbers? Also, note that m4 1.4.x has quadratic peak memory usage (but no leaks) on any algorithm that recurses on $@ (and quite a bit of autoconf does this, at least, prior to my recent patches to m4sugar this month). Perhaps there have been some efficiency fixes in m4 since 1.4.5 that require less memory to do the same work? At any rate, the (as-yet-unreleased) m4 1.6 has solved the memory usage to scale linearly rather than quadratically; requiring gm4 1.4.5 might be a losing proposition since you have already confirmed that upgrading to newer software solves the problem for you. | | What would you suggest to further pinpoint if there is a recursion | problem with our macros, or if aclocal is looping to much, or if the | shell is trashing autom4te's output in its way to gm4 or if it is | actually a gm4 binary or version problem ? Based on the error message, the "out of memory" error is occurring when m4 (run by autom4te, in turn run by aclocal) exhausts its heap. Yes, it is possible for a recursion bug to cause this, but it seems odd that upgrading to a newer m4 fixes the problem; generally, if you have a recursion bug in your configure.ac, then it would run out of memory independently of m4 version. | | Could some additional tracing be enabled even if we need to edit whatever ? Yes. Within configure.ac, you can use m4_traceon/m4_traceoff, or add messages to grep for. With autom4te, you can use the --trace command to trace a particular macro; the trace output generally appears under the autom4te.cache directory. And don't rule out the idea of temporarily commenting out portions of configure.ac (or the files it includes) to see if you can narrow in on the culprit code, even if commenting stuff out breaks the resulting configure file. - -- Don't work too hard, make some time for fun as well! Eric Blake ebb9@xxxxxxx -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiRLj4ACgkQ84KuGfSFAYCXdACfeembwgvLcVrNjdKX1/lifUBV QDoAnRj/vkFnrog5UxCQ3+aQHvM/i+f7 =dgTx -----END PGP SIGNATURE----- _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
