* [RFA] dwarf2loc, guard against null
@ 2007-09-17 12:04 Jerome Guitton
2007-09-17 12:15 ` Daniel Jacobowitz
0 siblings, 1 reply; 8+ messages in thread
From: Jerome Guitton @ 2007-09-17 12:04 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 189 bytes --]
get_frame_function can return null; in this case, crash...
OK to apply?
2007-09-17 Jerome Guitton <guitton@adacore.com>
* dwarf2loc.c (dwarf_expr_frame_base): Guard against NULL.
[-- Attachment #2: dwarf2loc.c.diff --]
[-- Type: text/x-diff, Size: 436 bytes --]
Index: dwarf2loc.c
===================================================================
--- dwarf2loc.c (revision 14570)
+++ dwarf2loc.c (working copy)
@@ -151,6 +151,9 @@ dwarf_expr_frame_base (void *baton, gdb_
framefunc = get_frame_function (debaton->frame);
+ if (!framefunc)
+ error (_("No frame function."));
+
if (SYMBOL_OPS (framefunc) == &dwarf2_loclist_funcs)
{
struct dwarf2_loclist_baton *symbaton;
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [RFA] dwarf2loc, guard against null 2007-09-17 12:04 [RFA] dwarf2loc, guard against null Jerome Guitton @ 2007-09-17 12:15 ` Daniel Jacobowitz 2007-09-17 12:27 ` Jerome Guitton 0 siblings, 1 reply; 8+ messages in thread From: Daniel Jacobowitz @ 2007-09-17 12:15 UTC (permalink / raw) To: Jerome Guitton; +Cc: gdb-patches On Mon, Sep 17, 2007 at 02:04:43PM +0200, Jerome Guitton wrote: > > get_frame_function can return null; in this case, crash... > > OK to apply? > > 2007-09-17 Jerome Guitton <guitton@adacore.com> > > * dwarf2loc.c (dwarf_expr_frame_base): Guard against NULL. I'm not sure - there must be another bug so it might be this should be a gdb_assert instead. The DW_AT_frame_base that brought us here came from .debug_info inside an entry for a function. So we must have found the function at some point. But we didn't find the function this time - why not? -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFA] dwarf2loc, guard against null 2007-09-17 12:15 ` Daniel Jacobowitz @ 2007-09-17 12:27 ` Jerome Guitton 2007-09-17 12:30 ` Daniel Jacobowitz 0 siblings, 1 reply; 8+ messages in thread From: Jerome Guitton @ 2007-09-17 12:27 UTC (permalink / raw) To: gdb-patches Daniel Jacobowitz (drow@false.org): > I'm not sure - there must be another bug so it might be this should be > a gdb_assert instead. The DW_AT_frame_base that brought us here came > from .debug_info inside an entry for a function. So we must have > found the function at some point. But we didn't find the function > this time - why not? Hmmm... Let me have a closer look. In my case, the problem appears when debugging an application on VxWorks, with this scenario: * breakpoint hit; * print the address of a variable in the current frame (print &DB); * resume the execution; program exited normally; * retry to print the variable => end up in dwarf_expr_frame_base, no frame, crash. We are (probably) still using a wrong .debug_info at this point. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFA] dwarf2loc, guard against null 2007-09-17 12:27 ` Jerome Guitton @ 2007-09-17 12:30 ` Daniel Jacobowitz 2007-09-17 13:10 ` Jerome Guitton 0 siblings, 1 reply; 8+ messages in thread From: Daniel Jacobowitz @ 2007-09-17 12:30 UTC (permalink / raw) To: gdb-patches On Mon, Sep 17, 2007 at 02:26:54PM +0200, Jerome Guitton wrote: > * retry to print the variable => end up in dwarf_expr_frame_base, > no frame, crash. > > We are (probably) still using a wrong .debug_info at this point. Yeah. Shouldn't you have gotten a "no such variable in this scope" error? I'm not sure how symbol lookup found a local variable without any frame. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFA] dwarf2loc, guard against null 2007-09-17 12:30 ` Daniel Jacobowitz @ 2007-09-17 13:10 ` Jerome Guitton 2007-09-17 13:20 ` Daniel Jacobowitz 0 siblings, 1 reply; 8+ messages in thread From: Jerome Guitton @ 2007-09-17 13:10 UTC (permalink / raw) To: gdb-patches Daniel Jacobowitz (drow@false.org): > On Mon, Sep 17, 2007 at 02:26:54PM +0200, Jerome Guitton wrote: > > * retry to print the variable => end up in dwarf_expr_frame_base, > > no frame, crash. > > > > We are (probably) still using a wrong .debug_info at this point. > > Yeah. Shouldn't you have gotten a "no such variable in this scope" > error? I'm not sure how symbol lookup found a local variable without > any frame. Right. Actually, it got the selected frame (deprecated_selected_frame) in deprecated_safe_get_selected_frame. This function reads: struct frame_info * deprecated_safe_get_selected_frame (void) { if (!target_has_registers || !target_has_stack || !target_has_memory) return NULL; return get_selected_frame (NULL); } When the inferior is dead, target_has_registers (resp. target_has_memory, target_has_stack) should be false and deprecated_safe_get_selected_frame should return NULL. This is the bug in my vxWorks-specific backend (I should pop some target vector at mourn_inferior, I guess). Anyway, when deprecated_safe_get_selected_frame returns NULL, I get the message "Address of "db" is unknown". Much better. Now back to the original problem: assertion or error? I guess that the question is: in which cases get_frame_block can return NULL? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFA] dwarf2loc, guard against null 2007-09-17 13:10 ` Jerome Guitton @ 2007-09-17 13:20 ` Daniel Jacobowitz 2007-09-17 13:42 ` Jerome Guitton 0 siblings, 1 reply; 8+ messages in thread From: Daniel Jacobowitz @ 2007-09-17 13:20 UTC (permalink / raw) To: Jerome Guitton; +Cc: gdb-patches On Mon, Sep 17, 2007 at 03:10:52PM +0200, Jerome Guitton wrote: > When the inferior is dead, target_has_registers (resp. > target_has_memory, target_has_stack) should be false and > deprecated_safe_get_selected_frame should return NULL. This is the bug > in my vxWorks-specific backend (I should pop some target vector at > mourn_inferior, I guess). Yes, that's probably it. If you stay connected to the target after mourning, you may want to look at the new target_mark_exited. I haven't had time to contribute the target extended-remote bits that go along with that yet but soon, soon... > Now back to the original problem: assertion or error? I guess that the > question is: in which cases get_frame_block can return NULL? Assertion, please. If we found a frame-relative symbol then it was certainly within some function associated with a frame. If we can't find the frame, something has gone wrong. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFA] dwarf2loc, guard against null 2007-09-17 13:20 ` Daniel Jacobowitz @ 2007-09-17 13:42 ` Jerome Guitton 2007-09-17 13:52 ` Daniel Jacobowitz 0 siblings, 1 reply; 8+ messages in thread From: Jerome Guitton @ 2007-09-17 13:42 UTC (permalink / raw) To: gdb-patches [-- Attachment #1: Type: text/plain, Size: 743 bytes --] Daniel Jacobowitz (drow@false.org): > Yes, that's probably it. If you stay connected to the target after > mourning, you may want to look at the new target_mark_exited. I > haven't had time to contribute the target extended-remote bits that > go along with that yet but soon, soon... OK, thanks for your help. > Assertion, please. If we found a frame-relative symbol then it was > certainly within some function associated with a frame. If we can't > find the frame, something has gone wrong. OK, makes sense. I will commit the patch in attachment. 2007-09-17 Jerome Guitton <guitton@adacore.com> * dwarf2loc.c (dwarf_expr_frame_base): Guard against NULL. Part of G917-008. * Makefile.in (dwarf2loc.o): Depend on gdb_assert.h. [-- Attachment #2: dwarf2loc.c.diff --] [-- Type: text/x-diff, Size: 1821 bytes --] Index: gdb/Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/Makefile.in,v retrieving revision 1.936 diff -u -p -r1.936 Makefile.in --- gdb/Makefile.in 5 Sep 2007 00:14:02 -0000 1.936 +++ gdb/Makefile.in 17 Sep 2007 13:41:35 -0000 @@ -1963,7 +1963,7 @@ dwarf2-frame.o: dwarf2-frame.c $(defs_h) dwarf2loc.o: dwarf2loc.c $(defs_h) $(ui_out_h) $(value_h) $(frame_h) \ $(gdbcore_h) $(target_h) $(inferior_h) $(ax_h) $(ax_gdb_h) \ $(regcache_h) $(objfiles_h) $(exceptions_h) $(elf_dwarf2_h) \ - $(dwarf2expr_h) $(dwarf2loc_h) $(gdb_string_h) + $(dwarf2expr_h) $(dwarf2loc_h) $(gdb_string_h) $(gdb_assert_h) dwarf2read.o: dwarf2read.c $(defs_h) $(bfd_h) $(symtab_h) $(gdbtypes_h) \ $(objfiles_h) $(elf_dwarf2_h) $(buildsym_h) $(demangle_h) \ $(expression_h) $(filenames_h) $(macrotab_h) $(language_h) \ Index: gdb/dwarf2loc.c =================================================================== RCS file: /cvs/src/src/gdb/dwarf2loc.c,v retrieving revision 1.45 diff -u -p -r1.45 dwarf2loc.c --- gdb/dwarf2loc.c 23 Aug 2007 18:08:28 -0000 1.45 +++ gdb/dwarf2loc.c 17 Sep 2007 13:41:36 -0000 @@ -37,6 +37,7 @@ #include "dwarf2loc.h" #include "gdb_string.h" +#include "gdb_assert.h" /* A helper function for dealing with location lists. Given a symbol baton (BATON) and a pc value (PC), find the appropriate @@ -145,6 +146,11 @@ dwarf_expr_frame_base (void *baton, gdb_ framefunc = get_frame_function (debaton->frame); + /* If we found a frame-relative symbol then it was certainly within + some function associated with a frame. If we can't find the frame, + something has gone wrong. */ + gdb_assert (framefunc != NULL); + if (SYMBOL_OPS (framefunc) == &dwarf2_loclist_funcs) { struct dwarf2_loclist_baton *symbaton; ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFA] dwarf2loc, guard against null 2007-09-17 13:42 ` Jerome Guitton @ 2007-09-17 13:52 ` Daniel Jacobowitz 0 siblings, 0 replies; 8+ messages in thread From: Daniel Jacobowitz @ 2007-09-17 13:52 UTC (permalink / raw) To: gdb-patches On Mon, Sep 17, 2007 at 03:42:46PM +0200, Jerome Guitton wrote: > OK, makes sense. I will commit the patch in attachment. > > 2007-09-17 Jerome Guitton <guitton@adacore.com> > > * dwarf2loc.c (dwarf_expr_frame_base): Guard against NULL. > Part of G917-008. > * Makefile.in (dwarf2loc.o): Depend on gdb_assert.h. Thanks! -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2007-09-17 13:52 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-09-17 12:04 [RFA] dwarf2loc, guard against null Jerome Guitton 2007-09-17 12:15 ` Daniel Jacobowitz 2007-09-17 12:27 ` Jerome Guitton 2007-09-17 12:30 ` Daniel Jacobowitz 2007-09-17 13:10 ` Jerome Guitton 2007-09-17 13:20 ` Daniel Jacobowitz 2007-09-17 13:42 ` Jerome Guitton 2007-09-17 13:52 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox