Conference turris::decladebug

866.0. "W shouldn't do this..." by ADA9X::BRETT () Wed Mar 05 1997 11:06

The following shows that ladebug is going completely off the deep end
when trying to do a W command.  It is quite capable of being able to 
show you the current line being executed, but not the lines around
it!

/Bevin


% ladebug ~/eg029-for-ladebug
Welcome to the Ladebug Debugger Version 4.0-31
------------------
object file name: /usr/users/brett/eg029-for-ladebug

(ladebug) stop in main
[#1: stop in int main(void) ]
(ladebug) run
[1] stopped at [int main(void):20 0x120002190]
     20     Derived t;
(ladebug) n
stopped at [int main(void):21 0x120002198]
     21     return ((Base2*)&t)->frob();
(ladebug) s
stopped at [void __INTER__Derived_frob_Base2_Xv(void):14 0x12000216c]
     14     int frob() { return 0; }
(ladebug) alias W
W       list $curline - 10:20
(ladebug) W
      4
      5 class Base2 {
      6 public:
      7     virtual int frob() = 0;
      8 };
      9
     10
     11 class Derived: public Base1, public Base2 {
     11 class Derived: public Base1, public Base2 {
     12 public:
     13     Derived()  { }
>    14     int frob() { return 0; }
     15 };
     16
     17
     18 main()
     19 {
     20     Derived t;
     21     return ((Base2*)&t)->frob();
     22 }
(ladebug) n
stopped at [int Derived::frob(void):14 0x120002178]
     14     int frob() { return 0; }
(ladebug) W

Ladebug Debugger Version 4.0-31 caught signal "Segmentation fault" (11).
This is an unexpected condition and may indicate the presence of a defect.
If you wish to report this, please include the stack trace that follows.
Diagnostic stack trace ...
0x1250b414 : LanguageCPlusPlus::find(NamedScope*, SymbolList*, char*) const
0x1250ce3c : LanguageCPlusPlus::classfind(NamedScope*, SymbolList*, int&) const
0x1250ebd8 : LanguageCPlusPlus::restrict(Scope*, SymbolListOwn) const
0x1250dea0 : LanguageCPlusPlus::walkBack(Scope*, SymbolList*&, const int, const
int) const
0x1250ee60 : LanguageCPlusPlus::restrict(Scope*, SymbolListOwn) const
0x12393c64 : symbolType(char* const, Scope* const, const int, const int, const
i

nt)
0x123af7c0 : CXXlex(void)
0x12366898 : CXXparse(void)
0x123cc6f0 : DebuggerState::parser(void)
0x12314e64 : ProcessCommands(void)
0x1231bae0 : main
0x12264a6c : __start
end of diagnostic stack trace.
Fatal error: Segmentation fault

The crash in .0 occurs while using the modified ladebug I've given
Bevin, which I've fixed at the point of segv-ing.

But the question being raised here is why ladebug is doing this
type of work for a listing of lines?  I haven't had time to track
this down yet.

-Steve

Yeah, you'd think a listing of lines would be pretty simple, wouldn't you.
Well rest assured that dbx treats this in a rather tortuous fashion too.
The main point of all the work may be that this is really a multi-step
process by the way the "W" command is set up.  First you have to access the
current line, then you have to solve for the expression $curline-10
and then you have another expression built in, print 20 etc.  I'm pretty
sure that I've set breakpoints going through this code in the past,
and we seem to be doing extra calculations between the output of 
each line of source, rather than just blasting 20 lines of
it onto the screen.  AH!  Insight!  We do have to stop at each line
because we want to see if this is the line that you preface with
the >.  Dbx is somewhat different, in that we have the concept of the
current line '>' (which changes as you print more source), and the
current execution point '*'.

Not that I want to get you extra confused, or anything...


PeterT