bugGNU Octave - Bugs: bug #55196, Locked screen halts program...

 
 

bug #55196: Locked screen halts program execution if your program throws up plots:

Submitter:  deego <deego>
Submitted:  Mon 10 Dec 2018 09:17:13 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  3 - Low Item Group:  Other
Status:  Works For Me Assigned to:  None
Originator Name:  deego Open/Closed:  * Closed
Release:  * 4.2.2 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 10 Mar 2019 07:07:02 PM UTC, comment #14: 

No response, asumming this has been fixed in the latest release.  Closing report.

Rik <rik5>
Group administrator
Sat 02 Mar 2019 07:28:00 PM UTC, comment #13: 

Version 4.2.2 is deprecated and no longer supported.  Please try with the latest stable release which is 5.1.0.

Rik <rik5>
Group administrator
Thu 24 Jan 2019 08:34:19 PM UTC, comment #12: 

Mike,

Yes, I will follow up on these things.

(Yes, I will try this with 4.4. I've tried multiple times to move to 4.4 in the past year, but among other things, casadi is not ready for it, and breaks with it at the moment.)

Thanks
Dave

deego <deego>
Thu 24 Jan 2019 07:48:53 PM UTC, comment #11: 

I cannot reproduce it with current 5.0.1 tip ("361f7ce80f85")
on

Fedora 29
Intel(R) Xeon(R) CPU           W3530  @ 2.80GHz
VGA compatible controller: NVIDIA Corporation GF106GL [Quadro 2000] (rev a1)



glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: nouveau (0x10de)
    Device: NVC3 (0xdd8)
    Version: 18.2.8
    Accelerated: yes
    Video memory: 968MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.3
    Max compat profile version: 3.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: nouveau
OpenGL renderer string: NVC3
OpenGL core profile version string: 4.3 (Core Profile) Mesa 18.2.8
OpenGL core profile shading language version string: 4.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.1 Mesa 18.2.8
OpenGL shading language version string: 1.40
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.2.8
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 24 Jan 2019 07:33:39 PM UTC, comment #10: 

So the explanation at this point is this seems to be some interaction between Octave's OpenGL calls and the nouveau driver somehow blocking these calls when the screen lock is active?

If you have ssh access to this machine, I would try logging in remotely while this happens, attach to Octave with gdb and try to see where it is blocked, if it is in fact an OpenGL library call that is blocked and not returning.

If that's the case, then this might be reproducible with any OpenGL program, and can maybe be brought to the attention of the nouveau developers.

I don't have any nvidia hardware, but maybe someone else does and can try to reproduce this with the nouveau driver. And it would still be useful to know if you can upgrade to 4.4.1 and still reproduce this.

Mike Miller <mtmiller>
Group Member
Fri 21 Dec 2018 08:11:25 PM UTC, comment #9: 

Mike, re op. system suspesion: I def. made sure that's not the case:

(1) I have completely disabled hibernation/suspending anyway.

(2) Other scripts continue working just fine and making appropriate noises.

(3) Even Octave scripts that have never thrown up a plot continue making beeps.

(4) It is only those scripts that threw up a figure at some point during their lives that see this problem (note that the problem happens even when there's no figure() or plot() inside the while loop itself).



deego <deego>
Fri 21 Dec 2018 06:50:17 PM UTC, comment #8: 

Is it possible the operating system is being suspended when you activate the screen lock?

Mike Miller <mtmiller>
Group Member
Wed 19 Dec 2018 06:21:15 AM UTC, comment #7: 

More information:


With the same debian/xfce/octave, this bug seems - strangely - to be specific to the nouveau driver.

If I use the proprietary nvidia driver instead, the "extra gap" bug disappears, with the very same debian/xfce/octave(4.2.2).

deego <deego>
Tue 11 Dec 2018 03:06:54 AM UTC, comment #6: 

You are right. I am running octave --no-gui where I see that octave is symlinked to octave-4.2.2.

(In htop, its subthreads(?) show up as octave-gui --no-gui).
 


deego <deego>
Tue 11 Dec 2018 02:21:24 AM UTC, comment #5: 

Debian stable-backports repository has Octave 4.4.1. Please do try it if you can. But I don't think anything is necessarily "fixed" by upgrading from 4.2.2 to 4.4.1. I get the same behavior with both 4.2.2 and 4.4.1 on my system, the program is not halted.

In regards to your latest comment on bug #55185, are you actually running 'octave-gui --no-gui' directly? Are you sure you're not using 'octave --no-gui', which does important things like detaching from the controlling terminal before exec'ing the 'octave-gui' program? The 'octave-gui' program is hidden under an "internal use only" path intentionally, because you're really not supposed to run it directly. If you are calling it directly, can you try using the 'octave' stub executable instead?

And to repeat your details from bug #55185, this is with the Xfce desktop environment, running Octave with '--no-gui' in xfce4-terminal.

Mike Miller <mtmiller>
Group Member
Tue 11 Dec 2018 01:48:11 AM UTC, comment #4: 

Dmitri and Mike,

Thanks. Glad to learn it might be fixed in 4.4.1. I will try to upgrade.



deego <deego>
Mon 10 Dec 2018 11:39:46 PM UTC, comment #3: 

I am not able to reproduce with Octave 4.2.2 in a GNOME environment. Possibly some interaction specific to the Xfce window manager and screen lock?

If I lock the screen when the elapsed timer shows 10 seconds, and wait 30 seconds before unlocking, the terminal shows that each 2 second interval between 10 and 40 has been printed in the meantime and continues to print at 2 second intervals, no gaps.

Mike Miller <mtmiller>
Group Member
Mon 10 Dec 2018 11:28:55 PM UTC, comment #2: 

Can you upgrade to octave 4.4.1?

I cannot reproduce your problem with 4.2.2, but it definitely has some problem. In my case the text is suppressed until I click
on figure windows. I do not get any gaps though...

4.4.1 and current dev tip behave as expected...

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Mon 10 Dec 2018 10:19:49 PM UTC, comment #1: 

It happens even if there is no attempt to throw up a plot. As long as there is a figure present, locking the screen stops the entire program (even if you attempt no further plotting).

Run this program. Lock the screen. Wait 10 secs, then unlock the screen. Now, don't forget to wait for the next toc! You see a 10 seconnd extra gap!

function yyybug012;
  figure(1);
  tic();
  while true;
    pause(2);
    toc;
  endwhile
endfunction


Octave__17:16:01_0030005_1> yyybug012
Elapsed time is 2.00092 seconds.
Elapsed time is 4.00138 seconds.
Elapsed time is 6.0018 seconds.
Elapsed time is 8.00217 seconds.
Elapsed time is 10.0026 seconds.
Elapsed time is 12.003 seconds.
Elapsed time is 14.0035 seconds.
Elapsed time is 27.1781 seconds.  <==== Extra gap.




deego <deego>
Mon 10 Dec 2018 09:17:13 PM UTC, original submission:  

(I worked around the #55185 kbhit(1) bug reported earlier by not calling it in the first place when locked. It seems that the same happens simply by plotting:)

Next, it seems that the same problem happens with plot itself. plot also hangs indefinitely if it is called when locked. [Debian stable, 4.2.2, qt toolkit, xfce4]

Again, imagine a giant program that plots periodically, and that the screen gets locked for security when idle. Unfortunately, that also pauses the program itself!


function yyybug010();
  tic();
  while true;
    pause(2);
    plot(rand(1,2), rand(1,2));  system("beep");     hold off;
    disp(toc);
  endwhile
endfunction

## Octave__16:09:26_0025359_5> yyybug010
##  2.27368807792664
##  4.54688906669617
##  6.82589006423950
##  9.10250306129456
##  22.4111368656158  (screen was locked here. You stopped hearing beeps, your program halted)
##  24.6930980682373
##  26.9730200767517
##  29.2445690631866
##  31.5159778594971

deego <deego>

 

(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 rik5 (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by deego (Submitted the item)
  • -email is unavailable- added by deego
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-10 rik5 Open/ClosedOpen Closed
    2019-01-24 mtmiller Priority5 - Normal 3 - Low
        Item GroupNone Other
    2018-12-10 mtmiller StatusNone Works For Me
    2018-12-10 deego Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code