This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix ASAN crash for gdb.compile/compile.exp
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 19 May 2015 14:35:36 +0200
- Subject: Re: [patch] Fix ASAN crash for gdb.compile/compile.exp
- Authentication-results: sourceware.org; auth=none
- References: <20150418170138 dot GA9123 at host1 dot jankratochvil dot net> <867fs4ssb6 dot fsf at gmail 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