bugGNU Octave - Bugs: bug #51103, GUI command-line output window...

 
 

bug #51103: GUI command-line output window freezes after plot, but input still works

Submitter:  Dan Sebald <sebald>
Submitted:  Wed 24 May 2017 02:43:48 AM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Works For Me Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 26 May 2017 04:57:33 AM UTC, comment #16: 

I don't see such a thing.  The file that I tried appears to come from Mint/Ubuntu libgl1-mesa-glx-lts-vivid package which is titled

free implementation of the OpenGL API -- GLX runtime

In fact, there are a half dozen packages with similar names (e.g., sans "-lts-vivid".  I don't think I want to experiment with installing new packages, though, because the "uninstall" list looks rather long and has a lot of important graphics libraries including

nvidia-340
xorg
xorg-server

I don't want to get that experimental because I'm busy with some other projects.  Maybe in a month or so I'll look at this again--after a Mint upgrade, in which case maybe it fixes itself with newer versions of everything.

Dan Sebald <sebald>
Fri 26 May 2017 04:30:42 AM UTC, comment #15: 

libGL.so is wrong.
Do you have just libGLX.so?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 26 May 2017 03:51:51 AM UTC, comment #14: 

I couldn't find any library file on my system with "mesa" name, so picked this

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0

and that produces


libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
>> graphics_toolkit ('fltk')
>> plot ([1:50])
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast


at which point all of the GUI is frozen.  swrast is one of the OpenGL drivers if I recall correctly (on its way out).

I configured osmesa out of the build.  (Of course, that doesn't mean it isn't built into the program, just that it is apparently not used for drawing.)

Dan Sebald <sebald>
Fri 26 May 2017 02:59:41 AM UTC, comment #13: 

Have you tried

LD_PRELOAD=/usr/lib64/lib64/libGLX_mesa.so ./run-octave

(or whatefver the name of your GL library)
?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 25 May 2017 10:49:17 PM UTC, comment #12: 

There doesn't seem to be much beyond cosmetic changes to FLTK in the past six months,

http://hg.savannah.gnu.org/hgweb/octave/log/8edbc923a7dc/libinterp/dldfcn/__init_fltk__.cc

except starting here:

http://hg.savannah.gnu.org/hgweb/octave/rev/0842b119dc1b

Out of curiosity I undid the above patch, and it had no effect.  Not worth investigating further unless someone else encounters the problem.

Dan Sebald <sebald>
Thu 25 May 2017 10:30:19 PM UTC, comment #11: 

OK, I think I can summarize this better now, given that I have commented

%  graphics_toolkit('gnuplot');

out of my .octaverc file.

So, with that, launching and plot uses 'qt' graphics toolkit.  If the plot is successful, the command-line window output does not freeze.  If the Qt plot is unsuccessful (i.e., a grey window with a white rectange in the upper-left corner) the command-line window output does freeze.

The switch to graphics_toolkit('fltk') consistently freezes the output window event though the plot looks fine.  I can still run commands, and in fact I can still run plot commands and get an updated plot, even though characters no longer appear in the command window.

So, the bug here seems to be that FLTK is not return the output resource to the Command Window, similar to what is probably happening when Qt plot freezes.

Dan Sebald <sebald>
Thu 25 May 2017 10:25:48 PM UTC, comment #10: 

Closing, as this seems to be a specific HW/SW interaction on Dan's computer.

Rik <rik5>
Group administrator
Thu 25 May 2017 10:06:04 PM UTC, comment #9: 

You caught that ahead of me, Dmitri.  It is 'qt' that is the default.  I didn't think of what the -f option means.  So 'qt' works, but sometimes the Qt plot hangs--that's the plot itself that is freezing, not the command line.  The 'Qt' plot randomly freezing for me is a known bug.

Dan Sebald <sebald>
Thu 25 May 2017 09:53:45 PM UTC, comment #8: 

I tried to build with those options and I do not see this problem.
It is strange that when you do ./run-octave -f the default graphics toolkit is gnuplot. It should be qt.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 25 May 2017 09:52:07 PM UTC, comment #7: 

I rebuilt without any options and got the same behavior as described previously.

I assumed 'qt' g.t. would be the same as 'fltk', but interestingly it isn't quite the same.


run-octave
>> graphics_toolkit ('qt')
>> plot ([1:50])
>>


hangs but notice the extra >>, which doesn't appear with the 'fltk' toolkit when it hangs.  But more surprising is that the -f option does in fact work:


run-octave -f
>> graphics_toolkit ('qt')
>> plot ([1:50])
>> exit


If I go into my .octaverc file and comment out all commands unrelated to path and packages, g.t. 'qt' will work.  But 'qt' figure once in a while ends up shredded.

Oh!  So that wasn't 'gnuplot' toolkit failing.  The -f option doesn't load .octaverc, so it is actually 'qt' failing in that instance.

Well, I'd say close this report.  I think this is just the usual problems I've had for quite a while with OpenGL and nVidia hardware.

Dan Sebald <sebald>
Thu 25 May 2017 09:00:29 PM UTC, comment #6: 

I've never tried '--no-recursion'.  Given that this is something to do with graphics the '--without-osmesa' seems more likely.

Does the default qt toolkit have the same problem or is it only fltk?

Rik <rik5>
Group administrator
Thu 25 May 2017 06:13:36 PM UTC, comment #5: 

I wasn't quite accurate on that, as I did use some configure options and build outside the source tree.  So it was


<cd build tree>
make maintainer-clean
<cd source tree>
./bootstrap
<cd build tree>
<source tree>/configure --without-osmesa --no-recursion
make


Maybe the --no-recursion option is the issue.  I've been using that option for quite a while now.

Dan Sebald <sebald>
Thu 25 May 2017 06:06:47 PM UTC, comment #4: 

I tried


make maintainer-clean
./bootstrap
./configure
make


but there is no change.


<path>/run-octave
graphics_toolkit ('fltk')
plot ([1:50])


hangs the output window (though input is still accepted).  The default graphics toolkit (gnuplot) doesn't lead to output window hang.

In addition


<path>/run-octave -f
plot ([1:50])


freezes the output window (with default graphics toolkit gnuplot) and sometimes messes up the gnuplot plot as well.  But with an explicit graphics_toolkit call, i.e.,


<path>/run-octave -f
graphics_toolkit ('gnuplot')
plot ([1:50])


the output window does not hang.

Dan Sebald <sebald>
Wed 24 May 2017 10:33:25 PM UTC, comment #3: 

The -f option makes things worse.  gnuplot toolkit freezes as well doing a simple plot.  I'll do a maintainer clean and rebuild this evening.

Dan Sebald <sebald>
Wed 24 May 2017 08:58:10 PM UTC, comment #2: 

As I reported on bug #48667, this works for me.  This might be something with your particular set up.  Maybe try running with the '-f' option so you don't load any packages or user settings which might be the issue.

Rik <rik5>
Group administrator
Wed 24 May 2017 02:45:18 AM UTC, comment #1: 

I meant for one of those to be:


graphics_toolkit ('fltk')
image(20*rand(4))


Dan Sebald <sebald>
Wed 24 May 2017 02:43:48 AM UTC, original submission:  

Any type of plotting freezes the command line output in the GUI, even though keystrokes are accepted and processed after the window freezes:


graphics_toolkit ('fltk')
plot(20*rand(4))


Now type


exit


Relaunch GUI (I'm using "run-octave" after a build):


graphics_toolkit ('fltk')
plot(20*rand(4))


Same thing.  Originally I thought this was a color map issue, but I no longer think that:

https://savannah.gnu.org/bugs/?48667#comment16

Dan Sebald <sebald>

 

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

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

    Date Changed by Updated Field Previous Value => Replaced by
    2017-05-25 rik5 Open/ClosedOpen Closed
    2017-05-24 rik5 StatusNone Works For Me

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code