This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFA/DWARF] do not use dwarf2_per_objfile in dwarf2_per_objfile_free.


Hello,

This patch fixes a case of multiple calls freeing the same data
while free-ing objfiles that have child objfiles (separate debug
info, as is the case on Darwin targets). This causes a crash
the user does something that causes the debugger to try to unload
the old symbols before loading new ones - eg, when debugging
a new program, or after the program being debugged has been
rebuilt.

Following the code, free_objfile_separate_debug iterates over
all child objfiles of the parent objfile, calling free_objfile:

  for (child = objfile->separate_debug_objfile; child;)
    {
      struct objfile *next_child = child->separate_debug_objfile_link;
      free_objfile (child);
      child = next_child;
    }

This causes, among other things, the free'ing of the child objfile's
private data:

  /* Discard any data modules have associated with the objfile.  The function
     still may reference objfile->obfd.  */
  objfile_free_data (objfile);

This indirectly calls(back) dwarf2_per_objfile_free, which tries
to free the dwarf2read-specific data by using the dwarf2_per_objfile
global, eg:

  for (ix = 0; ix < dwarf2_per_objfile->n_comp_units; ++ix)

Even if we were lucky enough the first time around that this global
actually corresponds to the objfile being destroyed, the global
will still have the same value at the second iteration, and thus
become dangling. Indeed, after dwarf2_per_objfile_free returns
eventually back to free_objfile, free_objfile then deallocates
its objfile_obstack, where the dwarf2_per_objfile is allocated.

Ironically, there should be no need to access that global at all,
here, since the data is passed as an argument of the callback.
And it looks like the dwo/dwp/[...]-handling code is in fact already
using that argument, rather than the global.

This patch thus fixes the problem by doing the same, replacing
all references to DWARF2_PER_OBJFILE by uses of DATA instead.

gdb/ChangeLog:

        * dwarf2read.c (dwarf2_per_objfile): Replace uses of
        DWARF2_PER_OBJFILE by uses of DATA instead.

Tested on x86_64-linux. Also tested on x86_64-darwin, with AdaCore's
testsuite.

OK to commit?

Thanks,
-- 
Joel

---
 gdb/dwarf2read.c |   11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index 55b1b17..27dc8a6 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -20482,14 +20482,13 @@ dwarf2_per_objfile_free (struct objfile *objfile, void *d)
   struct dwarf2_per_objfile *data = d;
   int ix;
 
-  for (ix = 0; ix < dwarf2_per_objfile->n_comp_units; ++ix)
-    VEC_free (dwarf2_per_cu_ptr,
-	      dwarf2_per_objfile->all_comp_units[ix]->imported_symtabs);
+  for (ix = 0; ix < data->n_comp_units; ++ix)
+   VEC_free (dwarf2_per_cu_ptr, data->all_comp_units[ix]->imported_symtabs);
 
-  for (ix = 0; ix < dwarf2_per_objfile->n_type_units; ++ix)
+  for (ix = 0; ix < data->n_type_units; ++ix)
     VEC_free (dwarf2_per_cu_ptr,
-	      dwarf2_per_objfile->all_type_units[ix]->per_cu.imported_symtabs);
-  xfree (dwarf2_per_objfile->all_type_units);
+	      data->all_type_units[ix]->per_cu.imported_symtabs);
+  xfree (data->all_type_units);
 
   VEC_free (dwarf2_section_info_def, data->types);
 
-- 
1.7.10.4


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]