bugGNU Octave - Bugs: bug #55980, Octave interpreter indent for...

 
 

bug #55980: Octave interpreter indent for print increases whenever octave_base_value::print error emitted

Submitted by:  Nikita <sirgienko>
Submitted on:  Fri 22 Mar 2019 09:22:13 PM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Confirmed Assigned to:  None
Originator Name:  Nikita Open/Closed:  Open
Release:  5.1.0 Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sat 23 Mar 2019 12:57:40 AM UTC, comment #4:

Here is a much simpler way to demonstrate the error

load sehrSchlect.mat
disp (ahrsEuler)
a = 1

Every call to disp() results in an error, and an extra indentation of 3 spaces.

Rik <rik5>
Project Administrator
Fri 22 Mar 2019 10:31:04 PM UTC, comment #3:

The problem is definitely related to the failure of the eval statement within the try/catch block.

The first variable that does this in the file sehrSchlect.mat is "ahrsEuler".  When I try to inspect the variable I get

ahrsEuler
ahrsEuler =

  scalar structure containing the fields:

    MCOS =

      3707764736
               2
               1
               1
               1
               2

    AHRSEulerEKF =

error: octave_base_value::print (): wrong type argument '<unknown type>'

My modified code for testing is below (and also attached as tst_print.m)

more off
load sehrSchlecht.mat
printf('__cantor_delimiter_line__\n');
__cantor_list__ = who();
__cantor_parse_values__ = true;
for __cantor_index__ = 1:length(__cantor_list__)
  __cantor_varname__ = char(__cantor_list__{__cantor_index__});
  printf([__cantor_varname__ '\n']);
  if (__cantor_parse_values__)
    try
      if (strcmp (__cantor_varname__, 'ahrsEuler'))
        keyboard;
      endif
      eval(['__cantor_string__ = disp(' __cantor_varname__ ');']);
      printf(__cantor_string__);
    catch
      keyboard;
      printf(['<unprintable value>' '\n']);
    end_try_catch;
  endif;
  printf('__cantor_delimiter_line__\n')
endfor;
clear __cantor_list__;
clear __cantor_index__;
clear __cantor_varname__;
clear __cantor_parse_values__;
clear __cantor_string__;

The behavior is worse on the development branch.  In that case, after I hit the keyboard statement, if I use dbnext then Octave segfaults.

