Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MAD: printing variables in stack frames other than the current one gives incorrect results #301

Closed
lutzhamel opened this issue Dec 12, 2023 · 1 comment · Fixed by #304
Closed
Assignees
Labels
bug Something isn't working

Comments

@lutzhamel
Copy link
Collaborator

Printing variables in stack frames other than the current one gives incorrect results. Consider the program,

load system io.

function fact
   with 0 do
      1
   with n do
      n*fact(n-1)
end

io @println (fact 3)

when using MAD ,

lutz$ asteroid -d fact.ast
Minimal Asteroid Debugger 0.0.1
(c) University of Rhode Island
type "help" for additional information
mad> next
>  1 load system io.
   2 
   3 function fact
   4    with 0 do
   5       1
mad> next
   1 load system io.
   2 
>  3 function fact
   4    with 0 do
   5       1
   6    with n do
   7       n*fact(n-1)
mad> set 7
mad> cont
reached breakpoint (fact.ast:7)
   4    with 0 do
   5       1
   6    with n do
>  7       n*fact(n-1)
   8 end
   9 
   10 io @println (fact 3)
   11 
mad> cont
reached breakpoint (fact.ast:7)
   4    with 0 do
   5       1
   6    with n do
>  7       n*fact(n-1)
   8 end
   9 
   10 io @println (fact 3)
   11 
mad> stack
Runtime stack (most recent call first):
frame #0: fact.ast @fact
frame #1: fact.ast @fact
frame #2: fact.ast @<toplevel>
mad> print n
n: 2
mad> up
you are looking at frame #1
mad> print n
n: 2                        <<<< this should be 3
mad> 

Notice that we keep returning the value of n associated with the current frame.

@lutzhamel lutzhamel added the bug Something isn't working label Dec 12, 2023
@NicholasRM
Copy link
Contributor

This seems like something that happens with how the debugger handles print * and print $SYM. Calling print * tells the debugger to load the current stack frame from the SymTab with MAD's self.frame_ix. However, print $SYM is handled by calling the SymTab method .lookup_sym(), which then calls .find_sym_dict() to return the first dictionary that contains a specific symbol. This is why calling print * correctly displays the value of n in different scopes.

Minimal Asteroid Debugger 0.0.1
(c) University of Rhode Island
type "help" for additional information
mad> next
>  1 load system io.
   2
   3 function fact
   4    with 0 do
   5       1
mad> next
   1 load system io.
   2
>  3 function fact
   4    with 0 do
   5       1
   6    with n do
   7       n*fact(n-1)
mad> set 7
mad> cont
reached breakpoint (.\fact.ast:7)
   4    with 0 do
   5       1
   6    with n do
>  7       n*fact(n-1)
   8 end
   9
   10 io @println (fact 3
   11 [EOF]
mad> cont
reached breakpoint (.\fact.ast:7)
   4    with 0 do
   5       1
   6    with n do
>  7       n*fact(n-1)
   8 end
   9
   10 io @println (fact 3
   11 [EOF]
mad> stack
Runtime stack (most recent call first):
frame #0: .\fact.ast @fact
frame #1: .\fact.ast @fact
frame #2: .\fact.ast @<toplevel>
mad> print n
n: 2
mad> up
you are looking at frame #1
mad> print n
n: 2
mad> print *
n: 3
mad> down
you are looking at frame #0
mad> print *
n: 2
mad>

This else branch in ._handle_print()may need to get the current scope instead of looking up the symbol from the table directly.

# mad.py
def _handle_print(self,args):
      # ...
      if args[0] == '*':
         var_list = self.interp_state.symbol_table.get_curr_scope(scope=self.frame_ix, option="items")
         for (name,val) in var_list:
            print("{}: {}".format(name,term2string(val)))
      else:
         val = self.interp_state.symbol_table.lookup_sym(args[0],strict=False)
         if not val:
            print("error: variable {} not found".format(args[0]))
         else:
            print("{}: {}".format(args[0],term2string(val)))
      return START_DEBUGGER

@NicholasRM NicholasRM self-assigned this Feb 1, 2024
NicholasRM added a commit that referenced this issue Feb 6, 2024
@NicholasRM NicholasRM linked a pull request Feb 13, 2024 that will close this issue
NicholasRM added a commit that referenced this issue Feb 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants