In this commit:
commit 6108fd1823
Date: Thu Sep 17 11:47:50 2020 -0600
Use htab_up in type copying
A use after free bug was introduced. In compile-object-run.c, in the
function compile_object_run, the code used to look like this:
htab_t copied_types;
/* .... snip .... */
/* OBJFILE may disappear while FUNC_TYPE still will be in use. */
copied_types = create_copied_types_hash (objfile);
func_type = copy_type_recursive (objfile, func_type, copied_types);
htab_delete (copied_types);
/* .... snip .... */
call_function_by_hand_dummy (func_val, NULL, args,
do_module_cleanup, data);
The copied_types table exists on the obstack of objfile, but is
deleted once the call to copy_type_recursive has been completed.
After the change the code now looks like this:
/* OBJFILE may disappear while FUNC_TYPE still will be in use. */
htab_up copied_types = create_copied_types_hash (objfile);
func_type = copy_type_recursive (objfile, func_type, copied_types.get ());
/* .... snip .... */
call_function_by_hand_dummy (func_val, NULL, args,
do_module_cleanup, data);
The copied_types is now a unique_ptr and deleted automatically when it
goes out of scope.
The problem however is that objfile, and its included obstack, may be
deleted by the call to do_module_cleanup, which is called by
call_function_by_hand_dummy.
This means that in the new code the objfile, and its obstack, are
deleted before copied_types is deleted, and as copied_types is on the
objfiles obstack, we are now reading undefined memory.
The solution in this commit is to wrap the call to
create_copied_types_hash and copy_type_recursive into a new static
helper function. The htab_up will then be deleted within the new
function's scope, before objfile is deleted.
This resolves some non-deterministic test failures I was seeing in
gdb.compile/*.exp tests.
gdb/ChangeLog:
* compile/compile-object-run.c (create_copied_type_recursive): New
function.
(compile_object_run): Use new function.
0295dde655