From: Pedro Alves <pedro@codesourcery.com>
To: Paul Pluzhnikov <ppluzhnikov@google.com>
Cc: gdb-patches@sourceware.org, Yao Qi <yao@codesourcery.com>
Subject: Re: [patch] Fix leak of bp_jit_event breakpoints
Date: Thu, 27 Jan 2011 14:15:00 -0000 [thread overview]
Message-ID: <201101271244.09767.pedro@codesourcery.com> (raw)
In-Reply-To: <AANLkTikLk0CxeXwMNDiOcQMds=GuXJb6FV2fD++HLevu@mail.gmail.com>
Hi Paul, sorry for the delay in getting back to this.
On Thursday 27 January 2011 23:27:39, Paul Pluzhnikov wrote:
>
> +struct jit_inferior_data {
Put the { on it's own line, please.
> + struct breakpoint *breakpoint;
> + CORE_ADDR breakpoint_addr;
> + CORE_ADDR descriptor_addr;
> +};
> +static struct jit_inferior_data *
> +get_jit_inferior_data (void)
Please add a small describing blurb over functions.
> + if (inf_data->breakpoint != NULL)
> + {
> + if (inf_data->breakpoint_addr == inf_data->breakpoint->loc->address)
> + /* Same location as on last run. Existing breakpoint is good. */
> + return 0;
I'm a little warry about this optimization. For example,
we should probably also compare other things, like
gdbarch and location's pspace|aspace. Is it
a significant difference if we always delete the breakpoint
(here or perhaps on inferior exit?)
There's at least one problem to solve: on "exec",
update_breakpoints_after_exec deletes bp_jit_event
breakpoints, effectively making it so that your
inf_data->breakpoint pointer becomes stale. There may
be other paths that delete the breakpoint behind jit.c's
back. One solution would be to get rid of the breakpoint
pointer in jit.c, and add a remove_jit_event_breakpoints
function, modelled on remove_solib_event_breakpoints. But
if you want to come up with other solutions, I'd be happy
to consider them. I'm thinking that we should delete the
jit breakpoint (and perhaps more) whenever the executable
changes (say, the "file" command), which is kind of
a similar case of an "exec", so maybe we should install
an executable_changed observer as well. Not sure that
covers all we need.
> +
> + /* Location has changed since last run. */
> + delete_breakpoint (inf_data->breakpoint);
> + }
--
Pedro Alves
next prev parent reply other threads:[~2011-01-27 12:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-19 20:49 Paul Pluzhnikov
2011-01-19 21:14 ` Pedro Alves
2011-01-20 7:17 ` Paul Pluzhnikov
2011-01-21 1:11 ` Paul Pluzhnikov
2011-01-26 19:48 ` Paul Pluzhnikov
2011-01-27 14:15 ` Pedro Alves [this message]
2011-01-27 22:59 ` Paul Pluzhnikov
2011-01-28 1:27 ` Pedro Alves
2011-01-28 18:02 ` Paul Pluzhnikov
2011-01-28 20:38 ` Pedro Alves
2011-01-31 22:00 ` Paul Pluzhnikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201101271244.09767.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=ppluzhnikov@google.com \
--cc=yao@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox