* Macro code crasher on re-run
@ 2003-11-03 4:07 Daniel Jacobowitz
2003-11-03 4:48 ` Jim Blandy
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Jacobowitz @ 2003-11-03 4:07 UTC (permalink / raw)
To: gdb, jimb
There's a bug in default_macro_scope. I was in the middle of working on
something else when GDB crashed, so I can't fix it now, and Jim probably can
think of a better fix than I can - hence this message :) Or I'll get to it
in a few days.
Here's the problem. I've just typed "run".
82 struct macro_scope *
83 default_macro_scope (void)
84 {
85 struct symtab_and_line sal;
86 struct macro_source_file *main;
87 struct macro_scope *ms;
88
89 /* If there's a selected frame, use its PC. */
90 if (deprecated_selected_frame)
91 sal = find_pc_line (get_frame_pc (deprecated_selected_frame), 0);
So deprecated_selected_frame is NULL...
92
93 /* If the target has any registers at all, then use its PC. Why we
94 would have registers but no stack, I'm not sure. */
95 else if (target_has_registers)
96 sal = find_pc_line (read_pc (), 0);
And target_has_registers is false.
97
98 /* If all else fails, fall back to the current listing position. */
99 else
100 {
101 /* Don't call select_source_symtab here. That can raise an
102 error if symbols aren't loaded, but GDB calls the expression
103 evaluator in all sorts of contexts.
104
105 For example, commands like `set width' call the expression
106 evaluator to evaluate their numeric arguments. If the
107 current language is C, then that may call this function to
108 choose a scope for macro expansion. If you don't have any
109 symbol files loaded, then get_current_or_default would raise an
110 error. But `set width' shouldn't raise an error just because
111 it can't decide which scope to macro-expand its argument in. */
112 struct symtab_and_line cursal =
113 get_current_source_symtab_and_line ();
114
115 sal.symtab = cursal.symtab;
116 sal.line = cursal.line;
117 }
So we initialize just the symtab and line pointers.
118
119 return sal_macro_scope (sal);
120 }
39 if (! sal.symtab
40 || ! sal.symtab->macro_table)
41 return 0;
Oops, uninitialized memory read. That else case can't work; Jim, should we
just return 0 from default_macro_scope if the target isn't running, or
is there a function I don't see somewhere to find the macrotab and
initialize the rest of the symtab? Should it be "sal = cursal"?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Macro code crasher on re-run
2003-11-03 4:07 Macro code crasher on re-run Daniel Jacobowitz
@ 2003-11-03 4:48 ` Jim Blandy
2003-11-03 4:56 ` Daniel Jacobowitz
0 siblings, 1 reply; 12+ messages in thread
From: Jim Blandy @ 2003-11-03 4:48 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
Daniel Jacobowitz <drow@mvista.com> writes:
> There's a bug in default_macro_scope.
Only one?!? :)
> 97
> 98 /* If all else fails, fall back to the current listing position. */
> 99 else
> 100 {
> 101 /* Don't call select_source_symtab here. That can raise an
> 102 error if symbols aren't loaded, but GDB calls the expression
> 103 evaluator in all sorts of contexts.
> 104
> 105 For example, commands like `set width' call the expression
> 106 evaluator to evaluate their numeric arguments. If the
> 107 current language is C, then that may call this function to
> 108 choose a scope for macro expansion. If you don't have any
> 109 symbol files loaded, then get_current_or_default would raise an
> 110 error. But `set width' shouldn't raise an error just because
> 111 it can't decide which scope to macro-expand its argument in. */
> 112 struct symtab_and_line cursal =
> 113 get_current_source_symtab_and_line ();
> 114
> 115 sal.symtab = cursal.symtab;
> 116 sal.line = cursal.line;
> 117 }
>
> So we initialize just the symtab and line pointers.
> 118
> 119 return sal_macro_scope (sal);
> 120 }
>
>
> 39 if (! sal.symtab
> 40 || ! sal.symtab->macro_table)
> 41 return 0;
>
> Oops, uninitialized memory read. That else case can't work; Jim, should we
> just return 0 from default_macro_scope if the target isn't running, or
> is there a function I don't see somewhere to find the macrotab and
> initialize the rest of the symtab? Should it be "sal = cursal"?
I don't follow. All default_macro_scope's callers check for null
return; it's documented to return zero at times. So you must be
talking about that code in sal_macro_scope itself. Line 39 refers to
sal.symtab, initialized by line 115, so you must be talking about line
40. But sal.symtab must be non-zero, or else we wouldn't reach the
right operand of the ||.
Or should I sleep and try again?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Macro code crasher on re-run
2003-11-03 4:48 ` Jim Blandy
@ 2003-11-03 4:56 ` Daniel Jacobowitz
2003-11-03 21:00 ` Jim Blandy
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Jacobowitz @ 2003-11-03 4:56 UTC (permalink / raw)
To: Jim Blandy; +Cc: gdb
On Sun, Nov 02, 2003 at 11:48:05PM -0500, Jim Blandy wrote:
>
> Daniel Jacobowitz <drow@mvista.com> writes:
> > There's a bug in default_macro_scope.
>
> Only one?!? :)
One at a time, one at a time.
>
> > 97
> > 98 /* If all else fails, fall back to the current listing position. */
> > 99 else
> > 100 {
> > 101 /* Don't call select_source_symtab here. That can raise an
> > 102 error if symbols aren't loaded, but GDB calls the expression
> > 103 evaluator in all sorts of contexts.
> > 104
> > 105 For example, commands like `set width' call the expression
> > 106 evaluator to evaluate their numeric arguments. If the
> > 107 current language is C, then that may call this function to
> > 108 choose a scope for macro expansion. If you don't have any
> > 109 symbol files loaded, then get_current_or_default would raise an
> > 110 error. But `set width' shouldn't raise an error just because
> > 111 it can't decide which scope to macro-expand its argument in. */
> > 112 struct symtab_and_line cursal =
> > 113 get_current_source_symtab_and_line ();
> > 114
> > 115 sal.symtab = cursal.symtab;
> > 116 sal.line = cursal.line;
> > 117 }
> >
> > So we initialize just the symtab and line pointers.
> > 118
> > 119 return sal_macro_scope (sal);
> > 120 }
> >
> >
> > 39 if (! sal.symtab
> > 40 || ! sal.symtab->macro_table)
> > 41 return 0;
> >
> > Oops, uninitialized memory read. That else case can't work; Jim, should we
> > just return 0 from default_macro_scope if the target isn't running, or
> > is there a function I don't see somewhere to find the macrotab and
> > initialize the rest of the symtab? Should it be "sal = cursal"?
>
> I don't follow. All default_macro_scope's callers check for null
> return; it's documented to return zero at times. So you must be
> talking about that code in sal_macro_scope itself. Line 39 refers to
> sal.symtab, initialized by line 115, so you must be talking about line
> 40. But sal.symtab must be non-zero, or else we wouldn't reach the
> right operand of the ||.
>
> Or should I sleep and try again?
>
Right. sal.symtab is nonzero. sal.symtab->macro_table, however, is
uninitialized. The short-circuit if on line 40 does not trigger, but
the remainder of sal_macro_scope assumes that sal.symtab->macro_table
is valid.
In my case it happens to be 0xB.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Macro code crasher on re-run
2003-11-03 4:56 ` Daniel Jacobowitz
@ 2003-11-03 21:00 ` Jim Blandy
2003-11-03 21:04 ` Daniel Jacobowitz
0 siblings, 1 reply; 12+ messages in thread
From: Jim Blandy @ 2003-11-03 21:00 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
Daniel Jacobowitz <drow@mvista.com> writes:
> > I don't follow. All default_macro_scope's callers check for null
> > return; it's documented to return zero at times. So you must be
> > talking about that code in sal_macro_scope itself. Line 39 refers to
> > sal.symtab, initialized by line 115, so you must be talking about line
> > 40. But sal.symtab must be non-zero, or else we wouldn't reach the
> > right operand of the ||.
> >
> > Or should I sleep and try again?
> >
>
> Right. sal.symtab is nonzero. sal.symtab->macro_table, however, is
> uninitialized. The short-circuit if on line 40 does not trigger, but
> the remainder of sal_macro_scope assumes that sal.symtab->macro_table
> is valid.
>
> In my case it happens to be 0xB.
Every symtab's macro_table field should be initialized, at least to
zero. Which symtab is it? Who creates it?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Macro code crasher on re-run
2003-11-03 21:00 ` Jim Blandy
@ 2003-11-03 21:04 ` Daniel Jacobowitz
2003-11-03 21:34 ` Jim Blandy
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Jacobowitz @ 2003-11-03 21:04 UTC (permalink / raw)
To: Jim Blandy; +Cc: gdb
On Mon, Nov 03, 2003 at 03:59:41PM -0500, Jim Blandy wrote:
>
> Daniel Jacobowitz <drow@mvista.com> writes:
> > > I don't follow. All default_macro_scope's callers check for null
> > > return; it's documented to return zero at times. So you must be
> > > talking about that code in sal_macro_scope itself. Line 39 refers to
> > > sal.symtab, initialized by line 115, so you must be talking about line
> > > 40. But sal.symtab must be non-zero, or else we wouldn't reach the
> > > right operand of the ||.
> > >
> > > Or should I sleep and try again?
> > >
> >
> > Right. sal.symtab is nonzero. sal.symtab->macro_table, however, is
> > uninitialized. The short-circuit if on line 40 does not trigger, but
> > the remainder of sal_macro_scope assumes that sal.symtab->macro_table
> > is valid.
> >
> > In my case it happens to be 0xB.
>
> Every symtab's macro_table field should be initialized, at least to
> zero. Which symtab is it? Who creates it?
If you thought I wasn't making sense, you were right. I really needed
some sleep when I wrote that.
My best guess is that the returned symtab belongs to the old (already
unloaded) binary. Which would put the bug somewhere else.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Macro code crasher on re-run
2003-11-03 21:04 ` Daniel Jacobowitz
@ 2003-11-03 21:34 ` Jim Blandy
2003-11-03 21:37 ` Daniel Jacobowitz
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Jim Blandy @ 2003-11-03 21:34 UTC (permalink / raw)
To: Daniel Jacobowitz, Andrew Cagney; +Cc: gdb
Daniel Jacobowitz <drow@mvista.com> writes:
> On Mon, Nov 03, 2003 at 03:59:41PM -0500, Jim Blandy wrote:
> >
> > Daniel Jacobowitz <drow@mvista.com> writes:
> > > > I don't follow. All default_macro_scope's callers check for null
> > > > return; it's documented to return zero at times. So you must be
> > > > talking about that code in sal_macro_scope itself. Line 39 refers to
> > > > sal.symtab, initialized by line 115, so you must be talking about line
> > > > 40. But sal.symtab must be non-zero, or else we wouldn't reach the
> > > > right operand of the ||.
> > > >
> > > > Or should I sleep and try again?
> > > >
> > >
> > > Right. sal.symtab is nonzero. sal.symtab->macro_table, however, is
> > > uninitialized. The short-circuit if on line 40 does not trigger, but
> > > the remainder of sal_macro_scope assumes that sal.symtab->macro_table
> > > is valid.
> > >
> > > In my case it happens to be 0xB.
> >
> > Every symtab's macro_table field should be initialized, at least to
> > zero. Which symtab is it? Who creates it?
>
> If you thought I wasn't making sense, you were right. I really needed
> some sleep when I wrote that.
>
> My best guess is that the returned symtab belongs to the old (already
> unloaded) binary. Which would put the bug somewhere else.
I haven't debugged it (only Daniel J. has seen the problem, as far as
I know), but I kind of suspect this change:
2003-10-22 Andrew Cagney <cagney@redhat.com>
* target.c (target_close): New function.
(debug_to_close): Use "target_close".
(push_target): Use "target_close".
(unpush_target): Use "target_close".
(pop_target): Use "target_close".
* target.h (struct target_ops): Add "to_xclose".
(target_open): Delete macro. Move comment to "to_open".
(target_close): Replace macro with function that takes a target.
* top.c (quit_target): Pass "current_target" to "target_close".
The to_close method of the "exec" target calls free_objfile, which
assumes that its callers call clear_symtab_users at some appropriate
time. This change seems to have introduced several new callers to
target_close, so it may have broken that assumption.
Having free_objfile require its callers to take care of things this
way is not very nice.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Macro code crasher on re-run
2003-11-03 21:34 ` Jim Blandy
@ 2003-11-03 21:37 ` Daniel Jacobowitz
2003-11-03 23:51 ` Jim Blandy
2003-11-03 21:46 ` David Carlton
2003-11-03 22:01 ` Andrew Cagney
2 siblings, 1 reply; 12+ messages in thread
From: Daniel Jacobowitz @ 2003-11-03 21:37 UTC (permalink / raw)
To: Jim Blandy; +Cc: Andrew Cagney, gdb
On Mon, Nov 03, 2003 at 04:33:44PM -0500, Jim Blandy wrote:
>
> Daniel Jacobowitz <drow@mvista.com> writes:
> > On Mon, Nov 03, 2003 at 03:59:41PM -0500, Jim Blandy wrote:
> > >
> > > Daniel Jacobowitz <drow@mvista.com> writes:
> > > > > I don't follow. All default_macro_scope's callers check for null
> > > > > return; it's documented to return zero at times. So you must be
> > > > > talking about that code in sal_macro_scope itself. Line 39 refers to
> > > > > sal.symtab, initialized by line 115, so you must be talking about line
> > > > > 40. But sal.symtab must be non-zero, or else we wouldn't reach the
> > > > > right operand of the ||.
> > > > >
> > > > > Or should I sleep and try again?
> > > > >
> > > >
> > > > Right. sal.symtab is nonzero. sal.symtab->macro_table, however, is
> > > > uninitialized. The short-circuit if on line 40 does not trigger, but
> > > > the remainder of sal_macro_scope assumes that sal.symtab->macro_table
> > > > is valid.
> > > >
> > > > In my case it happens to be 0xB.
> > >
> > > Every symtab's macro_table field should be initialized, at least to
> > > zero. Which symtab is it? Who creates it?
> >
> > If you thought I wasn't making sense, you were right. I really needed
> > some sleep when I wrote that.
> >
> > My best guess is that the returned symtab belongs to the old (already
> > unloaded) binary. Which would put the bug somewhere else.
>
> I haven't debugged it (only Daniel J. has seen the problem, as far as
> I know), but I kind of suspect this change:
>
> 2003-10-22 Andrew Cagney <cagney@redhat.com>
>
> * target.c (target_close): New function.
> (debug_to_close): Use "target_close".
> (push_target): Use "target_close".
> (unpush_target): Use "target_close".
> (pop_target): Use "target_close".
> * target.h (struct target_ops): Add "to_xclose".
> (target_open): Delete macro. Move comment to "to_open".
> (target_close): Replace macro with function that takes a target.
> * top.c (quit_target): Pass "current_target" to "target_close".
>
> The to_close method of the "exec" target calls free_objfile, which
> assumes that its callers call clear_symtab_users at some appropriate
> time. This change seems to have introduced several new callers to
> target_close, so it may have broken that assumption.
>
> Having free_objfile require its callers to take care of things this
> way is not very nice.
I was using the 6.0 branch when I found the problem, so that's not it.
It may be a related problem in a caller of free_objfile, though. Or
reread_objfile?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Macro code crasher on re-run
2003-11-03 21:37 ` Daniel Jacobowitz
@ 2003-11-03 23:51 ` Jim Blandy
2003-11-07 16:29 ` Daniel Jacobowitz
0 siblings, 1 reply; 12+ messages in thread
From: Jim Blandy @ 2003-11-03 23:51 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
Daniel Jacobowitz <drow@mvista.com> writes:
> I was using the 6.0 branch when I found the problem, so that's not it.
> It may be a related problem in a caller of free_objfile, though. Or
> reread_objfile?
You mean reread_symbols? It wouldn't be that, because that calls
clear_symtab_users itself. It's certainly a caller of free_objfile.
I think this is just going to take some debugging. Can you tell me
how to reproduce it?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Macro code crasher on re-run
2003-11-03 23:51 ` Jim Blandy
@ 2003-11-07 16:29 ` Daniel Jacobowitz
2003-11-10 23:38 ` Jim Blandy
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Jacobowitz @ 2003-11-07 16:29 UTC (permalink / raw)
To: Jim Blandy; +Cc: gdb
On Mon, Nov 03, 2003 at 06:50:38PM -0500, Jim Blandy wrote:
>
> Daniel Jacobowitz <drow@mvista.com> writes:
> > I was using the 6.0 branch when I found the problem, so that's not it.
> > It may be a related problem in a caller of free_objfile, though. Or
> > reread_objfile?
>
> You mean reread_symbols? It wouldn't be that, because that calls
> clear_symtab_users itself. It's certainly a caller of free_objfile.
>
> I think this is just going to take some debugging. Can you tell me
> how to reproduce it?
Develop a habit for recompiling programs while you're debugging them,
and use dwarf2 information. I didn't even have -g3 macro debug
information at all. Eventually you'll crash, either in the macro or
frame code.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Macro code crasher on re-run
2003-11-07 16:29 ` Daniel Jacobowitz
@ 2003-11-10 23:38 ` Jim Blandy
0 siblings, 0 replies; 12+ messages in thread
From: Jim Blandy @ 2003-11-10 23:38 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
Daniel Jacobowitz <drow@mvista.com> writes:
> On Mon, Nov 03, 2003 at 06:50:38PM -0500, Jim Blandy wrote:
> >
> > Daniel Jacobowitz <drow@mvista.com> writes:
> > > I was using the 6.0 branch when I found the problem, so that's not it.
> > > It may be a related problem in a caller of free_objfile, though. Or
> > > reread_objfile?
> >
> > You mean reread_symbols? It wouldn't be that, because that calls
> > clear_symtab_users itself. It's certainly a caller of free_objfile.
> >
> > I think this is just going to take some debugging. Can you tell me
> > how to reproduce it?
>
> Develop a habit for recompiling programs while you're debugging them,
> and use dwarf2 information. I didn't even have -g3 macro debug
> information at all. Eventually you'll crash, either in the macro or
> frame code.
I did see some crashes last week, doing what you suggest, but I was in
a crunch and didn't have time to investigate. I'll see if I can do so
now.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Macro code crasher on re-run
2003-11-03 21:34 ` Jim Blandy
2003-11-03 21:37 ` Daniel Jacobowitz
@ 2003-11-03 21:46 ` David Carlton
2003-11-03 22:01 ` Andrew Cagney
2 siblings, 0 replies; 12+ messages in thread
From: David Carlton @ 2003-11-03 21:46 UTC (permalink / raw)
To: Jim Blandy; +Cc: Daniel Jacobowitz, gdb
On 03 Nov 2003 16:33:44 -0500, Jim Blandy <jimb@redhat.com> said:
> I haven't debugged it (only Daniel J. has seen the problem, as far as
> I know)
I've been getting occasional crashes when I'm in the middle of
debugging a program, I recompile it, and then I tell GDB to run it
again and that yes, I want to reload it. I did once run GDB on itself
when this happened (or maybe looked at a core file, I can't remember),
and macro stuff was involved somehow. So I may have seen the same
problem that Daniel's seeing, from a source base that's older than the
patch you mentioned.
David Carlton
carlton@kealia.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Macro code crasher on re-run
2003-11-03 21:34 ` Jim Blandy
2003-11-03 21:37 ` Daniel Jacobowitz
2003-11-03 21:46 ` David Carlton
@ 2003-11-03 22:01 ` Andrew Cagney
2 siblings, 0 replies; 12+ messages in thread
From: Andrew Cagney @ 2003-11-03 22:01 UTC (permalink / raw)
To: Jim Blandy; +Cc: gdb
>
> I haven't debugged it (only Daniel J. has seen the problem, as far as
> I know), but I kind of suspect this change:
>
> 2003-10-22 Andrew Cagney <cagney@redhat.com>
>
> * target.c (target_close): New function.
> (debug_to_close): Use "target_close".
> (push_target): Use "target_close".
> (unpush_target): Use "target_close".
> (pop_target): Use "target_close".
> * target.h (struct target_ops): Add "to_xclose".
> (target_open): Delete macro. Move comment to "to_open".
> (target_close): Replace macro with function that takes a target.
> * top.c (quit_target): Pass "current_target" to "target_close".
That's unlikely. The change re-aranged deck chairs.
Andrew
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2003-11-10 23:38 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-03 4:07 Macro code crasher on re-run Daniel Jacobowitz
2003-11-03 4:48 ` Jim Blandy
2003-11-03 4:56 ` Daniel Jacobowitz
2003-11-03 21:00 ` Jim Blandy
2003-11-03 21:04 ` Daniel Jacobowitz
2003-11-03 21:34 ` Jim Blandy
2003-11-03 21:37 ` Daniel Jacobowitz
2003-11-03 23:51 ` Jim Blandy
2003-11-07 16:29 ` Daniel Jacobowitz
2003-11-10 23:38 ` Jim Blandy
2003-11-03 21:46 ` David Carlton
2003-11-03 22:01 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).