bugGNU Octave - Bugs: bug #53644, Possible Octave or Nouveau image...

 
 

bug #53644: Possible Octave or Nouveau image plot bug (not sure which) discovered via ASAN

Submitter:  Dan Sebald <sebald>
Submitted:  Fri 13 Apr 2018 06:28:23 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed 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

Thu 19 Apr 2018 04:13:21 PM UTC, comment #9: 

I've done the full build and "make check" on a system with Nvidia video driver active and a system with Nouveau driver active.  As far as graphics, both succeed (yay!).

It wouldn't surprise me if this issue may have caused problems on other systems and graphics cards, but in those situations the difference could have been that maybe Nouveau is using system memory for its implementation, hence ASAN catches an address-out-of-bounds error, whereas the Intel/Nvidia native graphics drivers use their internal memory for general calculations (since the companies know exactly what memory their own cards have).  Just a guess.  But in the latter situation there's no OS to catch problems internal to the graphics card so however it is programmed (right or wrong) is what happens.

Dan Sebald <sebald>
Mon 16 Apr 2018 05:06:29 AM UTC, comment #8: 

Very useful. This fix also improves line smoothness in
FC 27 using Intel VGA controller

  *-display                
       description: VGA compatible controller
       product: Intel Corporation
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 06
       width: 64 bits
       clock: 33MHz
       capabilities: pciexpress msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:126 memory:db000000-dbffffff memory:90000000-9fffffff ioport:f000(size=64) memory:c0000-dffff

Michael Godfrey <godfrey>
Group Member
Mon 16 Apr 2018 01:41:52 AM UTC, comment #7: 

Oh boy, that was a cryptic bug.  I checked in your changeset here: http://hg.savannah.gnu.org/hgweb/octave/rev/601cc3a063f5.

I don't use the nouveau driver, but I had occasionally seen segfaults when building the plots for the documentation as well.  I hope this fixes it.

Closing report.

Rik <rik5>
Group administrator
Sun 15 Apr 2018 09:23:20 AM UTC, comment #6: 

Found it.  Whew, that one was a "doozy" (using mid-20th century idiom).  It's a bug in plain view, but until one realizes how it comes about, it's baffling.

