Re: How to pinpoint aclocal failure

[Eric Blake]

-----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             address@hidden
-----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-----