[bug #68441] Entering "x ..." causes Octave to become unresponsive

Brendon Higgins <[email protected]> Thu, 11 Jun 2026 12:57:34 -0400 (EDT)
Newsgroups	gmane.comp.gnu.octave.bugs
Message-ID	<[email protected]>
Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only notification stream.  Info posted to this mailing list address won't appear in the tracker database where it is most useful.

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

                 Summary: Entering "x ..." causes Octave to become
unresponsive
                   Group: GNU Octave
               Submitter: blhiggins
               Submitted: Thu 11 Jun 2026 04:57:26 PM UTC
                Category: Interpreter
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
             Assigned to: None
         Originator Name:
        Originator Email:
             Open/Closed: Open
         Discussion Lock: Unlocked
                 Release: stable
        Operating System: Any
           Fixed Release: None
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Thu 11 Jun 2026 04:57:26 PM UTC By: Brendon Higgins <blhiggins>
I observed on Linux (Debian's) Octave 11.1.0 that entering the following
causes Octave to stop responding and the process to consume a full CPU core:

x ...
    = [1, 3]


This happens either in GUI mode or CLI mode.

I then observed on Windows Octave 11.3.0 that the interactive Octave interface
stops before even getting to type the second line: "x ..." followed by Enter
is enough. The surrounding GUI remains responsive, though.

I suspect it's somehow triggering an infinite loop in the parser.
		
If you wonder why would I ever want to try something this, consider this
example:

[longvariablename1, longvariablename2, longvariablename3] ...
    = longFunctionNameThatReturnsMultipleResults(longargumentname1,
longargumentname2, etc, etc)


Placing the = before the ellipsis seems to not trigger this problem, so that's
a workaround. But just the fact that the parser responds like I observed, for
any context, seems undesirable.







    _______________________________________________________

Reply to this item at:

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

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc (application/pgp-signature, 228 B)