So, the main clue is that the opengl_renderer::draw_axes routine fails in the same code line every time, but it isn't until the second invocation of "image()" that the ASAN abort occurs.  Look at the following code and notice there are two instances of draw_axes_boxes()


  void
  opengl_renderer::draw_axes (const axes::properties& props)
  {
[snip]
    setup_opengl_transformation (props);

    // For 2D axes with only 2D primitives, draw from back to front without
    // depth sorting
    bool is2D = props.get_is2D (true);
    if (is2D)
      glDisable (GL_DEPTH_TEST);
    else
      glEnable (GL_DEPTH_TEST);

    draw_axes_planes (props);

    if (! is2D || props.layer_is ("bottom"))
      {
        draw_axes_grids (props);
        if (props.get_tag () != "legend" || props.get_box () != "off")
          draw_axes_boxes (props);
      }

[this line disables the glLineStipple activated by draw_axes_boxes(), but...]
    set_linestyle ("-");  // Disable LineStipple

    set_clipbox (x_min, x_max, y_min, y_max, z_min, z_max);

    draw_axes_children (props);

    if (is2D && props.layer_is ("top"))
      {
        draw_axes_grids (props);
        if (props.get_tag () != "legend" || props.get_box () != "off")
          draw_axes_boxes (props);
      }

[...but there is nothing here deactivating the glLineStipple of the second draw_axes_boxes()]


Basically, there was nothing disabling any possibly-set glLineStipple in the draw_axes_boxes() routine such that on the second invocation of image() the stipple was set coming into this routine.  The draw_axes_planes() routine uses GL_QUADS, but filled quads have a line option.  I suppose having stipple on with those quads causes Nouveau to look for stipple information just outside the valid memory region for the stored quad.  That is, in this ASAN output:


Shadow bytes around the buggy address:
  0x0c22801a0080: fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c22801a0090: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c22801a00a0: fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa
  0x0c22801a00b0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c22801a00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c22801a00d0: 00 00 00 00 00[fa]fa fa fa fa fa fa fa fa fa fa
  0x0c22801a00e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c22801a00f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c22801a0100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c22801a0110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c22801a0120: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa


the [fa] is the out-of-range address access (00 means addressable) just after what is probably the quad stored in memory.  One could say this may be a Nouveau issue because it should be able to address the situation when stipple is on, but as I see it we really aren't using such a scenario so I think we can avoid it.  Plus, it makes good sense to have every instance of setting glLineStipple balanced with turning it off after line-drawing is done.

Attached is a patch that makes the ASAN dump go away, and it also makes the documentation figure failures go away on KDE/Plasma where I'm using Nouveau driver and not Nvidia driver.


(file #43931)

Dan Sebald <sebald>
Sat 14 Apr 2018 04:09:23 PM UTC, comment #5: 

Regarding Comment #4, after testing fairly extensively last night, I don't think the multiple drawing of a newly created figure is the root cause of this issue.  I'm going to guess that perhaps the multiple "rendering" comes about from the OS window manager.  (I'm going to carefully use the word "rendering" as specifically referring to the OpenGL actions and "redraw" as referring to Octave running its plot code.)  That is, some of these window managers get sort of fancy with what they are doing.  For example, I think Cinnamon will render a new app window multiple times--small-to-big--as though the window is appearing out of the ether or something.  It could be that Plasma is doing the same, but the window is always the same size, and the randomness of how many draws may come from the window manager drawing based on timing, e.g., every 150 ms for 1 s factoring in the rendering speed.  So, it could be that the OS window manager creates the figure window and keeps rendering the thing while Octave is still populating the figure.  First it is a blank window, i.e.,

xPlane: 1
yPlane: 1
zPlane: 0
xPlaneN: 0
yPlaneN: 0
zPlaneN: 1

and somewhere along the way it becomes a populated window, i.e.,

xPlane: 64.5
yPlane: 0.5
zPlane: 0
xPlaneN: 0.5
yPlaneN: 64.5
zPlaneN: 1
is2d: 1

In any case, what that multiple rendering does when first creating the Figure is it brings the root cause to the core because of the following description.  It appears to be the first rendering after an "image" rendering is causing the ASAN abort.  That is, if I first generate

>> figure


then separately call

>> image


there is no ASAN abort, but from that point forward anything redrawn (not necessarily an image) will cause an abort in the opengl_renderer::draw_axes_planes() rendering.  It doesn't have to be another image().  And the failure is consistently at that same location I first described.

Now, it is only the image() routine that will setup the failure condition.  I can run ploat(1:50), surface(), etc. and keep replotting...none of that rendering fails.  It's only when I call image() then do following rendering, whether it is another Octave plot action, or resizing the window, etc.

So, the root cause lies in the image() rendering code, and it is difficult to find.  I've practically eliminated the draw_image() OpenGL-aimed code and the issue still occurs.  I wonder if maybe there is a colormap or some other ancillary issue unique to image plotting.  Maybe within the OpenGL driver Octave is instructing a colormap that is slightly too big causing the heap out of bounds.

Dan Sebald <sebald>
Sat 14 Apr 2018 06:20:58 AM UTC, comment #4: 

Can anyone think of a recent change to the graphics code that would cause multiple plotting prior to Figure data being all initialized?

Dan Sebald <sebald>
Sat 14 Apr 2018 06:09:06 AM UTC, comment #3: 

The data all sort of makes sense to me in terms of the opengl_renderer::draw_axes_planes() routine.  But something is not quite right about the initialization of the figure/graphics.  If I call

>> figure; image


immediately after launching octave, I see:


octave:1> image
vw: 0 0 560 420
draw_axes_planes: true 9.0
spo 1
spo 2
spo 3
spo 6
xPlane: 1
yPlane: 1
zPlane: 0
xPlaneN: 0
yPlaneN: 0
zPlaneN: 1
is2d: 1
draw_axes_planes: set_polygon_offset (false);
spo 4
spo 5
spo 6
vw: 0 0 560 420
draw_axes_planes: true 9.0
spo 1
spo 2
spo 3
spo 6
xPlane: 1
yPlane: 1
zPlane: 0
xPlaneN: 0
yPlaneN: 0
zPlaneN: 1
is2d: 1
draw_axes_planes: set_polygon_offset (false);
spo 4
spo 5
spo 6
vw: 0 0 560 420
draw_axes_planes: true 9.0
spo 1
spo 2
spo 3
spo 6
xPlane: 1
yPlane: 1
zPlane: 0
xPlaneN: 0
yPlaneN: 0
zPlaneN: 1
is2d: 1
draw_axes_planes: set_polygon_offset (false);
spo 4
spo 5
spo 6
octave:2> vw: 0 0 560 420
draw_axes_planes: true 9.0
spo 1
spo 2
spo 3
spo 6
xPlane: 64.5
yPlane: 0.5
zPlane: 0
xPlaneN: 0.5
yPlaneN: 64.5
zPlaneN: 1
is2d: 1
draw_axes_planes: set_polygon_offset (false);
spo 4
spo 5
spo 6
gonna draw_image
vw: 0 0 560 420
draw_axes_planes: true 9.0
spo 1
spo 2
spo 3
spo 6
xPlane: 64.5
yPlane: 0.5
zPlane: 0
xPlaneN: 0.5
yPlaneN: 64.5
zPlaneN: 1
is2d: 1
draw_axes_planes: set_polygon_offset (false);
spo 4


ASAN aborts.  And if I use

>> figure
>> image


I see:


vw: 0 0 560 420
draw_axes_planes: true 9.0
spo 1
spo 2
spo 3
spo 6
xPlane: 64.5
yPlane: 0.5
zPlane: 0
xPlaneN: 0.5
yPlaneN: 64.5
zPlaneN: 1
is2d: 1
draw_axes_planes: set_polygon_offset (false);
spo 4
spo 5
spo 6
gonna draw_image


i.e., success.  Notice there isn't that extra rounds of calling this routine in the latter example.

I think that this is the timing issue bug that is fairly recent

https://savannah.gnu.org/bugs/?53513

Notice how in the failing first case I used "figure; image".  In the successful latter case I used "figure" followed by "image".  That time it took me to type "i m a g e <CR>" was easily enough of a delay to do effectively what Rik's doing with adding a delay.  So, the above is a clue as to what is happening.  It looks to me that the figure is created, perhaps only partially, while plotting is allowed to proceed.  Some kind of recursion in the plotting action is going on until (maybe) some variable being set is stopping the recursion.

Reiterating, there should only be one call to opengl_renderer::draw_axes_planes() in drawing this simple image figure, not five calls to draw_axes_planes().  Notice how the first few passes are using a box of (0,0) to (1,1) (probably default upon creating the figure) while the last few have a box more in line with the image data (0.5,0.5) to (64.5,64.5).  And the number of passes is random when I try this multiple times.

The same type of scenario occurs if I do a data plot like "figure; plot(1:50)", but that doesn't seem to cause a pointer outside of memory block so ASAN doesn't abort.

Dan Sebald <sebald>
Sat 14 Apr 2018 03:22:27 AM UTC, comment #2: 

Not sure this is specific to images.  Nonetheless, I'm writing notes here to keep track of things.

It seems that the ASAN consistently exits at "spo 4" in the following location in gl-render.cc:


  void
  opengl_renderer::set_polygon_offset (bool on, float offset)
  {
    if (on)
      {
std::cerr << "spo 1\n";
        glEnable (GL_POLYGON_OFFSET_FILL);
std::cerr << "spo 2\n";
        glEnable (GL_POLYGON_OFFSET_LINE);
std::cerr << "spo 3\n";
        glPolygonOffset (offset, offset);
      }
    else
      {
std::cerr << "spo 4\n";
        glDisable (GL_POLYGON_OFFSET_FILL);
std::cerr << "spo 5\n";
        glDisable (GL_POLYGON_OFFSET_LINE);
      }
std::cerr << "spo 6\n";
  }


The image() routine causes the above hunk of code to run three times (in pairs, i.e., the "on" is true, some drawing, then "on" is false) and on the third time that "glDisable (GL_POLYGON_OFFSET_FILL);" is where ASAN complains and exits.

That routine glDisable() is quite simple, it's basically disabling the polygon features or drawing a filled surface and an outlining or border.  So I can't imagine that routine is the actual problem, just where ASAN recognizes the problem.  Also, glPolygonOffset() is pretty innocuous, as it controls a little z-depth offset to bring the lines nearer and prevent the stitching phenomenon.

So, as is typical with these ASAN like programs, we look prior to the occurrence of the dump.  I worked backward and put pre-process conditional around the following hunk of code


  opengl_renderer::draw_axes_planes (const axes::properties& props)
  {
[snip]
#if 0
    if (! is2d)
      {
        // X plane
        glVertex3d (xPlane, yPlaneN, zPlaneN);
        glVertex3d (xPlane, yPlane, zPlaneN);
        glVertex3d (xPlane, yPlane, zPlane);
        glVertex3d (xPlane, yPlaneN, zPlane);

        // Y plane
        glVertex3d (xPlaneN, yPlane, zPlaneN);
        glVertex3d (xPlane, yPlane, zPlaneN);
        glVertex3d (xPlane, yPlane, zPlane);
        glVertex3d (xPlaneN, yPlane, zPlane);
      }

    // Z plane
    glVertex3d (xPlaneN, yPlaneN, zPlane);
    glVertex3d (xPlane, yPlaneN, zPlane);
    glVertex3d (xPlane, yPlane, zPlane);
    glVertex3d (xPlaneN, yPlane, zPlane);
#endif
[snip]


and the image() routine works fine, can be repeated, have different plotting methods in-between, etc.  So, the next step is to look for anything peculiar about the memory buffer for the drawing of the axes in this code hunk.

Dan Sebald <sebald>
Fri 13 Apr 2018 06:32:36 PM UTC, comment #1: 

Rik commented here:

https://savannah.gnu.org/bugs/?53604#comment10

"We could put an assert statement in the code temporarily to make sure that offset is in some reasonable range ([-5, +5])."

If it is temporary, for the sake of finding a bug, why not make the assert the exact range?  If the image is shifted, say one pixel to the left/right or top/bottom, we'd want to know that.  That would be the likely risk here; some kine of 0-start versus 1-start indexing.

Dan Sebald <sebald>
Fri 13 Apr 2018 06:28:23 PM UTC, original submission:  

In Bug #53604 I've scene an ancillary issue with some OpenGL image plotting:


octave:1> demo image
image example 1:
 clf;
 colormap (jet (21));
 img = 1 ./ hilb (11);
 x = y = -5:5;
 subplot (2,2,1);
  h = image (x, y, img);
  ylabel ("limits = [-5.5, 5.5]");
  title ("image (x, y, img)");
 subplot (2,2,2);
  h = image (-x, y, img);
  title ("image (-x, y, img)");
 subplot (2,2,3);
  h = image (x, -y, img);
  title ("image (x, -y, img)");
  ylabel ("limits = [-5.5, 5.5]");
 subplot (2,2,4);
  h = image (-x, -y, img);
  title ("image (-x, -y, img)");

octave:2> =================================================================
==3309==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x611000d406a8 at pc 0x7f656654a733 bp 0x7fff060b1cc0 sp 0x7fff060b1468
READ of size 200 at 0x611000d406a8 thread T0
    #0 0x7f656654a732  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x79732)
    #1 0x7f65226a8dbc  (/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so+0x5bddbc)
    #2 0x7f65226a9cfb  (/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so+0x5becfb)
    #3 0x7f65226a9e76  (/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so+0x5bee76)
    #4 0x7f65226b49fd  (/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so+0x5c99fd)
    #5 0x7f652234782e  (/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so+0x25c82e)
    #6 0x7f652230c9d5  (/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so+0x2219d5)
    #7 0x7f65222f0ddb  (/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so+0x205ddb)
    #8 0x7f65223097a2  (/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so+0x21e7a2)
    #9 0x7f65221b9234  (/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so+0xce234)
    #10 0x7f6564747feb in octave::opengl_renderer::set_polygon_offset(bool, float) ../octave/libinterp/corefcn/gl-render.cc:3932
    #11 0x7f656474fde8 in octave::opengl_renderer::draw_axes_planes(axes::properties const&) ../octave/libinterp/corefcn/gl-render.cc:1194
    #12 0x7f6564791374 in octave::opengl_renderer::draw_axes(axes::properties const&) ../octave/libinterp/corefcn/gl-render.cc:2125
    #13 0x7f656474afdd in octave::opengl_renderer::draw(graphics_object const&, bool) ../octave/libinterp/corefcn/gl-render.cc:647
    #14 0x7f65660c3a15 in octave::opengl_renderer::draw(Matrix const&, bool) ../octave/libinterp/corefcn/gl-render.h:60
    #15 0x7f656475e6bc in octave::opengl_renderer::draw_figure(figure::properties const&) ../octave/libinterp/corefcn/gl-render.cc:712
    #16 0x7f656474afdd in octave::opengl_renderer::draw(graphics_object const&, bool) ../octave/libinterp/corefcn/gl-render.cc:647
    #17 0x7f656601904a in QtHandles::GLCanvas::draw(octave_handle const&) ../octave/libgui/graphics/GLCanvas.cc:72
    #18 0x7f6565fcbdfb in QtHandles::Canvas::canvasPaintEvent() ../octave/libgui/graphics/Canvas.cc:304
    #19 0x7f655d53686c  (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x1b386c)
    #20 0x7f655d516047 in QWidget::event(QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x193047)
    #21 0x7f655d4d782b in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x15482b)
    #22 0x7f655d4df0f3 in QApplication::notify(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x15c0f3)
    #23 0x7f655c7595c7 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x28a5c7)
    #24 0x7f655d50f189 in QWidgetPrivate::sendPaintEvent(QRegion const&) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x18c189)
    #25 0x7f655d4e6703  (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x163703)
    #26 0x7f655d4e7094  (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x164094)
    #27 0x7f655d4fe66e in QWidgetPrivate::syncBackingStore() (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x17b66e)
    #28 0x7f655d5161b7 in QWidget::event(QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x1931b7)
    #29 0x7f655d629b6a in QMainWindow::event(QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x2a6b6a)
    #30 0x7f6565f63124 in QtHandles::FigureWindowBase::event(QEvent*) ../octave/libgui/graphics/FigureWindow.h:33
    #31 0x7f655d4d782b in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x15482b)
    #32 0x7f655d4df0f3 in QApplication::notify(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x15c0f3)
    #33 0x7f655c7595c7 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x28a5c7)
    #34 0x7f655c75bd3c in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x28cd3c)
    #35 0x7f655c7b2eb2  (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x2e3eb2)
    #36 0x7f65541b2286 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4c286)
    #37 0x7f65541b24bf  (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4c4bf)
    #38 0x7f65541b254b in g_main_context_iteration (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4c54b)
    #39 0x7f655c7b24de in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x2e34de)
    #40 0x7f655c757619 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x288619)
    #41 0x7f655c760663 in QCoreApplication::exec() (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x291663)
    #42 0x7f6565dab253 in octave::gui_application::execute() ../octave/libgui/src/octave-gui.cc:202
    #43 0x562a27d7afa9 in main ../octave/src/main-gui.cc:104
    #44 0x7f655ee21b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #45 0x562a27d7b849 in _start (/home/sebald/octave/octave-53604/build1/src/.libs/octave-gui+0x2849)

0x611000d406a8 is located 0 bytes to the right of 232-byte region [0x611000d405c0,0x611000d406a8)
allocated by thread T0 here:
    #0 0x7f65665afd38 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded38)
    #1 0x7f65226a6032  (/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so+0x5bb032)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x79732)
Shadow bytes around the buggy address:
  0x0c22801a0080: fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c22801a0090: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c22801a00a0: fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa
  0x0c22801a00b0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c22801a00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c22801a00d0: 00 00 00 00 00[fa]fa fa fa fa fa fa fa fa fa fa
  0x0c22801a00e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c22801a00f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c22801a0100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c22801a0110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c22801a0120: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==3309==ABORTING


From my recollection reading other bugs in the track, Nouveau is known to have some issues.  It's only on some KDE test platforms that Nouveau is run, whereas on my Mint/Cinnamon system the Nvidia driver is used.  It could be that Nvidia driver is more forgiving, if there happened to be an Octave bug in using OpenGL, but I'm not sure what the issue is.

Dan Sebald <sebald>

 

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

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by godfrey (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-04-16 rik5 StatusNone Fixed
        Open/ClosedOpen Closed
    2018-04-15 sebald Attached File- Added octave-opengl_qt_toolkit_line_stipple_nouveau_driver-djs2018apr15.patch, #43931

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code