Re: [pph] Free buffers used during tree encoding/decoding

[Gabriel Charette <gchare at google dot com>]

My linemap implementation just caught a very important failure due to
this patch (because of it's massive use of pph_in_string for
filenames).

We CANNOT free stream->encoder.r.file_data this early as it contains
all of the strings streamed in (which are refered to directly from all
over the place (pointers passed back by lto_input_string).

We will probably need the strings in here until the end of the
compilation, so we could either just not free it (i.e. memory leak,
but allow important when program is over...)

Or we could strcpy the strings pph'ed in, but that involves
duplication of identical strings, unless we use a cache-like trick for
this.

Or we could put it in a side table that we free at the end of the
compilation (or whenever the strings are no longer needed, but I was
getting some seg faults deep down in the compilation because of this
memory issue).

On a positive note: with this fixed (I just commented out the free
line (pph-streamer.c:179) for now to try it), my linemap
implementation is now complete and makes c1eabi1.cc pass (and
p4eabi1's asm diff has changed, I'll look into that now).

Gab

On Fri, Jul 29, 2011 at 4:16 PM, Lawrence Crowl <crowl@google.com> wrote:
> I removed the build directories and rebuilt. ?Everything worked.
> There are gremlins in the machine.
>
> On 7/29/11, Gabriel Charette <gchare@google.com> wrote:
>> I just stashed all my changes and pulled in the latest svn HEAD this
>> morning to check if I was seeing these failures:
>>
>> Repository Root: svn+ssh://gcc.gnu.org/svn/gcc
>> Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
>> Revision: 176906
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: crowl
>> Last Changed Rev: 176906
>> Last Changed Date: 2011-07-28 16:18:55 -0700 (Thu, 28 Jul 2011)
>>
>> I did a successful build + pph check of both debug and opt builds
>> (incremental build only, I didn't actually need to start from scratch;
>> however I was stashing changes to some headers in libcpp, so
>> potentially that rebuilt somethings that weren't rebuilt in a smaller
>> incremental build if there is a missing dependency..?)
>>
>> Gab
>>
>> On Thu, Jul 28, 2011 at 10:01 PM, Diego Novillo <dnovillo@google.com> wrote:
>>> On Thu, Jul 28, 2011 at 16:30, Lawrence Crowl <crowl@google.com> wrote:
>>>> I'm getting massive failures after incorporating this change:
>>>>
>>>> ? bytecode stream: trying to read 1735 bytes after the end of the
>>>> ? input buffer
>>>>
>>>> where the number of bytes changes. ?Suggestions?
>>>
>>> Odd. ?I'm getting the usual results with:
>>>
>>> $ git svn info
>>> Path: .
>>> URL: svn+ssh://gcc.gnu.org/svn/gcc/branches/pph/gcc
>>> Repository Root: svn+ssh://gcc.gnu.org/svn/gcc
>>> Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
>>> Revision: 176671
>>> Node Kind: directory
>>> Schedule: normal
>>> Last Changed Author: gchare
>>> Last Changed Rev: 176671
>>> Last Changed Date: 2011-07-22 21:04:48 -0400 (Fri, 22 Jul 2011)
>>>
>>> Perhaps a file did not get rebuilt after you updated your tree? ?That
>>> may point to a Makefile dependency bug. ?Or maybe you have some local
>>> patch?
>>>
>>>
>>> Diego.
>>>
>>
>
>
> --
> Lawrence Crowl
>