On 10/09/2014 01:36 PM, Eric Blake wrote: > In particular, autom4te --verbose shows this is the runaway command line: > > /usr/bin/m4 --nesting-limit=1024 --gnu --include=/usr/share/autoconf > --debug=aflq --fatal-warning --debugfile=/tmp/am4tSXlU7J/traces.0t > --trace=AM_GNU_GETTEXT_VERSION --trace=_m4_warn --trace=include > --trace=m4_include --trace=m4_pattern_allow --trace=m4_pattern_forbid > --reload-state=/usr/share/autoconf/autoconf/autoconf.m4f > --undefine=__m4_version__ - configure.ac > /tmp/am4tSXlU7J/output.0t
and adding --debug to keep the temp files, I note that the traces.0t file consistently gets stuck at: m4trace:configure.ac:506: -1- m4_pattern_allow([^LIBMOUNT_VERSION$]) m4trace:configure.ac:519: -1- m4_pattern_allow([^HAVE_LIBMOUNT_MOUNT$]) m4trace:configure.ac:546: -1- m4_pattern_allow([^H where configure.ac has at line 546: UTIL_CHECK_LIB(util, openpty) Alas, traces.0t is buffered, so it is not a precise point of where the loop is happening, but somewhere shortly after there is the culprit. I'm still trying to see if I can coax m4 into emitting more details about what is looping; I may have luck attaching a gdb process at the point it starts consuming memory... -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
