[Top][All Lists]

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

Re: recent changes to obstacks cause many out of memory failures in M4 m

From: Gary V . Vaughan
Subject: Re: recent changes to obstacks cause many out of memory failures in M4 master testsuite
Date: Fri, 5 Dec 2014 20:56:19 +0000

Hi Eric,

> On Dec 5, 2014, at 7:11 PM, Eric Blake <address@hidden> wrote:
> On 12/05/2014 12:03 PM, Gary V. Vaughan wrote:
>> Bisecting my way to the the first gnulib changeset that causes these 
>> failures, I landed at:
>>  bb2ab7e 2014-10-29 14:02 Alan Modra   obstack: 64-bit obstack support, part 
>> 2
>> Which is not surprising as GNU M4 uses GNU obstack extensively throughout.
> I bet it has to do with this:
> src/builtin.c:      obstack_blank (data->obs, sizeof (symbol *));
> src/builtin.c:      obstack_blank_fast (obs, len);
> src/builtin.c:      obstack_blank (obs, -1);
> src/macro.c:   obstack_blank is documented to take a negative size to
> reduce the
> src/macro.c:  obstack_blank (&argv_stack, -argc * sizeof (token_data *));

ACK.  Only, on master I get:

$ grep obstack_blank `git ls-files`
grep: build-aux/gnulib: Is a directory
m4/macro.c:  obstack_blank (&context->trace_messages, start - len);
modules/gnu.c:              obstack_blank_fast (obs, len);
modules/m4.c:      obstack_blank (symbol_data->obs, sizeof *symbol_data->base);
modules/m4.c:      obstack_blank_fast (symbol_data->obs, sizeof 
modules/m4.c:      obstack_blank (obs, -1);
modules/m4.c:          obstack_blank (obs, min - uvalue);
modules/m4.c:      obstack_blank (obs, uvalue);
modules/m4.c:      obstack_blank (obs, min);

Changing just the call in macro.c to obstack_blank_fast does indeed allow the 
to pass again.  For correctness, I'll also change the `obstack_blank (obs, -1)` 
and audit the other call sites for possible changes along the same lines.

> vs. the discussion on gnulib that we intentionally changed upstream
> obstack_blank to no longer do this, and that you HAVE to use
> obstack_blank_fast to get that effect.

Bah, I didn't notice the nuances of that conversation at the time :-(  Thanks 
for the

Gary V. Vaughan (gary AT gnu DOT org)

reply via email to

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