[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::decladebug

Title:Digital Ladebug debugger
Moderator:TLE::LUCIA
Created:Fri Feb 28 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:969
Total number of notes:3959

959.0. "Assertion tripped when processing ELLIPSIS parameter" by GEMGRP::MONTELEONE () Tue May 20 1997 16:46

    
    
    I am working on debug support for processing an "unspecified number of 
    arguments" (i.e. "...") and came across the following problem with the V5.1
    ucode C++ compiler. The problem does not occur with GEM based compilers
    because such support is not yet implemented in them. Since I am working
    towards such support, it would be nice to have the debugger behave
    properly.
    
    int foo(...);
    
    int foo(int fooparam,int barparam,...) {
    
    return 3;
    
    }
    
    int main () { return foo(1,2,3); }
    
    whipit> lad e_old.out
    Welcome to the Ladebug Debugger Version 4.0-36
    ------------------
    object file name: e_old.out
    Reading symbolic information ...done
    (ladebug) bp foo
    [#1: stop in int foo(int, int, ...) ]
    (ladebug) r
    [1] stopped at [int foo(int, int, ...):6 0x1200020c0]
          6 return 3;
    (ladebug) where
    >0  0x1200020c0 in foo(fooparam=1, barparam=2, $$ellipsis=Invalid
    symbol descrip
    tor d_ellipsis for symbol $$ellipsis in Symbol::value(Frame*)
    Assertion failed: locp != NULL src/libsrc/ladebug/symbol.C 1193
    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 ...
    0x123ba9a8
    0x123be070
    0x1229a30c
    0x1229b6f8
    0x1229b174
    0x1229b7ec
    0x1229be50
    0x12232ac4
    0x122370b0
    0x122270fc
    0x1222423c
    end of diagnostic stack trace.
    
    
    Here is the symbol table - the $$ellipsis symbol is the symbol
    of interest:
    
    Binary of auxes:
      0. 0x00000000   0x00000018   0x00000009   0x00000018   0x00000018
      5. 0x0000000e   0x00000018
    
    
    Local Symbols:
    from file ellip.cxx   Printf aux if present
      0. ( 0)(   0) ellip.cxx  File       Text       symref 15
      1. ( 1)(0x1200020b0) foo(int, int, ...) Proc       Text       [ 2]
    endref 9, int
      2. ( 2)(   0) fooparam   Param      Abs        [ 4] int
      3. ( 2)( 0x8) barparam   Param      Abs        [ 4] int
      4. ( 2)( 0xc) $$ellipsis Param      Abs        indexNil
    **********************************************************
      5. ( 2)(0x10)            Block      Text       symref 8
      6. ( 3)( 0x1) <RESULT>   Local      Register   indexNil
      7. ( 2)(0x20)            End        Text       symref 5
      8. ( 1)(0x2c) foo(int, int, ...) End        Text       symref 1
      9. ( 1)(0x1200020e0) main       Proc       Text       [ 5] endref 14,
    int
     10. ( 2)(0x18)            Block      Text       symref 13
     11. ( 3)( 0x9) <RESULT>   Local      Register   indexNil
     12. ( 2)(0x48)            End        Text       symref 10
     13. ( 1)(0x60) main       End        Text       symref 9
     14. ( 0)(   0) ellip.cxx  End        Text       symref 0
    
    
     The value field of the symbol is a little suspect and I am going
     to clairfy this format via the Symbol Table Working Group; however
     ladebug should not assert, regardless.
    
     I have a V51 C++ ucode based compiler handy - let me know if you 
     need it...
    
    
     Bob
    
T.RTitleUserPersonal
Name
DateLines
959.1The storage class doesn't look good either...GEMGRP::MONTELEONETue May 20 1997 18:029
    
    
    On further thought, the scAbs associated with $$ellipsis is probably
    inappropriate as well. I still contend the debugger should do something
    other than assert, though...
    
    
    Bob