bugGNU Octave - Bugs: bug #53521, GUI freezes and requires SIGKILL...

 
 

bug #53521: GUI freezes and requires SIGKILL upon large pasted input

Submitted by:  Adrian <adaerr>
Submitted on:  Fri 30 Mar 2018 10:09:01 AM UTC  
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev 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.

 

( Jump to the original submission)

Mon 30 Apr 2018 04:35:13 PM UTC, comment #7:

Yes, Bug #52276 seems really close to what I observed. So, let's keep the printout problems in Bug #52276 report and make this bug report about just the "Octave freeze when pasting large input".

Dan Sebald <sebald>
Mon 30 Apr 2018 02:30:30 PM UTC, comment #6:

Could bug #52276 be related?

Philip Nienhuis <philipnienhuis>
Project Member
Sun 29 Apr 2018 11:36:57 PM UTC, comment #5:

No "screen" here. I had to install "screen" to test your example, so I was using the shell and octave-cli.

That copy/paste bug doesn't give me a warm fuzzy. I use block copy via middle mouse button all the time.

However, it could be that what I'm seeing (with the latest development code...who knows, something could have been altered there in the last month) is only a printout issue on Octave's part and not actually corrupted input, because when I test the resulting N value against the expected value, they match:

So, it could be that what I'm seeing is related to the freeze bug in some way. I guess I would describe it as a simultaneous input/output terminal problem. It's as though some text of the input buffer is making its way into the output buffer prematurely, e.g.:

that hunk of text that appears always seems to be a number or portion of a number that is ahead of the processed script line.

I think what I'm seeing isn't quite the same as what you are describing with dropped blocks of data when pasting using "screen".

Dan Sebald <sebald>
Sun 29 Apr 2018 05:39:46 AM UTC, comment #4:

To follow up on a CLI bug noticed by Dan Sebald (comment #1 and comment #2) independently of the GUI bug that this bugtracker entry is about: after some more testing it appears that the glitches upon pasting into a terminal running "octave --no-gui" are not octave-specific. They also occur when pasting into an editor or simply cat - which made me realise I had been bitten by that bug several times already. They are however (as far as I tested) specific to the use of screen, rather than terminal, shell or application. I updated the corresponding bug report

https://savannah.gnu.org/bugs/index.php?35862

@Dan Sebald: Did you also work within a screen session when you observed the glitches ?

It seems this has no obvious connection with the GUI bug I reported originally.

Adrian <adaerr>
Fri 30 Mar 2018 09:08:31 PM UTC, comment #3:

Interesting find. Nice work.

Dan Sebald <sebald>
Fri 30 Mar 2018 08:57:43 PM UTC, comment #2:

Thanks Dan for the additional observations. I was indeed talking about pasting into the Command Window, sorry for forgetting that detail.

I can also confirm that pasting large buffers into a terminal running "octave --no-gui" does not cause octave to hang.
It works nicely in an xterm, but I also observe the occasional glitches described by Dan when using an rxvt with a screen session. Here, these glitches are not merely problems echoing the pasted input. For example I see glitches such as

To test if all instructions are executed I slightly changed the test script to that generated by

It shows that some instructions are skipped or mangled. Indeed an example where all lines from the start to "N+=4000;" were pasted results in 3987 'digested' lines (from the command counter in the prompt) and a wrong final value for N:

As far as I tested, this non-gui problem seems terminal-related (glitches do not seem to occur when pasting into an xterm). I do not know if any of this helps with the GUI freeze that this bug report is about, though.

My computer is running an up-to-date Debian/testing GNU/Linux distribution.

Adrian <adaerr>
Fri 30 Mar 2018 05:30:17 PM UTC, comment #1:

Confirmed on linux, Mint, Cinnamon. We are talking pasting into the Command Window. Additional information is that if the file name extension is .m rather than .txt it can be run as a script and there are no problems--runs fast, N is the final value in the list. When Octave is run in command-line mode, cut-and-past of the large text buffer works. However, there is something peculiar in the fact "glitches" in the character stream appear. For example, every once in a while there is:

or

or

and so on. I don't understand what is happening there, but perhaps that same kind of thing is happening when pasted to the terminal emulator (Command Line) in the GUI but such activity in the GUI causes a hang.

The only other small detail I notice is that when running the GUI and pasting, the climb in CPU usage doesn't appear to happen immediately. There is a slight lag of about five to ten seconds (taking into consideration the filtering operation of my system monitor).

Dan Sebald <sebald>
Fri 30 Mar 2018 10:09:01 AM UTC, original submission:

If I past large input (10k-20k characters) into the octave GUI, CPU usage goes up for a few seconds and then drops to zero. No output is shown and the GUI becomes completely unresponsive, including to Ctrl-C. It does not redraw its window content either.

To reproduce:
1) Generate a large input, e.g.
for n in {1..10000} ; do
echo "N=${n};" >>octavepastetest.txt
done
2) Open that file in an editor, select 3500 lines or more and paste into octave-gui

The exact quantity of input that makes the GUI freeze does not seem to be reproducible. I observed freezes for as little as 340 pasted lines / 12000chars (though of a more complex script than the above example). With the above test some 3500 lines / 27000 chars freeze the GUI reliably on my box, while <2500 lines are processed without problem.

Once the GUI is frozen, sending the octave-gui process the TERM signal may result in either of the following:
- no effect
- termination of both the octave and the octave-gui processes ("octave exited with signal 6") if Ctrl-C had not been pressed; this seems to be the same behaviour (and signal) as when a normally responsive GUI is terminated via SIGTERM.
- GUI prints part of the pasted input, and becomes functional again (if Ctrl-C had been pressed before sending the TERM signal).

Adrian <adaerr>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by adaerr (Submitted the item)
  •  

    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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-04-27 mtmiller Carbon-CopyRemoved 80942 => -
    2018-04-27 mtmiller Release4.3.90 => dev
    2018-04-10 mtmiller StatusNone => Confirmed
        Release4.2.2 => 4.3.90
    2018-04-10 mtmiller Item GroupSegfault, Bus Error, etc. => Unexpected Error

    Back to the top


    Powered by Savane 3.3