[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug#764580: m4 eats memory for breakfast (fwd)
|
From: |
Eric Blake |
|
Subject: |
Re: Bug#764580: m4 eats memory for breakfast (fwd) |
|
Date: |
Thu, 09 Oct 2014 14:14:53 -0600 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 |
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