[RFA/commit] Memory leak in on reading frame register

[Joel Brobecker]

> >> Not sure about this.
> >>
> >> How come this in bpstat_check_breakpoint_conditions didn't
> >> handle this issue already? :
> >>
> >> ...
> >>       /* We use value_mark and value_free_to_mark because it could
> >> 	 be a long time before we return to the command level and
> >> 	 call free_all_values.  We can't call free_all_values
> >> 	 because we might be in the middle of evaluating a
> >> 	 function call.  */
> >>       struct value *mark = value_mark ();
> >>
> >> ...
> >>       value_free_to_mark (mark);
> > 
> > An excellent question, which I will try to research in the next
> > couple of days!
> 
> Thanks.  I wonder whether the leaks come from constructing the
> current frame at each stop, instead of from evaluating
> breakpoint conditions.  E.g.., if we do a "step" over:
> 
>    while (1);
> 
> ... are we constantly leaking values until the user does
> ctrl-c?
> 
> That would suggest to me to that we should be doing
> value_mark/value_free_to_mark around each
> handle_inferior_event.

A very accurate guess, as it turns out. Condition evaluation
is not the problem, here, but indeed, we a couple of calls to
handle_inferior in addition to each call to
bpstat_check_breakpoint_conditions. The former are responsible
for the leak.

How about the attached patch?

gdb/ChangeLog:

        * infrun.c (handle_inferior_event_1): Renames handle_inferior_event.
        (handle_inferior_event): New function.

Tested on x86_64-linux. No regression.

Thanks!
-- 
Joel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Memory-leak-reading-frame-register-during-inferior-e.patch
Type: text/x-diff
Size: 2306 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20150515/80254985/attachment.bin>