octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #61105] call to nested function triggers "inte


From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #61105] call to nested function triggers "internal error: invalid access link in function call stack"
Date: Wed, 1 Sep 2021 15:40:29 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

URL:
  <https://savannah.gnu.org/bugs/?61105>

                 Summary: call to nested function triggers "internal error:
invalid access link in function call stack"
                 Project: GNU Octave
            Submitted by: jwe
            Submitted on: Wed 01 Sep 2021 07:40:27 PM UTC
                Category: Interpreter
                Severity: 4 - Important
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: jwe
         Originator Name: jwe
        Originator Email: 
             Open/Closed: Open
                 Release: 6.3.0
         Discussion Lock: Any
        Operating System: Any

    _______________________________________________________

Details:

Calling the function


function r = bad_access ()
  a = 3;
  b = 5;
  c = 7;
  function r = f1 (f, x)
    r = f(x) + a;
  end
  function r = f2 (y)
    function r2 = f3 (z)
      r2 = z^2 + b*y;
    end
    r = f1 (@f3, y) + c;
  end
  r = f2 (2)
end


results in the following error:


error: internal error: invalid access link in function call stack
error: called from
    bad_access>f3 at line 10 column 10
    bad_access>f1 at line 6 column 7
    bad_access>f2 at line 12 column 7
    bad_access at line 14 column 5


Bisecting on the stable branch points to this changeset:


The first bad revision is:
changeset:   29832:6d1224698acf
branch:      stable
parent:      29825:290eff7148bb
user:        John W. Eaton <jwe@octave.org>
date:        Tue Jun 29 05:25:34 2021 -0400
summary:     fix scoping issue for handles to sibling nested functions (bug
#60845)


I don't think there is anything wrong with the logic of that change, but it
exposes a problem with storing parent function names in function objects in
some cases.  A possible fix is:


--- a/libinterp/corefcn/symscope.cc
+++ b/libinterp/corefcn/symscope.cc
@@ -197,6 +197,20 @@ namespace octave
   }
 
   void
+  symbol_scope_rep::cache_parent_fcn_names (const std::list<std::string>&
names)
+  {
+    m_parent_fcn_names = names;
+
+    if (m_code && m_code->is_user_function ())
+      {
+        octave_user_function *fcn
+          = dynamic_cast<octave_user_function *> (m_code);
+
+        fcn->stash_parent_fcn_name (names.front ());
+      }
+  }
+
+  void
   symbol_scope_rep::set_parent (const std::shared_ptr<symbol_scope_rep>&
parent)
   {
     m_parent = std::weak_ptr<symbol_scope_rep> (parent);
diff --git a/libinterp/corefcn/symscope.h b/libinterp/corefcn/symscope.h
--- a/libinterp/corefcn/symscope.h
+++ b/libinterp/corefcn/symscope.h
@@ -262,10 +262,7 @@ namespace octave
       return m_parent_fcn_names;
     }
 
-    void cache_parent_fcn_names (const std::list<std::string>& names)
-    {
-      m_parent_fcn_names = names;
-    }
+    void cache_parent_fcn_names (const std::list<std::string>& names);
 
     octave_user_code *user_code (void) const { return m_code; }
 


I'll check in a proper changeset with a test on the stable branch after I have
a bug report number.

While investigating this problem, I also found that we are storing info about
parent functions directly in the function object and also in the scope object
that the function contains. Since storing the same info in multiple places
almost always leads to trouble and this mess is almost certainly my work,
I’ll see if I can eliminate the duplication with another change on the
default branch.





    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61105>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]