From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
To: Simon Marchi <simon.marchi@ericsson.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [RFAv2] Fix leak in displaced step.
Date: Tue, 13 Nov 2018 17:02:00 -0000 [thread overview]
Message-ID: <1542055670.1531.5.camel@skynet.be> (raw)
In-Reply-To: <516d7e99-79da-9939-7ff0-ca79942985c8@ericsson.com>
On Mon, 2018-11-12 at 16:17 +0000, Simon Marchi wrote:
> From what I understand, the allocation model you propose in this patch is to
> allocate a buffer the first time we do a displaced step for an inferior and
> free it when the inferior exits.
Yes, that is the plan.
> The allocated size is
>
> len = gdbarch_max_insn_length (gdbarch);
>
> Given that there can be multiple architectures inside a single inferior, can
> the required buffer size change between multiple displaced step?
Good remark : I did not know of this multiple architecture for a
single inferior, and then yes possibly the buffer might have to change size.
So, we should rather do (unconditionally) :
displaced->step_saved_copy = (gdb_byte *) xrealloc (len);
>
> Also, if freeing the buffer on inferior exit is indeed what we want to do, why do
> we need the above cleanup? Even if the setup fails, shouldn't be fine to keep the buffer
> allocated?
The idea was to avoid having a piece of memory containing not properlyÂ
initialized data. But probably this is not a problem, as this data will
only be used if the displaced setup is finished, at the end of the function.
So, effectively no real need for the cleanup anymore.
Philippe
prev parent reply other threads:[~2018-11-13 17:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-11 12:11 Philippe Waroquiers
2018-11-12 15:35 ` David Blaikie
2018-11-12 16:17 ` Simon Marchi
2018-11-13 17:02 ` Philippe Waroquiers [this message]
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=1542055670.1531.5.camel@skynet.be \
--to=philippe.waroquiers@skynet.be \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@ericsson.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