(file #46626)

Rik <rik5>
Project Administrator
Fri 22 Mar 2019 10:07:11 PM UTC, comment #2:

Confirmed.  I didn't test for the segfault, but I can see that the column indent increases as the command is run.

I've marked the bug against the current stable release of Octave where I tested.

In reviewing the output, I can see that the indent increases after the catch block of the try/catch statement is executed.  My guess is that we are not correctly saving/restoring the indent level when an error occurs in the catch statement.

Rik <rik5>
Project Administrator
Fri 22 Mar 2019 09:35:01 PM UTC, comment #1:

Correct example of broken octave output:

octave:7> a = 3
                                                            a =  3
octave:8>

Parsing command:

printf('__cantor_delimiter_line__\n');
__cantor_list__ = who();
__cantor_parse_values__ = true;
for __cantor_index__ = 1:length(__cantor_list__)
  __cantor_varname__ = char(__cantor_list__{__cantor_index__});
  printf([__cantor_varname__ '\n']);
  if (__cantor_parse_values__)
    try
      eval(['__cantor_string__ = disp(' __cantor_varname__ ');']);
      printf(__cantor_string__);
    catch
      printf(['<unprintable value>' '\n']);
    end_try_catch;
  endif;
  printf('__cantor_delimiter_line__\n')
endfor;
clear __cantor_list__;
clear __cantor_index__;
clear __cantor_varname__;
clear __cantor_parse_values__;
clear __cantor_string__;

Parsing command oneline:

printf('__cantor_delimiter_line__\n');__cantor_list__ = who();__cantor_parse_values__ = true;for __cantor_index__ = 1:length(__cantor_list__)  __cantor_varname__ = char(__cantor_list__{__cantor_index__});  printf([__cantor_varname__ '\n']);  if (__cantor_parse_values__)    try      eval(['__cantor_string__ = disp(' __cantor_varname__ ');']);      printf(__cantor_string__);    catch      printf(['<unprintable value>' '\n']);    end_try_catch;  endif;  printf('__cantor_delimiter_line__\n')endfor;clear __cantor_list__;clear __cantor_index__;clear __cantor_varname__;clear __cantor_parse_values__;clear __cantor_string__;

Nikita <sirgienko>
Fri 22 Mar 2019 09:22:13 PM UTC, original submission:

Hi, I am one of developer of Cantor program - frontend for some mathematical languages. In Cantor, we supports backend for Octave language. We provides some functions, like syntax highlighting, auto completion, etc. Also, we provides variable menagement.

For parsing variables names and values we use this octave code:
````
printf('__cantor_delimiter_line__\n');
_cantor_list_ = who();
_cantor_parse_values_ = true;
for _cantor_index_ = 1:length(_cantor_list_)
  _cantor_varname_ = char(_cantor_list_{__cantor_index__});
  printf([__cantor_varname__ '\n']);
  if (_cantor_parse_values_)
    try
      eval(['__cantor_string__ = disp(' _cantor_varname_ ');']);
      printf(_cantor_string_);
    catch
      printf(['<unprintable value>' '\n']);
    end_try_catch;
  endif;
  printf('__cantor_delimiter_line__\n')
endfor;
clear _cantor_list_;
clear _cantor_index_;
clear _cantor_varname_;
clear _cantor_parse_values_;
clear _cantor_string_;
````

This code works without problem most part of time.

But after loading this matlab file I have strange issue with this Cantor parsing command: after each call of the command, Octave starts adding some spaces on the left of output of disp() and display() commands. And this added spaces stay forever. That worse, spaces accamulates.

Like this:
````
octave:7> a = 3
                                                            a =  3
octave:8>
````

Much worse, when spaces count getting bigger terminal width, Octave stops to response after executiong the cantor parsing command and starts allocate all your available memory. I don't actually allows Octave allocate enough memory to forcing system to using swap partrition, I am killing octave process before this. But observable maximum of allocated memory in this situation is 10 GB, so it's unnormal at all.

I have reproduced this problem not only  Cantor, but in octave-cli too.

Steps:
1) Load attached .mat file via load().
octave:1> load("~/sehrSchlecht.mat")
2) Run the cantor parsing command
octave:2> printf('__cantor_delimiter_line__\n');__cantor_list__ = who();__cantor_parse_values__ = true;for _cantor_index_ = 1:length(_cantor_list__cantor_varname_ = char(_cantor_list_{__cantor_index__});  printf([__cantor_varname__ '\n']);  if (_cantor_parse_values_)    try      eval(['__cantor_string__ = disp(' _cantor_varname_ ');']);      printf(_cantor_string_);    catch      printf(['<unprintable value>' '\n']);    end_try_catch;  endif;  printf('__cantor_delimiter_line__\n')endfor;clear _cantor_list_;clear _cantor_index_;clear _cantor_varname_;clear _cantor_parse_values_;clear _cantor_string_;
3) repeat step 2 again and again, until Octave stops to response and starts to allocate all your memory

I also have communicated with another Octave user with Octave5 and the user have reproduced this problem too.

Nikita <sirgienko>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #46626:  tst_print.m added by rik5 (774B - text/x-matlab)
file #46625:  sehrSchlecht.mat added by sirgienko (2MiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by sirgienko (Submitted the item)
  • -email is unavailable- added by sirgienko (My contact email adress)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-23 rik5 SummaryOctave, after load .mat file and using specific command, stop work and starts allocate all available memory => Octave interpreter indent for print increases whenever octave_base_value::print error emitted
    2019-03-22 rik5 Attached File- => Added tst_print.m, #46626
    2019-03-22 rik5 CategoryNone => Interpreter
        Item GroupSegfault, Bus Error, etc. => Other
        StatusNone => Confirmed
        Release4.2.2 => 5.1.0
    2019-03-22 sirgienko Attached File- => Added sehrSchlecht.mat, #46625
        Carbon-Copy- => Added warquark@gmail.com

    Back to the top


    Powered by Savane 3.4