bugGNU Octave - Bugs: bug #44823, Segfault when using HD Graphics...

 
 

bug #44823: Segfault when using HD Graphics 6000 on Fedora 21

Submitted by:  Michael Godfrey <godfrey>
Submitted on:  Mon 13 Apr 2015 02:37:16 AM UTC  
 
Category:  Plotting with OpenGL Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  None Assigned to:  None
Originator Name:  Godfrey Open/Closed:  Closed
Release:  4.0.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.

 

( Jump to the original submission)

Sat 23 Jul 2016 09:53:55 PM UTC, comment #30: 

While this report was about Intel HD6000 graphics,
which is not that popular, it is worth reporting
the print with "visible" "on" now works both locally
and remotely through ssh. Connected with this the
X11/gls demos work and remote plots display as they
should.

So, this can be closed and HD6000 graphics can be
listed as fully working with latest Octave and latest
system updates.

Michael Godfrey <godfrey>
Project Member
Sat 02 Jul 2016 11:45:01 AM UTC, comment #29: 

I'll mark it as "won't fix" on the Wiki page.

I agree that it would be good to keep this as "status: none".

Lachlan Andrew <lachlan>
Sat 02 Jul 2016 10:57:53 AM UTC, comment #28: 

Rik: Won't fix is a bit overdoing it. Given that there is
a need to implement code which detects graphics capabilities
and selects choices that are known to work and returns a
reject if no known capability exists, this problem with
respect to the HD 6000 hardware should be included.

So, whatever classification which means not for 4.2 but NOT
forgotten would be good.

Michael Godfrey <godfrey>
Project Member
Sat 02 Jul 2016 03:23:01 AM UTC, comment #27: 

@Michael: The current release strategy is to bump all "Crash" reports up to Important.  And then make sure they get a proper review and either fixed or demoted.

If this only affects a small set of hardware, and the workaround for Octave is cumbersome and not written, then I agree that there's not much
point.

Can I mark this as "Won't Fix"?

Rik <rik5>
Project Administrator
Fri 01 Jul 2016 10:31:39 PM UTC, comment #26: 

Rik: I am not sure that this needs upgrade to important.
It appears that this seg fault is unique to systems
with Intel HD 6000 graphics, and it appears that this
Intel version was not too popular and is being replaced
by a newer system. The most that should/can be done is
to test for the graphics system and then only print with
visibility "off".

Michael Godfrey <godfrey>
Project Member
Wed 29 Jun 2016 05:01:21 PM UTC, comment #25: 

Mike: Very useful. But, does print (with visible on) work
for all of the cases that you listed?

In any case, this does mean that a test for what video
hardware/software is available is necessary.

Maybe for 4.2 just test for Intel HD 6000? If this is
actually the only case that fails with visible on, it may
make sense to just ignore it, with some comment that
the required workaround is for the user to implement
the visible on/off as I do.

Michael

Michael Godfrey <godfrey>
Project Member
Wed 29 Jun 2016 04:01:14 PM UTC, comment #24: 

Setting visibility to off does not work in general for many users, so I don't think it is an appropriate solution to apply to everyone.

1. OSMesa is an optional dependency, so if you build with --without-OSMesa, you can't print with visible off.

2. All users with the proprietary Nvidia video stack experience segfaults when trying to mix OSMesa with Nvidia's OpenGL, so they can't print with visible off.

3. Windows users currently see a fatal error with OSMesa, so they can't print with visible off.

Mike Miller <mtmiller>
Project Administrator
Wed 29 Jun 2016 03:31:12 PM UTC, comment #23: 

Lachlan: In principle I would be willing to do this, but:
1. There is some uncertainty whether an unconditional
   visibility off/on is appropriate.
2. Starting on 1 July we are selling our previous home,
   moving to a new apartment and having to deal with a
   lot of issues connected with this.  The target is to
   have this substantially done by the end of July, but...

Since this also means that there may be (despite much
planning) some periods of no or very limited internet
connection, I really should not commit to doing this well
before 4.2 release.

If it is true that the visibility switch makes sense
unconditionally the coding should really be quite simple:
1. Test for visibility "off", if so just go ahead.
2. If not, turn it "off" do the print, turn it back on.

I bet that I could do that, but if something goes wrong and
I am boarding a flight...

Of course, I will be happy to help any way I can.
OK?
Michael

Michael Godfrey <godfrey>
Project Member
Wed 29 Jun 2016 01:23:17 PM UTC, comment #22: 

Thanks for looking into that, Michael.

Do you want to take ownership of the task of writing a patch to turn visibility off for printing?

Lachlan Andrew <lachlan>
Wed 29 Jun 2016 11:25:59 AM UTC, comment #21: 

I have taken a quick look at the state of X11, Wayland,
and some problem reports especially for Fedora 24.
The shortrun picture is pretty bleak. Quite a few
Matlab users are complaining about X11-related problems,
and this will get worse as users upgrade to Fedora 24.
In the meantime there is considerable work going on to
complete Wayland to the point that it can replace X11.
Elements of Wayland automatically install when Fc24 is
installed.

So, I am sure that it is unrealistic to do much for the
4.2 release. The only change that makes sense is the
set("visibility","off") for printing. It may be that this
is a good idea in any case. Executing the print code with
visibility off surely uses less resources. Is there any
negative effect?

Michael Godfrey <godfrey>
Project Member
Tue 28 Jun 2016 10:00:43 PM UTC, comment #20: 

For what it is worth, there is a bug in Fedora 24 which
causes Matlab's program need_softwareopengl to hang
instead of returning the answers:
Returns: 1 if MATLAB previously crashed due to a graphics issue..
         2 if graphics settings are software OpenGL.
         3 if graphics settings are hardware OpenGL, but graphics tests fail.
         4 if graphics tests fail.
         0 otherwise.
====================================
I would expect that this will be fixed sometime soon and that
the fix may affect the Octave hang.

Michael Godfrey <godfrey>
Project Member
Tue 28 Jun 2016 06:50:11 PM UTC, comment #19: 

John, This is a long and complex set of issues. OpenGL, X11, and
other software are involved. And, I just discovered that Fedora 24
behaves differently from 23. An obvious difference is that ssh'ing
from Fedora 24 to 23 no longer runs matlab. matlab -nodesktop
just hangs. Under 23 to 23 to ran OK.

Running from Mac OS to Fedora 23 works, with the following
complaints:

[godfrey@qss ~]$ matlab -nodesktop
MATLAB is selecting SOFTWARE OPENGL rendering.

                                                 < M A T L A B (R) >
                                       Copyright 1984-2016 The MathWorks, Inc.
                                        R2016a (9.0.0.341360) 64-bit (glnxa64)
                                                  February 11, 2016


To get started, type one of these: helpwin, helpdesk, or demo.
For product information, visit www.mathworks.com.


        Academic License

>> plot(1:100)
Warning: MATLAB has disabled some advanced graphics rendering features by switching to software OpenGL. For more
information, click <a href="matlab:opengl('problems')">here</a>.
>>

So, the problem of useful use of Octave through ssh/X11 remote
access seems to be both challenging and a moving target.

I will try to learn more, but am very pressed for time right now.

Michael

Michael Godfrey <godfrey>
Project Member
Tue 28 Jun 2016 05:19:59 PM UTC, comment #18: 

It would be fine with me to detect systems that are bad and fall back to some safe but possibly inefficient way of doing things.  Or even to just have an option to choose the safe way.  But for some of these graphics problems it's not clear to me what the safe way is.

John W. Eaton <jwe>
Project Administrator
Tue 28 Jun 2016 02:25:55 PM UTC, comment #17: 

And, in answer to Lachlan's comment #14 I now realize
that I should not have mixed 2 problems in one bug report.
The hangs when using remote access are a separate error.
I will do some more testing and report that as a new
bug report.

Please treat this bug report as only what the title says.

Michael Godfrey <godfrey>
Project Member
Tue 28 Jun 2016 01:55:05 PM UTC, comment #16: 

Oh, I should have added that not all Linux systems install
lspci by default. So, it would also be useful to test
for the presence of lspci, or there may be another command
that provides the required information.

Michael Godfrey <godfrey>
Project Member
Tue 28 Jun 2016 01:51:25 PM UTC, comment #15: 

It would make sense to have a "black list" of
hardware devices and controllers which cause failures
with fallbacks or workarounds to prevent incorrect behavior.

A way, in Linux, to detect the "bad" VGA controller in
my case is:
 lspci  |grep "HD Graphics 6000"

if this yields:
VGA compatible controller: Intel Corporation HD Graphics 6000

the current Octave will seg fault on print command unless
set("visible", "off") is used.

Michael Godfrey <godfrey>
Project Member
Tue 28 Jun 2016 12:27:59 PM UTC, comment #14: 

It would be good if this could be fixed or worked around for 4.2.0.

Would it be possible simply to detect vulnerable systems, and set ("visible", "off") before printing?  That would only address issue 2 of comment #13, which is the less critical one.

Lachlan Andrew <lachlan>
Wed 11 May 2016 09:34:11 PM UTC, comment #13: 

John:

