* 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
[parent not found: <CABD==127dOrixY6KaHKBnycQV_+h1aMXPgT8h67Tkfka6GboGQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* 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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).