Re: [PATCH] Fix faulty use of obstack_free() to *shrink* dont_print_statmem_obstack. Instead use obstack_blank_fast() with a "negative" size. A real stack data structured would be appropriate here. Added unit test gdb/testsuite/gdb.cp/printstaticrecursion.exp.

[Simon Marchi <simon dot marchi at ericsson dot com>]

On 2017-10-23 03:37 PM, Simon Marchi wrote:
> I've stepped over the obstack_free call and noticed something strange, it changes the
> value of obstack::object_base...
> 
> (top-gdb) p dont_print_statmem_obstack
> $6 = {chunk_size = 256, chunk = 0x3b8b5a0, object_base = 0x3b8b5b0 "2\020`",
>   next_free = 0x3b8sb5c0 "0\270\270\003", chunk_limit = 0x3b8b6a0 "p\265\270\003", temp = {i = 0,
>     p = 0x0}, alignment_mask = 15, chunkfun = {plain = 0x798604 <xmalloc(size_t)>,
>     extra = 0x798604 <xmalloc(size_t)>}, freefun = {plain = 0x798732 <xfree(void*)>,
>     extra = 0x798732 <xfree(void*)>}, extra_arg = 0x0, use_extra_arg = 0, maybe_empty_object = 0,
>   alloc_failed = 0}
> (top-gdb) p free_to_ptr
> $7 = (void *) 0x3b8b5b8
> (top-gdb) n
> 383		  if (last_set_recurse != recurse)
> (top-gdb) p dont_print_statmem_obstack
> $8 = {chunk_size = 256, chunk = 0x3b8b5a0, object_base = 0x3b8b5b8 "1\020`",
>   next_free = 0x3b8b5b8 "1\020`", chunk_limit = 0x3b8b6a0 "p\265\270\003", temp = {i = 0,
>     p = 0x0}, alignment_mask = 15, chunkfun = {plain = 0x798604 <xmalloc(size_t)>,
>     extra = 0x798604 <xmalloc(size_t)>}, freefun = {plain = 0x798732 <xfree(void*)>,
>     extra = 0x798732 <xfree(void*)>}, extra_arg = 0x0, use_extra_arg = 0, maybe_empty_object = 0,
>   alloc_failed = 0}
> 
> 
> As you can see, object_base goes from 0x3b8b5b0 to 0x3b8b5b8.  And indeed, looking at obstack_free,
> I see:
> 
>        if (__obj > (void *) __o->chunk && __obj < (void *) __o->chunk_limit)  \
> 	 __o->next_free = __o->object_base = (char *) __obj;		      \
> 
> So when you free, it resets object_base to that point... why does it do that?  It doesn't make sense
> to me.
> 
> At least, that seems to explain why the obstack is empty after having called
> obstack_free, even though we didn't ask it to free the whole obstack.
> 
> Simon
> 

After following a crash course about obstacks on IRC (thanks Tom!), I understood that obstack_free
is normally used to free completed objects.  object_base points to the beginning of the object
currently being constructed, so obstack_free sets it to the beginning of the newly freed area,
so that the next object to be constructed will be placed there.

In the libc manual [1], it is stated clearly that obstack_blank should be used with a negative
size to make the current object smaller:

  You can use obstack_blank with a negative size argument to make the current object smaller.
  Just don’t try to shrink it beyond zero length—there’s no telling what will happen if you
  do that.

For negative sizes, obstack_blank seems equivalent to obstack_blank_fast.  So I am now
pretty much convinced that your fix is good, in that it does what the original code
intended (but failed) to do.  Could you address the comments from my previous mails
and submit a new version?  While at it, I noticed there is a missing space in:

  obstack_blank_fast(&dont_print_statmem_obstack, shrink_bytes);

before the opening parenthesis.

Thanks!

Simon

[1] https://www.gnu.org/software/libc/manual/html_node/Growing-Objects.html#Growing-Objects