All of lore.kernel.org
 help / color / mirror / Atom feed
* libdwarves memory leaks in the stealer interface
@ 2016-07-14 19:58 Tavis Ormandy
       [not found] ` <CABD==127dOrixY6KaHKBnycQV_+h1aMXPgT8h67Tkfka6GboGQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 2+ messages in thread
From: Tavis Ormandy @ 2016-07-14 19:58 UTC (permalink / raw)
  To: dwarves-u79uwXL29TY76Z2rM5mHXA

Hello, I have a fun project that I'm trying to use libdwarves with,
but had a couple of questions.

I'm using the "steal" callback interface to search for a specific cu.
If the cu matches the one I was looking for, I process it and then
return LSK__STOP_LOADING to abort processing this file. If it's not
the cu I wanted, I just return LSK__DELETE.

This seems to do what I want, but leaks memory.

1) LSK__DELETE doesn't seem to clean up the dwarf_cu obstack, I think
this wasn't intended.
2) If die__process_and_recode() fails in finalize_cu_immediately(),
the cu is leaked. This one is definitely a bug :)

I'm not 100% sure if I'm using LSK__STOP_LOADING correctly. It doesn't
cleanup the cu like LSK__DELETE does, and it doesn't call cus__add()
like LSK__KEEPIT does, so was the stealer supposed to clean it up?

If so, how do I clean up the dcu? I think I can pull it out of
cu->priv, but I think you didn't intend to expose that to callbacks?

The patch I'm using is below.

Thanks for libdwarves, it's a really great library!

Tavis.

diff --git a/src/struct/dwarf_loader.c b/src/struct/dwarf_loader.c
index 163cb51..ba715a9 100644
--- a/src/struct/dwarf_loader.c
+++ b/src/struct/dwarf_loader.c
@@ -2169,9 +2169,12 @@ static int finalize_cu_immediately(struct cus
*cus, struct cu *cu,
  int lsk = finalize_cu(cus, cu, dcu, conf);
  switch (lsk) {
  case LSK__DELETE:
+ obstack_free(&dcu->obstack, NULL);
  cu__delete(cu);
  break;
  case LSK__STOP_LOADING:
+ obstack_free(&dcu->obstack, NULL);
+ cu__delete(cu);
  break;
  case LSK__KEEPIT:
  if (!cu->extra_dbg_info)
@@ -2304,8 +2307,11 @@ static int cus__load_module(struct cus *cus,
struct conf_load *conf,
  cu->priv = &dcu;
  cu->dfops = &dwarf__ops;

- if (die__process_and_recode(cu_die, cu) != 0)
+ if (die__process_and_recode(cu_die, cu) != 0) {
+ obstack_free(&dcu.obstack, NULL);
+ cu__delete(cu);
  return DWARF_CB_ABORT;
+ }

  if (finalize_cu_immediately(cus, cu, &dcu, conf)
     == LSK__STOP_LOADING)
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: libdwarves memory leaks in the stealer interface
       [not found] ` <CABD==127dOrixY6KaHKBnycQV_+h1aMXPgT8h67Tkfka6GboGQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2016-07-15  0:04   ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 2+ messages in thread
From: Arnaldo Carvalho de Melo @ 2016-07-15  0:04 UTC (permalink / raw)
  To: Tavis Ormandy; +Cc: dwarves-u79uwXL29TY76Z2rM5mHXA

Em Thu, Jul 14, 2016 at 12:58:07PM -0700, Tavis Ormandy escreveu:
> Hello, I have a fun project that I'm trying to use libdwarves with,
> but had a couple of questions.
> 
> I'm using the "steal" callback interface to search for a specific cu.
> If the cu matches the one I was looking for, I process it and then
> return LSK__STOP_LOADING to abort processing this file. If it's not
> the cu I wanted, I just return LSK__DELETE.
> 
> This seems to do what I want, but leaks memory.
> 
> 1) LSK__DELETE doesn't seem to clean up the dwarf_cu obstack, I think
> this wasn't intended.
> 2) If die__process_and_recode() fails in finalize_cu_immediately(),
> the cu is leaked. This one is definitely a bug :)
> 
> I'm not 100% sure if I'm using LSK__STOP_LOADING correctly. It doesn't
> cleanup the cu like LSK__DELETE does, and it doesn't call cus__add()
> like LSK__KEEPIT does, so was the stealer supposed to clean it up?
> 
> If so, how do I clean up the dcu? I think I can pull it out of
> cu->priv, but I think you didn't intend to expose that to callbacks?
> 
> The patch I'm using is below.

At first sight it is ok, i.e. it seems to fix the problem, but I think
the right place to do the free will be at:

  cu__delete()
     cu->dfops->cu__delete(cu);

Which for DWARF, maps to... nothing, I'll continue looking at this
tomorrow, its been a while I haven't touched this code :-\
 
> Thanks for libdwarves, it's a really great library!

Glad you liked it!
 
> Tavis.
> 
> diff --git a/src/struct/dwarf_loader.c b/src/struct/dwarf_loader.c
> index 163cb51..ba715a9 100644
> --- a/src/struct/dwarf_loader.c
> +++ b/src/struct/dwarf_loader.c
> @@ -2169,9 +2169,12 @@ static int finalize_cu_immediately(struct cus
> *cus, struct cu *cu,
>   int lsk = finalize_cu(cus, cu, dcu, conf);
>   switch (lsk) {
>   case LSK__DELETE:
> + obstack_free(&dcu->obstack, NULL);
>   cu__delete(cu);
>   break;
>   case LSK__STOP_LOADING:
> + obstack_free(&dcu->obstack, NULL);
> + cu__delete(cu);
>   break;
>   case LSK__KEEPIT:
>   if (!cu->extra_dbg_info)
> @@ -2304,8 +2307,11 @@ static int cus__load_module(struct cus *cus,
> struct conf_load *conf,
>   cu->priv = &dcu;
>   cu->dfops = &dwarf__ops;
> 
> - if (die__process_and_recode(cu_die, cu) != 0)
> + if (die__process_and_recode(cu_die, cu) != 0) {
> + obstack_free(&dcu.obstack, NULL);
> + cu__delete(cu);
>   return DWARF_CB_ABORT;
> + }
> 
>   if (finalize_cu_immediately(cus, cu, &dcu, conf)
>      == LSK__STOP_LOADING)
> --
> To unsubscribe from this list: send the line "unsubscribe dwarves" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-07-15  0:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-14 19:58 libdwarves memory leaks in the stealer interface Tavis Ormandy
     [not found] ` <CABD==127dOrixY6KaHKBnycQV_+h1aMXPgT8h67Tkfka6GboGQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-07-15  0:04   ` Arnaldo Carvalho de Melo

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.