Re: [patch] Fix ASAN crash for gdb.compile/compile.exp

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Tue, 19 May 2015 13:46:53 +0200, Yao Qi wrote:
> Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> > Whether the objfile really should be already freed during
> > call_function_by_hand_dummy() I am not sure.
> 
> Is there any reason we release OBJFILE in the dummy frame dtor?  Why
> don't we register a cleanup to release in OBJFILE in compile_object_run?
> together with releasing compile_module?  'struct compile_module' has a
> field objfile, which should be released together with
> 'struct compile_module' instead of dummy_frame.

(gdb) break puts
Breakpoint 2 at 0x3830c6fd30: file ioputs.c, line 34.
(gdb) compile code puts("hello")
Breakpoint 2, _IO_puts (str=0x7ffff7ff8000 "hello") at ioputs.c:34
34	{
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(_gdb_expr) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) bt
#0  _IO_puts (str=0x7ffff7ff8000 "hello") at ioputs.c:34
#1  0x00007ffff7ff9183 in _gdb_expr (__regs=0x7ffff7ff7000) at gdb command line:1
#2  <function called from gdb>
#3  main (argc=1, argv=0x7fffffffd7a8) at gdb.c:25
(gdb) _

Now compile_object_run() called from line
	(gdb) compile code puts("hello")
has finished for a long time.  But we still need to have that injected code
OBJFILE valid when GDB is executing it.  Therefore OBJFILE is freed only from
destructor of the frame #1.

At the patched line of call_function_by_hand_dummy() the dummy frame
destructor has not yet been run but it will be run before the fetched NAME
will get used.

In fact I do not see now how to fix it differently than what the patch does.

Obviously all these ugly hacks are needed only because GDB does not have
convenient memory management like C++/Java/others.


Jan