Yes, the problem of requiring visible off
for print has stayed the same for the life of
this bug report even though now the Fedora
level  is 23 with latest updates. To summarize:
HD 6000 system local print seg faults with visible
on, works correctly with visible off
HD 5000 system with same Fedora 23 print works
with visible on or off.

Remote login (ssh) from Mac running 10.11.4 to Fedora
(with latest Xcode) works correctly.

Remote login (either way) between Fedora systems
hangs on plot(1:100). It draws the window with Figure
title but then hangs. I attached a debug trace of this.

You asked:
  I'm wondering if this is a driver issue, something about OpenGL libraries, or something we are doing wrong when calling OpenGL functions.

It appears that there are differences between OpenGL libraires in
the way they behave on different systems. But, there is other
code which uses OpenGL for graphics which works in the cases where
Octave fails. Matlab is an example. So, part of the problem
must be what we are doing.

Now there are 2 fairly well-defined cases:
1. The hang when plotting is attempted between Fedora systems.

2. The seg fault when attempting print zzz.pdf on Fedora and HD6000.

I would say that the first is more important since it appears to
affect most Fedora systems.

And, I cannot say whether the second failure is "our fault" or
a problem with the drivers for HD 6000. They (the Opengl folks
accepted the bug report that I submitted and seemed to indicate that
they agreed that it was a valid bug. But no sign of a fix, and they
coul;d have changed their minds. I do not think that HD 6000 was
all that popular and it appears to no longer be the "current" Intel
graphics hardware...

Michael
p.s. If you do decide to work on this it should certainly go in
   "things that are a pain" category.

Michael Godfrey <godfrey>
Project Member
Wed 11 May 2016 08:43:33 PM UTC, comment #12: 

Michael:

Are you still seeing this problem with the current development version of Octave?

I'm wondering if this is a driver issue, something about OpenGL libraries, or something we are doing wrong when calling OpenGL functions.

John W. Eaton <jwe>
Project Administrator
Sun 21 Feb 2016 11:50:12 PM UTC, comment #11: 

This still fails on current dev system 4.1.0+. And,
below I said it works on Intel HD 6000. But,
I meant to say works on HG 5000. Still always fails
on Intel HD 6000.

Michael Godfrey <godfrey>
Project Member
Tue 02 Jun 2015 04:47:24 PM UTC, comment #10: 

Retagging release from 4.0.0-rc3 to 4.0.0.

John W. Eaton <jwe>
Project Administrator
Tue 05 May 2015 01:29:37 PM UTC, comment #9: 

I learned more about this seg fault:

It only happens if the figure is visible.

figure ("visible", "off");
plot(1:100)
... and other plot commands ...
print zzz.pdf

all works correctly on the Intel HD 6000
system.

I also obtained a bt of the seg fault with visible on.
It is far down in the Intel mesa code.

However, this means that the seg fualtis caused by code
that is only executed if the figure is visible.

Michael Godfrey <godfrey>
Project Member
Mon 13 Apr 2015 12:31:30 PM UTC, comment #8: 

Pantxo: Good.This seems the right choice.

Michael Godfrey <godfrey>
Project Member
Mon 13 Apr 2015 07:21:41 AM UTC, comment #7: 

I retitled the report to better describe the real issue, but didn't close it to keep it as a reference: Fedora users will probably face this issue.
I left the severity "Normal" as there doesn't seam to be anything we can do on Octave side.

Pantxo Diribarne <pantxo>
Project Member
Mon 13 Apr 2015 04:46:42 AM UTC, comment #6: 

I had switched Intel NUC boxes to one that uses
HD Graphics 6000. When I revert to a system using
HD Graphics 5000 everything works.

So, close this report, but keep in mind that Fedora
21 does not appear to handle the HD Graphics 6000
correctly.  All the standard screen stuff seems to
work fine.

Michael Godfrey <godfrey>
Project Member
Mon 13 Apr 2015 03:25:56 AM UTC, comment #5: 

Now, this problem is different from what I assumed.
RC2 also crashes on my current system, as does
version 3.8.2.

So, a recent Fedora update of something local to my machine
is causing this problem.

Michael Godfrey <godfrey>
Project Member
Mon 13 Apr 2015 03:03:26 AM UTC, comment #4: 

The seg faults below were when running: octave --no-gui

Running using the gui produces Octabe just disappears
after the print zzzz.pdf.

In any case an empty PDF file is written.

Michael Godfrey <godfrey>
Project Member
Mon 13 Apr 2015 02:50:53 AM UTC, comment #3: 

Using gnuplot and a more complex plot produces:

*** Error in `/usr/local/libexec/octave/4.0.0-rc3/exec/x86_64-unknown-linux-gnu/octave-gui': corrupted double-linked list: 0x00000000040c7e80 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x77d9e)[0x7f4cdc51cd9e]
/lib64/libc.so.6(+0x814cf)[0x7f4cdc5264cf]
/lib64/libc.so.6(__libc_malloc+0x6e)[0x7f4cdc52815e]
/lib64/libstdc++.so.6(_Znwm+0x18)[0x7f4cdd213608]
/usr/local/lib/octave/4.0.0-rc3/liboctinterp.so.2(+0xc12be6)[0x7f4ce67c6be6]
/usr/local/lib/octave/4.0.0-rc3/liboctinterp.so.2(_Z16dump_octave_corev+0x1c5)[0x7f4ce67c9905]
/usr/local/lib/octave/4.0.0-rc3/liboctinterp.so.2(+0xd52b8c)[0x7f4ce6906b8c]
/lib64/libpthread.so.0(+0x100d0)[0x7f4cdc8720d0]
/usr/lib64/dri/i965_dri.so(+0x201f5f)[0x7f4cb4f90f5f]
/usr/lib64/dri/i965_dri.so(+0x36daad)[0x7f4cb50fcaad]
/usr/lib64/dri/i965_dri.so(+0x2fa619)[0x7f4cb5089619]
/usr/lib64/dri/i965_dri.so(+0x2f90e5)[0x7f4cb50880e5]
/usr/lib64/dri/i965_dri.so(+0x1bf8ce)[0x7f4cb4f4e8ce]
/usr/lib64/dri/i965_dri.so(+0x1bff6b)[0x7f4cb4f4ef6b]
/usr/lib64/dri/i965_dri.so(+0x1b60f2)[0x7f4cb4f450f2]
/usr/lib64/dri/i965_dri.so(+0x1f8457)[0x7f4cb4f87457]
/usr/lib64/dri/i965_dri.so(+0x193ca6)[0x7f4cb4f22ca6]
/usr/lib64/dri/i965_dri.so(+0x18e80e)[0x7f4cb4f1d80e]
/usr/lib64/dri/i965_dri.so(+0x18f221)[0x7f4cb4f1e221]
/usr/lib64/dri/i965_dri.so(+0x32010c)[0x7f4cb50af10c]
/usr/lib64/dri/i965_dri.so(+0x175878)[0x7f4cb4f04878]
/usr/lib64/dri/i965_dri.so(+0x15cb3c)[0x7f4cb4eebb3c]

Michael Godfrey <godfrey>
Project Member
Mon 13 Apr 2015 02:47:10 AM UTC, comment #2: 

qt and fltk seg fault,
gnuplot does not. The resulting plot looks normal
for gnuplot.

Michael Godfrey <godfrey>
Project Member
Mon 13 Apr 2015 02:40:55 AM UTC, comment #1: 

Actually, all that is needed in Fedora 21 is:

plot(1:200)
print zzz.pdf

This is followed by the seg fault as below.

Michael Godfrey <godfrey>
Project Member
Mon 13 Apr 2015 02:37:16 AM UTC, original submission:  

This worked without problem until RC3:

>> plot_demods
title2 = Date: 12-Apr-2015.  airdata_1946-60_extr_1961: a =  1.57, -0.70,  b = 0.00, 0.07, 0.06, nl = 11, nconv = 1.
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Error: /syntaxerror in -file-
Operand stack:
   STnoshfill
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1951   1   3   %oparray_pop   1950   1   3   %oparray_pop   --nostringval--   1934   1   3   %oparray_pop   1820   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push
Dictionary stack:
   --dict:1187/1684(ro)(G)--   --dict:0/20(G)--   --dict:82/200(L)--   --dict:37/64(L)--
Current allocation mode is local
Last OS error: Not a directory
GPL Ghostscript 9.15: Unrecoverable error, exit code 1
Segmentation fault (core dumped)

I will try to learn more about this, but at this late stage
in the release cylce it may be a good choice to revert to rc2
or at least back out the plotting related changes.

Michael Godfrey <godfrey>
Project Member

 

(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

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by lachlan (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by godfrey (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 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-07-24 jwe Open/ClosedOpen => Closed
    2016-07-02 rik5 Carbon-CopyRemoved 72865 => -
    2016-07-02 rik5 Severity4 - Important => 2 - Minor
    2016-07-01 rik5 Severity3 - Normal => 4 - Important
    2016-03-21 mtmiller Dependencies- => bugs #46285 is dependent
    2015-06-02 jwe Release4.0.0-rc3 => 4.0.0
    2015-04-13 pantxo CategoryPlotting => Plotting with OpenGL
        Summarynew seg fault while plotting => Segfault when using HD Graphics 6000 on Fedora 21

    Back to the top


    Powered by Savane 3.5