bugGNU Octave - Bugs: bug #44478, test __osmesa_print__.cc-tst...

 
 

bug #44478: test __osmesa_print__.cc-tst crashes with Nvidia drivers

Submitter:  Tatsuro MATSUOKA <tmacchant>
Submitted:  Sat 07 Mar 2015 10:56:37 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  4 - Important
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Tatsuro MATSUOKA Open/Closed:  * Closed
Release:  * 4.0.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 03 Mar 2018 10:28:42 PM UTC, comment #119: 

I agree, not exactly fixed, but the issue is still resolved since osmesa is no longer required.

Rik <rik5>
Group administrator
Sat 03 Mar 2018 08:41:43 PM UTC, comment #118: 

This seems to be "fixed",
probably thanks to the changes made in bug #53186,
since mesa is not necessary any longer.
`make check` now passes without crash,
and without any trick like LD_PRELOAD.
(tested: hg id e08c1fea96c5)

ederag <ederag>
Sat 30 Dec 2017 02:36:03 AM UTC, comment #117: 

I don't know what the status of the Nvidia/OSMesa/swrast situation is.  Years ago I built OSMesa and the OpenGL stuff from scratch, was able to make changes, submit bug reports to the maintainers of the various drivers, etc.  I don't want to dig that deep again.

But the problem still seems to be an issue on my relatively up-to-date Mint, in particular the build process.  Perhaps there are some build work-arounds that avoid OSMesa and the issue altogether.  I'm happy to use that, but I suspect that generally speaking users who are just compiling won't like doing too much special.

With that in mind, and particular to address the issue raised in

https://savannah.gnu.org/bugs/?func=detailitem&item_id=44478#comment112

I've written a little bash script called "octave-olp" that is analogous to "octave-cli" but it does a few things:

1) Main issue: searches for the possibility that an Nvidia driver is active, and if there is a possibility octave-olp will search for an alternative generic driver to pre-load.  Since octave-olp is intended for off-line printing, what does it matter if the spiffy Nvidia driver is used?  I do see some figures in octave.pdf for voronoi (Figure 30.1) so it must be work (and I did a full rebuild with just the "configure" sans any preload on my part).

2) I'll make this a second point for importance: I've confirmed that Nvidia driver and generic driver are found on my system.  That is, I wondered if the system utility I'm using will only recognize the generic driver if the generic driver had been used prior (i.e., it only finds "installed" libraries).  Perhaps it is because at power up the OS loads the generic driver before even knowing details about the graphics hardware and a custom driver; then the library remains resident in the proper tables.  On the other hand, maybe there is an issue on systems that don't use any sort of generic driver at power-up.  That would be the fly in the ointment here, i.e., there is a generic driver present but it isn't found because it wasn't used prior.  I left some commented-out alternative OS utilities in the script file in case there is an issue.

3) This may not be a solution for Mac X OS (or windows).  Does the Nvidia driver problem exist for those systems?  Hmm, that has got me thinking.  I've placed "octave-olp" in the "figure-generating-commands", but if Windows can't run octave-olp, then what?  Is it possible to make a script that looks like bash on Unix and some other kind of fall-through script file on Windows?

4) Systems for which there is no Nvidia driver present, or for systems where there is no generic driver present, either there is no pre-load (former) or the loaded $GRAPHICS_LIB is empty "".  In both cases, the fall-back should be just like running "octave-cli --norc --silent --no-history" with the additional inputs.

5) The octave-olp is meant to work in both the build environment and the installed environment.  (See top of the bash script.)  If I run octave-olp after the fact and try plotting some figure, I see


linux@ ~ $ octave-olp
octave:1> plot(1:50)
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
octave:2>


Oh well, that's the way it goes.

As far as I'm concerned, this approach is a good enough solution if the online print works.  It solves the Nvidia driver build problem and at least gives a quick path for Nvidia users to create off-line figures.  I don't know what else beyond that one could expect from Octave.

(file #42760)

Dan Sebald <sebald>
Fri 13 May 2016 07:23:54 PM UTC, comment #116: 

The reason the _gl{extensions,renderer,vendor,version}__ properties are empty after doing something like


figure visible off
sombrero


is because no rendering actually happens for invisible figures so no context is created.  However, if you print the invisible figure, then you should see some information in the properties if you are using OSMesa to do the rendering.

John W. Eaton <jwe>
Group administrator
Fri 13 May 2016 04:47:29 PM UTC, comment #115: 

I saw the added OpenGL query yesterday and rebuilt.  So that is a realtime test that can be used.  Although the library info is not displayed when the figure is not visible, I would think that info could be gotten in any case by creating an unused context at launch.

I'm building OSMesa from scratch and still have the problem we're seeing.

I wouldn't mind flashing during building, be it temporary, but the reason most other people looking for a similar solution to their projects is that they are building on a system that has no graphics, e.g., server.

Dan Sebald <sebald>
Fri 13 May 2016 04:38:16 PM UTC, comment #114: 

I don't really know how to reliably detect that the nvidia library is linked with Octave.

All OpenGL function calls require a valid context to work properly, even the one that asks for the vendor and version info.  That's why I put that info in the figure properties (changeset http://hg.savannah.gnu.org/hgweb/octave/rev/1449e3b98941) and then, only after the figure is drawn.

John W. Eaton <jwe>
Group administrator
Fri 13 May 2016 04:35:26 PM UTC, comment #113: 

Ubuntu 14.04 and Linux Mint 17 users should either compile their own OSMesa or avoid using OSMesa with Octave altogether. Any results you get on either of those distributions are likely to be skewed by a broken libosmesa6 package. See https://bugs.launchpad.net/bugs/1551028

I'm hoping this reduces confusion, not adds to it. This has nothing to do with whether nvidia is used or not, I'm just noting here that OSMesa on these distributions will not work in Octave, unless you upgrade to Ubuntu 16.04 or Linux Mint 18 (not yet released).

Mike Miller <mtmiller>
Group Member
Fri 13 May 2016 04:20:51 PM UTC, comment #112: 

Summarizing: Either Nvidia and OSmesa will never be able to work together, or devising a workaround is going to require months of programmer time.

I think the best course now is to search for a way to detect the library clash and avoid it by disabling offscreen rendering with osmesa at runtime.  During a documentation build, that might mean flashing the figures on the screen--certainly annoying, but not fatal.

Rik <rik5>
Group administrator
Thu 12 May 2016 06:34:37 PM UTC, comment #111: 

Slow is better than the documentation failing every time one tries to build Octave.  I realize the bug is more about _osmesa_print_ crashing than the documentation, but disabling that test for the short term is an easy solution.  Long term there is going to need to be some work.

I'm going to try and see if I can use GLEW to at least recognize the presence of framebuffer support.  If that can be done, then that is an easy runtime conditional that can be used anywhere in Octave, be it _osmesa_print_, to check whether we should expect malfunction if OSMesa OpenGL commands are used.

Dan Sebald <sebald>
Thu 12 May 2016 06:25:49 PM UTC, comment #110: 

If you only link to OSMesa, you don't get accelerated graphics.  You just get software rendering.  That works, but is slow.

John W. Eaton <jwe>
Group administrator
Thu 12 May 2016 06:18:35 PM UTC, comment #109: 

This result

https://savannah.gnu.org/bugs/?44478#comment93

shows that your sample program will work when just OSMesa is linked.  For the Octave sample we've been using:

[launch octave]

graphics_toolkit ('qt')
figure visible off
sombrero
print invisible.pdf


isn't it the case that the only OpenGL context created will be

OSMesaCreateContext()
OSMesaMakeCurrent()

?  Of course, if the user were to make this visible it would crash...or wait, would it even link?  Well, for octave-os, one could switch around -lOSMesa -lGL (as done in a previous comment).  The point is, the user will never use octave-os...it would be only for creating the documentation and nothing else.

Dan Sebald <sebald>
Thu 12 May 2016 06:05:21 PM UTC, comment #108: 

Dynamically linking won't solve the problem for reasons that I've already explained.

A special version of Octave that only links in libOSMesa and not libGL does not solve the problem of offscreen rendering for figures that have the visible property set to "off".

John W. Eaton <jwe>
Group administrator
Thu 12 May 2016 05:58:45 PM UTC, comment #107: 

Dynamically loading would probably be a solution.  Not a real good one, I suppose.  It would mean deactivating the current graphics context altogether.

The standalone program approach would work, but I'm more partial to the framebuffers approach for a couple reasons, after thinking about this a bit.  First, the framebuffers is pretty seemless and doesn't require any type of context switching.  Second, and probably the bigger reason, is that framebuffers seems more OpenGL standard-friendly, so if there is any entity that is likely to change direction on this it is Mesa.  They may well decide at some point to take OSMesa and shape it into a framebuffer mold.  If that does happen, then Octave won't have to change anything because it would find framebuffer support in the future Mesa driver and not call OSMesaCreateContext() which will have to have come from an older version of Mesa at that point.

In the short term, if anything, what makes sense to me is simply creating a version of Octave that only links in -lOSMesa and not -lGL used for creating the documentation at build time.  Otherwise, the consequence of this problem is small because 99% of the time I would guess the user has the figure visible when attempting to print, and that works.  It's only when off-screen rendering is needed for documentation that this is critical.  It would be pretty easy to have two slightly different links.  And then if framebuffers or something else proves to be robust, take out that build command that links only -lOSMesa to create an octave-os.

Dan Sebald <sebald>
Thu 12 May 2016 04:57:07 PM UTC, comment #106: 

I think the links that in comment 104 are just saying that it is better to use dlopen (or LoadLibrary on Windows) to dynamically load the OpenGL library instead of linking directly to it.  But we don't really have that option if we use the QtOpenGL widgets, since the Qt libraries are linked directly with libGL.  And there is a lot of software that doesn't call the OpenGL functions through function pointers.  For example, gl2ps.  So dynamically loading the libraries doesn't work for that case anyway.  The symbols need to be known at link time.

John W. Eaton <jwe>
Group administrator
Thu 12 May 2016 04:50:45 PM UTC, comment #105: 

Instead of using framebuffers, my thought was to write a standalone program that links only with OSMesa and not GL.  Then this external program acts as a filter, accepting the graphics properties that define the plot and generating PostScript (or whatever) to be read by Octave.  The standalone program can use Octave libraries, it just can't to be linked with libGL or the GUI libraries (which would indirectly cause libGL to be linked).

John W. Eaton <jwe>
Group administrator
Thu 12 May 2016 04:18:01 PM UTC, comment #104: 

Mixing functions is obviously what's going on.  But I still don't know what to make of the description of how OpenGL operates:

https://www.opengl.org/wiki/Load_OpenGL_Functions
https://www.opengl.org/wiki/Creating_an_OpenGL_Context_%28WGL%29

The vague descriptions of how to initialize OpenGL suggest to me that the OpenGL functions shouldn't exist until a context is created.  Perhaps the loading of functions that is referred to is the OpenGL extensions only.

What Brian has written suggests that no matter the intended OpenGL initialization, something special is going on with Mesa/OSMesa that allows their OpenGL routines to "morph".

What Rik has said is what I've been trying to suggest and attempting to do.  Also, Brian in that quote says as well: "If you want to do offscreen rendering
with a hardware GPU, the easiest approach is to use framebuffer objects."  I've been trying to make framebuffer work with the nVidia driver.  From what I'm reading, I should be able to used framebuffer as an OpenGL extension, and that something like GLEW is needed to make that framebuffer support available.  So, the approach, I think, is to query the current OpenGL somehow to see if it has a framebuffer extension function--if so, then use the framebuffer for offscreen rendering--if not, then call OSMesaCreateContext and hope that -lGL is the Mesa OpenGL environment.  And that approach suggests we should never have the -lOSMesa -lGL order of linking otherwise we wouldn't be able to get at the other vendor's OpenGL extensions.

In all, it seems like a lot of work for what is ultimately a bitmap converted to some other graphics format using an external program.

Dan Sebald <sebald>
Thu 12 May 2016 03:19:31 PM UTC, comment #103: 

That quote from Brian on freedesktop.org seems definitive.

Instead of getting OSMesa and Nvidia libgl to work together, should the focus of this issue change to detecting that the condition exists and avoiding it if it does?

Rik <rik5>
Group administrator
Thu 12 May 2016 03:01:48 PM UTC, comment #102: 

The functions are supposed to access the data through the pointer to the current context.  But the layout of the structure referenced by the pointer is not necessarily the same for all implementations.  So mixing functions from one implementation with the context created by another is highly likely to fail.

Programs that use OpenGL are not calling functions through pointers, they are just calling the functions directly.  So there is no way for the libGL library to magically "map" functions from one library to another when switching context.  So if they even happened to be handed a pointer to the context created by another vendor's implementation, it isn't going to do any good.  The data layout would have to be exactly the same.  There is no reason to assume that it would be.

Please see this question on the mesa mailing list: https://lists.freedesktop.org/archives/mesa-users/2015-May/000971.html

A quote from Brian:  "Just to be clear, OSMesa does not work with nvidia's driver/hardware (or any other GPU).  The OSMesa interface only works with software rendering (swrast, softpipe, llvmpipe)."

John W. Eaton <jwe>
Group administrator
Thu 12 May 2016 07:49:26 AM UTC, comment #101: 

I understand what you've done as far as linking.  However, as far as I understand, OpenGL routines are slightly different.  All the glGetIntegerv(), etc. are not directly callable functions from the application.  One has to create a valid context and then the OpenGL routines are mapped somehow so they can be called by the application.

I would think for OpenGL linking order shouldn't matter in theory (but of course, that's currently the case).


  OSMesaContext ctx = OSMesaCreateContextExt (OSMESA_RGBA, 16, 0, 0, NULL);


should know the GL routines to map into the context.

Anyway, I have Mesa (with OSMesa) compiling, so I'm able to make modifications to OSMesa, print out variables, etc. under the various scenarios.  If you have something in mind I should try, let me know.

All I can add right now is a confirmation that the OSMesaCreateContext() seems to go through the same program flow no matter the order of library linking.  But, when it is -lGL -lOSMesa it's clear that the Mesa glGetIntegerv is not being called.


Dan Sebald <sebald>
Thu 12 May 2016 04:57:24 AM UTC, comment #100: 

As I understand it, OpenGL functions all work by reading or writing to the "current context".  The current context is just some data structure that can be accessed through a pointer.  There is no guarantee that the context will be laid out in the same way for all implementations.  So I don't think there is any reason to expect functions from the nvidia library to work with a context allocated by Mesa.  And that assumes that the context is even shared properly between the implementations.  I see no reason to expect that to be true either.

And yes, the link order matters.  You can create a simple example to show that:


$ cat a.cc
#include <iostream>

void
fcn (void)
{
  std::cerr << "a" << std::endl;
}
$ cat b.cc
#include <iostream>

void
fcn (void)
{
  std::cerr << "b" << std::endl;
}
$ cat main.cc
extern void fcn (void);

int
main (void)
{
  fcn ();
  return 0;
}
$ g++ -fPIC -shared -o libba.so a.cc
$ g++ -fPIC -shared -o libbb.so b.cc
$ g++ -fPIC main.cc -L. -la -lb
$ ldd a.out
        linux-vdso.so.1 (0x00007ffc53486000)
        liba.so => not found
        libb.so => not found
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe7b195f000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe7b165a000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe7b1444000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe7b109f000)
        /lib64/ld-linux-x86-64.so.2 (0x000055a83cb52000)
$ LD_LIBRARY_PATH=. ./a.out
a
$ g++ -fPIC main.cc -L. -lb -la
$ ldd a.out
        linux-vdso.so.1 (0x00007ffdec1dc000)
        libb.so => not found
        liba.so => not found
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1e07536000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1e07231000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1e0701b000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e06c76000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555b62265000)
$ LD_LIBRARY_PATH=. ./a.out
b


John W. Eaton <jwe>
Group administrator
Thu 12 May 2016 03:18:57 AM UTC, comment #99: 

I can't find init in the OSMesa code (there's an __init_), so I'm assuming that _init is present in all library files for dynamic loading or something.  OK, that one is out as a possible conflict.  I think I'll just have to build OSMesa and debug...hopefully is isn't a involved as the swrast and gallium drivers.

Dan Sebald <sebald>
Thu 12 May 2016 02:28:48 AM UTC, comment #98: 

Well, there aren't that many common global variables that are present in both libraries (i.e., common name, both of which have a "T" alongside it), discounting the glXYZ family which I think are just table entries:


000000000004ba00 T _glapi_create_table_from_handle
000000000028b2c0 T _glapi_create_table_from_handle

0000000000019cb0 T _init
000000000004e748 T _init


There are a few cases where the function might be in OSMesa lib referenced by GL lib.  (Why it would go that direction, I don't know.  Where would these functions come from if OSMesa were not linked in?  Is that a conflict?)


                 U _glapi_check_multithread
00000000002a5840 T _glapi_check_multithread

                 U _glapi_get_dispatch_table_size
00000000002a5770 T _glapi_get_dispatch_table_size

                 U _glapi_get_proc_address
00000000002a5680 T _glapi_get_proc_address

                 U _glapi_get_proc_offset
00000000002a5640 T _glapi_get_proc_offset

                 U _glapi_set_context
00000000002a5850 T _glapi_set_context

                 U _glapi_set_dispatch
00000000002a5860 T _glapi_set_dispatch


My guess would be that the conflict lies with one of the above routines.  I could send this to the OSMesa discussion list and see what they say.  (I'll make sure I have the absolute latest of all code to see if these names may have changed.)

Dan Sebald <sebald>
Thu 12 May 2016 02:09:59 AM UTC, comment #97: 

In fact, the OpenGL video does act flaky.  Here is the result for John's second example:


sebald@ ~/octave/opengl_nvidia $ g++ osmesa-fltk-foo-mod.cc -lGL -lOSMesa -lfltk -lfltk_gl
sebald@ ~/octave/opengl_nvidia $ a.out
GL_DEPTH_BITS: 24
GL_STENCIL_BITS: 0
GL_DEPTH_BITS: 1361941888
GL_STENCIL_BITS: 32766
sebald@ ~/octave/opengl_nvidia $ g++ osmesa-fltk-foo-mod.cc -lOSMesa -lGL -lfltk -lfltk_gl
sebald@ ~/octave/opengl_nvidia $ a.out
Segmentation fault


In the first case -lGL -lOSMesa, the FLTK X appears in a window and I close the window and it continues.  In the second case, there's a blip of a window appearing in the upper left corner, it disappears and Seg-fault appears.

I think there are some inadvertently shared variables and or functions between nVidia and Mesa.  That, or both started from a similar code base and programmers didn't bother to change variable/function names.

Any ideas?  All I can think of is to compare the global name's in the two libraries for what might be common, or compile OSMesa attempting to iteratively debug where exactly OSMesa is failing in the test programs and Octave.

Dan Sebald <sebald>
Thu 12 May 2016 01:41:44 AM UTC, comment #96: 

Good guess Rik.  Here's -lOSMesa first (reports 16 for depth) followed by -lOSMesa second (reports 0 for depth):


sebald@ ~/octave/opengl_nvidia $ g++ osmesa-foo-mod.cc -lOSMesa -lGL
sebald@ ~/octave/opengl_nvidia $ a.out
CTX: 0x7f64cf35c010
GL_DEPTH_BITS: 16
GL_STENCIL_BITS: 0
sebald@ ~/octave/opengl_nvidia $ g++ osmesa-foo-mod.cc -lGL -lOSMesa
sebald@ ~/octave/opengl_nvidia $ a.out
CTX: 0x7ff768d7e010
GL_DEPTH_BITS: 0
GL_STENCIL_BITS: 0


Of course, the worry would be that this linking in Octave might cause nVidia OpenGL to act flaky, which could be a worse problem.

I'm looking at the innards of OSMesa at the moment.  In particular OSMesaMakeCurrent().  One thing I notice is there is this line:


   _mesa_make_current( &osmesa->mesa, osmesa->gl_buffer, osmesa->gl_buffer );


in a string of commands pertaining to frame buffer resizing and stuff.  At the end of this string of function calls and code is


   return GL_TRUE;


But, that _mesa_make_current() returns a Boolean, so I can see now how the _mesa_make_current() can fail and the function OSMesaMakeCurrent() still indicates success.  That might explain how we can see


GL_DEPTH_BITS: 0
GL_STENCIL_BITS: 0


rather than getting the


    error ("__osmesa_print__: OSMesaMakeCurrent failed!");


error message.

Other observations are that the OSMesa has a lot of commands pertaining to multi-threading.

Well, anyway, so why this order of linking matters?  All I can think of right now is that there seem to be a lot of variables and such apparently common to both the -lGL and -lOSMesa drivers, judging from the contents of the "nm" dumps I did on the two libraries.  It takes some investigation to tell exactly what's happening and how these are all linked together.  For example, some entries are in the text space "T" in one module, but undefined "U" in the other module.  But there are some that are present in both:


000000000004ba00 T _glapi_create_table_from_handle



000000000028b2c0 T _glapi_create_table_from_handle


I wonder if there might be a handful of variables and/or functions that are the same in the source code for the two libraries and are interfering with proper behavior.  Rik, we probably should find some linking switch for uniqueness of global names in the object code, if just to help diagnose.

Dan Sebald <sebald>
Thu 12 May 2016 12:45:32 AM UTC, comment #95: 

Is the order of -l options important?  For example, is the first listed library searched first to resolve symbols?  In that case, I would hope that


g++ osmesa-foo-mod.cc -lOSMesa -lGL


might work.

Rik <rik5>
Group administrator
Thu 12 May 2016 12:42:32 AM UTC, comment #94: 

On second thought, looking at these results from the object file list:


000000000006a1c0 T glGetIntegerv
000000000006a1e0 T glGetLightfv
000000000006a200 T glGetLightiv


makes me think these aren't the actual functions.  Although the 'T' means code space, there's only 32 bytes distance between the glGetIntegerv and glGetLightfv.  That makes me think these are entries in a table.  The OpenGL standard indicates the glXYZ functions do not exist until there is a valid context.

To test this theory, I've run JWE's minimal program--without the -lGL library linked in--and did not create an OSMesa context.  It segfualts.  So... doing


  OSMesaContext ctx = OSMesaCreateContextExt (OSMESA_RGBA, 16, 0, 0, NULL);


indicates it is creating a valid context.  And in this bare-bones example


  glGetIntegerv (GL_DEPTH_BITS, &z);
  glGetIntegerv (GL_STENCIL_BITS, &s);


does not crash.  So, OK, then perhaps OSMesa is operating correctly and the OpenGL routines are getting mapped into the space.

BUT, when the -lGL library is nVidia, the result of the above two lines is no action (i.e., z and s come back unchanged).

Let's try then commenting out this line:


  // Bind the buffer to the context and make it current.
//  if (! OSMesaMakeCurrent (ctx, buffer, GL_UNSIGNED_BYTE, Width, Height))
//    error ("__osmesa_print__: OSMesaMakeCurrent failed!");


and see how that runs when -lGL is not linked in...  Does not crash, but comes back:


sebald@ ~/octave/opengl_nvidia $ a.out
CTX: 0x7f3b83744010
GL_DEPTH_BITS: 0
GL_STENCIL_BITS: 0


Interesting, so it could be OSMesaMakeCurrent() that is failing.  I'll look at the source code to see what it is doing.

Dan Sebald <sebald>
Wed 11 May 2016 10:22:38 PM UTC, comment #93: 

Yes, I think the multiple function names is the issue.  Check this out:


sebald@ ~/octave/opengl_nvidia $ g++ osmesa-foo-mod.cc -lGL -lOSMesa
sebald@ ~/octave/opengl_nvidia $ a.out
CTX: 0x7fad95c9b010
GL_DEPTH_BITS: 0
GL_STENCIL_BITS: 0
sebald@ ~/octave/opengl_nvidia $ g++ osmesa-foo-mod.cc -lOSMesa
sebald@ ~/octave/opengl_nvidia $ a.out
CTX: 0x7f28624d6010
GL_DEPTH_BITS: 16
GL_STENCIL_BITS: 0


I didn't even have to link in the OpenGL library to make the glGetIntegerv function work properly.  Whether that means the whole OSMesa will function properly, I don't know.  But, is it possible to do a partial link and resolve the function calls in the _osmesa_print_.o object using -lOSMesa and then the rest of Octave using -lGL?  Then combine?

Dan Sebald <sebald>
Wed 11 May 2016 09:57:43 PM UTC, comment #92: 

Regarding the conflicting names question, I have nVidia driver installed.  Is it the case then that my GL is one built by nVidia?  In some sense it doesn't matter which is current for the following check.  We know we are linking in both -lGL and -lOSMesa.

I do the following:


nm -D /usr/lib/x86_64-linux-gnu/libGL.so > libGL_functions.txt
nm -D /usr/lib/x86_64-linux-gnu/libOSMesa.so > libOSMesa_functions.txt


then open those two files to see if there are function names in common.  There are, For example, I see

000000000006a1c0 T glGetIntegerv

in the libGL file, and

00000000002a8100 T glGetIntegerv

in the libOSMesa file.  (Please verify on your system if there is a similar namespace.)

It probably would be a good idea to add some flag to Octave build that requires unique function names.  Generally, though, I'd think that C/C++ compiler/linkers just search until they find the appropriate global name and conclude, "it's there, next one".

I think it might be fastest to go to the Mesa/OSMesa source code and see if what the developers have done is non-portable in some way.

In the mean time, I was searching the Internet for solutions to offscreen rendering with OpenGL.  There are a lot of people asking how to do just that, feeling Mesa/OSMesa isn't adequate for their system, and looking for a GL, GLU, GLUT only solution.  There's a lot of back and forth comments, but ultimately no good answers.

Dan Sebald <sebald>
Wed 11 May 2016 09:25:50 PM UTC, comment #91: 

Responding to comment #90, wouldn't having two identical function names in two different libraries produce some sort of warning or error during the link phase?  Or if it doesn't, is there a way to turn on verbose messages during the link to make that happen?

If this is really about the link process rather than the code then it might be good to take jwe's example and separate it out into a compile stage command and a link command so that you could focus on the piece that was actually the problem.

Rik <rik5>
Group administrator
Wed 11 May 2016 09:10:16 PM UTC, comment #90: 

https://savannah.gnu.org/bugs/?44478#comment88

In one of the links I provided, the issue the programmer had was pretty much the same as what we are seeing.  Someone put a comment there that ultimately the issue is that -lGL and -lOSMesa are sharing some similar function names so exactly which gets called is anyone's guess.  (That's why I'm wondering if somehow the Mesa GL library can resolve this while the nVidia library can't.)  They further commented that GLEW might help because GLEW is a utility to organize OpenGL routines, particularly for OpenGL extensions.  Some of these extensions have "FunctionEXT", some don't, depends on their age, acceptance in OpenGL versions, etc.  I think GLEW is supposed to make life a little easier to manage the OpenGL name-space.

Dan Sebald <sebald>
Wed 11 May 2016 09:02:56 PM UTC, comment #89: 

"It works fine for me when linked with Mesa libs (GL and OSMesa), but not when linked with the nvida OpenGL lib."

Do you think the issue is simply that OSMesa only works well with Mesa GL because Mesa GL has knowledge of OSMesa's operation somehow?  Something that another library (in this case nVidia) can't know about?  If so, perhaps it is futile trying to solve this through coding, but instead maybe get lucky during the Octave config process to point to the proper Mesa GL library when linking, if it is present rather than just -lGL.

There is the OpenGL extensions I mentioned the other day.  (But that may be limited to nVidia).  Any other approach available?

https://www.opengl.org/discussion_boards/showthread.php/165359-Offscreen-rendering

http://stackoverflow.com/questions/12157646/how-to-render-offscreen-on-opengl

It seems to me the "figure visible off" should have a work-around because there otherwise is a functioning OpenGL window environment.  But in the case of generating documentation, I'm assuming folks want to use open GL and no external OpenGL windowing.

How about some version of Octave octave-os (off-screen) that doesn't link in -lGL but links in -lOSMesa that can be used for documentation generation?

Dan Sebald <sebald>
Wed 11 May 2016 08:48:28 PM UTC, comment #88: 

What exactly do you mean by "trying the GLEW route"?

What modifications did you make to the program or the way it is linked?

John W. Eaton <jwe>
Group administrator
Wed 11 May 2016 08:35:47 PM UTC, comment #87: 

I've got it: -lfltk -lfltk_gl

Well, I'm trying the GLEW route and right now I'm basically trying glewInit() after each of the context creations:


GLEW is fine.
GL_DEPTH_BITS: 24
GL_STENCIL_BITS: 0
GLEW init failed: Missing GL version
GL_DEPTH_BITS: -597588432
GL_STENCIL_BITS: 32764


Here's a link to what might be an explanation for the missing GL version:

http://stackoverflow.com/questions/23451435/glewinit-crashing-segfault-after-creating-osmesa-off-screen-mesa-context

Raises more questions than answers.

Dan Sebald <sebald>
Wed 11 May 2016 08:34:48 PM UTC, comment #86: 

I compile the second example with


g++ osmesa-fltk-foo.cc -lfltk_gl -lfltk -lGL -lOSMesa


John W. Eaton <jwe>
Group administrator
Wed 11 May 2016 08:26:23 PM UTC, comment #85: 

What are the link flags for FLTK?

Dan Sebald <sebald>
Wed 11 May 2016 07:51:14 PM UTC, comment #84: 

I'm attaching another version of the test program that first draws an X in an FLTK window, then initializes the OSMesa context.  It works fine for me when linked with Mesa libs (GL and OSMesa), but not when linked with the nvida OpenGL lib.

If you can fix this program so that it works with the nvidia OpenGL library, that would be great.


(file #37132)

John W. Eaton <jwe>
Group administrator
Wed 11 May 2016 07:39:17 PM UTC, comment #83: 

Mangling the mesa symbols won't help because other libraries that we use call OpenGL functions without using the mangled names.

John W. Eaton <jwe>
Group administrator
Wed 11 May 2016 07:33:13 PM UTC, comment #82: 

Putting a couple references here simply to not lose track of them:

http://osdir.com/ml/lang.j.beta/2008-02/msg00091.html

https://sourceforge.net/p/mesa3d/mailman/message/24583539/

I'll see if the use of glew helps in some way.  Maybe it controls which library function calls are made from.

Has anyone tried the Mesa mangling suggested in the link above?  Or would that mean recompiling libOSMesa.so to make the function references non-conflicting?

Dan Sebald <sebald>
Wed 11 May 2016 06:30:49 PM UTC, comment #81: 

Your sample program is exhibiting the same problem with invalid context.  I run this and see nonsensical numbers as well.  If I make the change:


--- osmesa-foo.cc        2016-05-11 12:47:27.675647015 -0500
+++ osmesa-foo-mod.cc        2016-05-11 13:03:55.287656681 -0500
@@ -31,7 +31,7 @@
   if (! OSMesaMakeCurrent (ctx, buffer, GL_UNSIGNED_BYTE, Width, Height))
     error ("__osmesa_print__: OSMesaMakeCurrent failed!");

-  GLint z, s;
+  GLint z=0, s=0;
   glGetIntegerv (GL_DEPTH_BITS, &z);
   glGetIntegerv (GL_STENCIL_BITS, &s);


I see


GL_DEPTH_BITS: 0
GL_STENCIL_BITS: 0


It's just that in the more complicated Octave/multi-thread setting we get a seg fault rather than "no action".

But your program could be a good debugging environment because it compiles quickly and may give more traceable debugging.

Either OSMesaCreateContextExt() is not working properly, even though the return value is telling us it is.  Or, the context is constructed correctly and the switch OSMesaMakeCurrent() is not correct.  If I had to guess, I say the former (i.e., creating the context) is what fails.

The thing I'm wondering about is how the OpenGL environment is initialized, or if it needs to be done at all.  The OpenGL documentation is very vague on this saying that it is system dependent and suggesting that we should just use a window manager (e.g., Qt?) which will have done the necessary work.

In that regard, is there something that needs to be done at the start of this sample program (call some function, include some library)?

For example, take a look at this example where someone tries to call glGetIntegerv() without having even created a context:

http://stackoverflow.com/questions/6594214/glgetintegerv-returning-garbage-value

The person then adds some "glut" type of code at the front which does the context creation (apparently) for a window.  There is some magic going on there which I don't fully comprehend yet.  Is there some type of initialization that needs to be done for the nVidia OpenGL library?

Dan Sebald <sebald>
Wed 11 May 2016 05:40:05 PM UTC, comment #80: 

I don't think this is about threads.  As far as I can tell, the problem is that nvidia's OpenGL library doesn't play well with the OSMesa library.

Please try the attached very simple program.  No threads.  Just two calls to GL functions after setting up an OSMesa context.

I compiled with


g++ osmesa-foo.cc -lGL -lOSMesa


On a system with the Mesa OpenGL libraries, I see


GL_DEPTH_BITS: 16
GL_STENCIL_BITS: 0


as expected.

On the same system, after installing the nvidia OpenGL library (as a dependency of the Debian nvidia-legacy-340xx-driver package) I see


GL_DEPTH_BITS: 0
GL_STENCIL_BITS: 4196832


Is there something wrong with the example program?


(file #37131)

John W. Eaton <jwe>
Group administrator
Wed 11 May 2016 04:17:53 PM UTC, comment #79: 

A DC is a device context:

http://stackoverflow.com/questions/878452/how-do-opengl-contexts-and-device-contexts-work#comment686293_878502

"The threading issue is different - when you make a DC, you need to always use that thread for all calls into that DC. In general, this means one graphics/rendering thread per device context (ie: per window). – Reed Copsey May 18 '09 at 18:39"

Dan Sebald <sebald>
Wed 11 May 2016 08:20:02 AM UTC, comment #78: 

Could someone who better understands the rendering flow setup, thread-wise, summarize the threads in which osmesa_print, gl2ps_render, screen display happen?

I've experimented with trying to use the render-buffer extensions in place of osMesa (had to link in GLEW) and I end up with a similar behavior for nVidia OpenGL library, i.e., a call to any of the glXyzExt routines immediately seg faults.

First, let me point out that this behavior, i.e., crashing for any of the OpenGL functions, sounds like it may be typical of OpenGL with no current context.  So, my guess is that contrary to the OSMesaMakeCurrent() routine returning OK, the nVidia library routine may actually not be setting a current context.

The reason I ask about threads is because:

1) The osmesa demos look like a single-threaded process.
2) We know that Qt only allows graphics in the single thread.
3) Octave appears to not be the one initializing the OpenGL interface.

Read this short description of the current context:

https://www.opengl.org/wiki/OpenGL_Context

It explains that multiple contexts can write to the same window (presumably from different threads), but a context can be current in only one thread.

Perhaps the issue with nVidia OpenGL library is that some configuration needs to be done to make the non-main Qt thread accept a context.  It could be that the non-nVidia library isn't so stringent on separate thread configuration.  The problem here, is that Qt is the code initializing the OpenGL environment.  If Qt only allows graphics in the main thread, maybe it doesn't concern itself with how OpenGL is configured in the other threads--then when Octave tries to use OpenGL in the non-main Qt thread, OpenGL fails.

Could it be an extra step needs to be done to make nVidia's OpenGL function properly in the thread that _osmesa_print_ is running in?  Does that make sense?

https://www.opengl.org/wiki/Getting_Started#Initialization

Dan Sebald <sebald>
Mon 09 May 2016 06:30:40 PM UTC, comment #77: 

I meant to finish the previous comment with:

But at least this can be used as a debugging aid when trying to diagnose why someone is having trouble with OpenGL graphics.  Now we can ask people to generate a figure and look at these properties.

John W. Eaton <jwe>
Group administrator
Mon 09 May 2016 06:28:52 PM UTC, comment #76: 

I don't think it is a thread issue.  I think it happens because the nvidia libGL doesn't know anything about the context that osmesa creates, or they are simply incompatible because they are not stored internally in the same way.  So mixing the nvidia libGL with libOSMesa just isn't likely to work.

If we could somehow detect that the nvidia library is linked with Octave, then we could disable _osmesa_print_.  But I don't know how to do that.

I checked in the following change so that it is possible to get some info about what OpenGL library was used to render a given figure:

http://hg.savannah.gnu.org/hgweb/octave/rev/1449e3b98941

But this feature has some limitations.  The info is not available until after something is actually drawn because the glGetString function requires a valid OpenGL context.  So things like


f = figure (); get (f, '__gl_version__')


may not return useful info because there may not be a call to draw the figure before the get function is called.

Similarly, for invisible figures the properties are not set until after printing:


>> f = figure ('visible', 'off')
f =  1
>> get (f, '__gl_version__')
ans =
>> sombrero
>> get (f, '__gl_version__')
ans =
>> print sombrero.pdf
>> get (f, '__gl_version__')
ans = 2.1 Mesa 11.1.3


But at least this can be used

John W. Eaton <jwe>
Group administrator
Wed 04 May 2016 05:58:24 PM UTC, comment #75: 

This is such a PITA.  It is possible that this is a thread issue.  If the OpenGL context was created in one thread, it might not be available to the other thread where Octave is running.  When you call glGetIntegerv it probably tries to look for the configuration value at an offset from where the context is located in memory.  If the context is 0 in the current thread then this could lead to the segfault.

Rik <rik5>
Group administrator
Wed 04 May 2016 05:36:18 PM UTC, comment #74: 

That agrees with the backtrace in the original post and followup comments, so no change in that regard.

Just adding a note that the segfault occurs in building the plots for the manual also, as reported in bug #45719 (now marked as a duplicate) and reported multiple times on the mailing list.

Building Octave with --without-OSMesa should avoid most of this drama for users of the proprietary nvidia toolkit, of course you will not be able to print figures with the "visible" property set to "off" unless you use the gnuplot toolkit.

See bug #44979 for a proposal to move the current configure detection of OSMesa into a runtime detection (which would have to be further improved to avoid the conflict with nvidia as reported in this bug).

Mike Miller <mtmiller>
Group Member
Wed 04 May 2016 05:19:00 PM UTC, comment #73: 

And, with the nvidia drivers installed, /usr/lib/x86_64-linux-gnu/libGL.so.1 ultimately points to /usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libGL.so.340.96, so the crash is happening inside the nvidia OpenGL implementation.

So, how can the following cause a segfault?


  GLint z, s;
  glGetIntegerv (GL_DEPTH_BITS, &z);


John W. Eaton <jwe>
Group administrator
Wed 04 May 2016 05:03:15 PM UTC, comment #72: 

For me, when doing


figure visible off
sombrero
print invisible.pdf


with nvidia drivers installed, Octave is crashing here:


#0  0x00007f82571947e9 in glGetIntegerv ()
   from /usr/lib/x86_64-linux-gnu/libGL.so.1
#1  0x00007f824778df76 in F__osmesa_print__ (args=...)
    at /home/jwe/src/octave/libinterp/dldfcn/__osmesa_print__.cc:135


This crash does not happen for me if I use the nouveau driver.

John W. Eaton <jwe>
Group administrator
Mon 14 Mar 2016 10:08:48 AM UTC, comment #71: 

Still there in 4.0.1-rc4

  libinterp/dldfcn/__osmesa_print__.cc-tst ....................panic: Segmentation fault -- stopping myself...
octave exited with signal 11

LD_PRELOAD=/usr/lib64/libGL.so make check
  libinterp/corefcn/givens.cc-tst ............................. PASS      6/6
  libinterp/corefcn/graphics.cc-tst ...........................libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
...
 PASS     38/38
  PASS     12999
  FAIL         0
  XFAIL       25
  SKIPPED     77


ederag <ederag>
Tue 19 Jan 2016 11:46:07 AM UTC, comment #70: 

Still there in 4.0.1-rc3

make check
  libinterp/dldfcn/__osmesa_print__.cc-tst ....................panic: Segmentation fault -- stopping myself...
octave exited with signal 11

LD_PRELOAD=/usr/lib64/libGL.so make check
  libinterp/corefcn/graphics.cc-tst ...........................libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
...
  PASS     12935
  FAIL         0
  XFAIL       25
  SKIPPED     77


ederag <ederag>
Sun 13 Dec 2015 05:51:38 PM UTC, comment #69: 

The link isn't helping because the problme is not witht he nvidia drivers but with mesa

This seems more related
https://answers.launchpad.net/ubuntu/+source/xorg-lts-transitional/+question/259177

This trick worked before but not anymore. there seems ot be something broken in libosmesa6 in Ubuntu 15.10

export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGL.so
export LIBGL_DEBUG=verbose
glxgears

libGL: screen 0 does not appear to be DRI2 capable
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
libGL: Can't open configuration file /home/juanpi/.drirc: No such file or directory.
libGL: Can't open configuration file /home/juanpi/.drirc: No such file or directory.
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  154 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  35
  Current serial number in output stream:  37


Juan Pablo Carbajal <juanpi>
Group Member
Fri 11 Dec 2015 11:20:29 PM UTC, comment #68: 
Avinoam Kalma <avinoam>
Group Member
Fri 11 Dec 2015 09:10:12 PM UTC, comment #67: 

Still there in 4.0.1-rc1

make check
  libinterp/dldfcn/__osmesa_print__.cc-tst ....................panic: Segmentation fault -- stopping myself...
octave exited with signal 11

LD_PRELOAD=/usr/lib64/libGL.so make check
  libinterp/corefcn/graphics.cc-tst ...........................libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
...
  PASS     12917
  FAIL         0
  XFAIL       14
  SKIPPED     77


ederag <ederag>
Sat 03 Oct 2015 11:40:15 PM UTC, comment #66: 

@Andreas Weber,
I do not know for Juan, but on my machine yes,
osdemo runs fine, although the nvidia drivers are used

ldd osdemo | grep libGL
libGLEW.so.1.10 => /usr/lib64/libGLEW.so.1.10 (0x00007f19280c0000)
libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00007f1927e40000)
libGL.so.1 => /usr/X11R6/lib64/libGL.so.1 (0x00007f1927af4000)

These are really the nvidia drivers:
/usr/X11R6/lib64/libGL.so.1 -> libGL.so.352.41

The mesa drivers are in /usr/lib64/libGL.so

ederag <ederag>
Sun 09 Aug 2015 06:25:40 PM UTC, comment #65: 

@Juan: Are you sure the Nvidia libGL.so gets loaded and not the mesa one?

Andreas Weber <andy1978>
Group Member
Sun 09 Aug 2015 05:43:19 PM UTC, comment #64: 

Andreas,

What do you mean they do not work with Nvidia drivers. Examples form the OSmesa code work perfectly with my Nvidia drivers.

Juan Pablo Carbajal <juanpi>
Group Member
Sat 08 Aug 2015 09:35:50 AM UTC, comment #63: 

I remove Ubuntu from title because this affects all distros, not only ubuntu. See bug #45719 for a report on arch.

Until now the easiest workaround is to install nouveau drivers or use the LD_PRELOAD from comment #57.

Since the propriatary Nvidias drivers can't work with OSMesa per design we should detect if Nvidia drivers are loaded on runtime and disable OSMesa in this case.

Andreas Weber <andy1978>
Group Member
Tue 02 Jun 2015 04:36:03 PM UTC, comment #62: 

Retagging release from 4.0.0-rc1 to 4.0.0.

John W. Eaton <jwe>
Group administrator
Sun 31 May 2015 11:10:29 AM UTC, comment #61: 

I just tried building from the 4.0.0 release (actually, two commits after the 4.0.0 tag on the stable branch) on Ubuntu 14.10 32 bits.

The problem is still here, exactly as before.

The LD_PRELOAD trick still works as reported below.

Julien Bect <jbect>
Wed 20 May 2015 03:37:27 PM UTC, comment #60: 

Looking at the warning messages,


[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called


made me think of bug #40343 which is about calling XInitThreads before starting the GUI in order for Xlib to be thread-safe.

Perhaps it is worth trying the code there in addition to the LD_PRELOAD step.  Maybe together the solution is even better.

Rik <rik5>
Group administrator
Mon 18 May 2015 09:12:32 AM UTC, comment #59: 

It also works here:

Ubuntu vivid, nvidia-346


Juan Pablo Carbajal <juanpi>
Group Member
Sat 16 May 2015 05:26:00 PM UTC, comment #58: 

Yes it works, both with FLTK and with Qt!

With Qt I get the same "libGL error" messages as you:

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

but no crash afterwards.

Julien Bect <jbect>
Sat 16 May 2015 04:46:15 PM UTC, comment #57: 

@Julien: Im able to use OSMesa with FLTK if I preload the mesa libGL.so. Can you confirm that this also works for you?


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


my testscript:

graphics_toolkit fltk
figure ("visible", "off")
plot (1:10)
print ("-depsc", "out.eps")


This works with --no-gui, --no-gui-libs and the GUI with FLTK. When using Qt I get


libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
o-num: ../../src/xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
panic: Aborted -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Abgebrochen


Andreas Weber <andy1978>
Group Member
Fri 15 May 2015 06:21:12 AM UTC, comment #56: 

@Andreas: No, I have nvidida-331 (331.113-0ubuntu0.1), installed from Ubuntu's repo (Ubuntu 14.10).

Julien Bect <jbect>
Thu 14 May 2015 07:25:51 PM UTC, comment #55: 

@Julien: Do you also use the proprietary nvidia legacy 304 driver? Using the Nvidia installer or via Debian/Ubuntu repos?

Andreas Weber <andy1978>
Group Member
Sat 09 May 2015 06:59:01 AM UTC, comment #54: 

Just tried building Octave 4.0.rc4 again. The problem is still here:


./run-octave --no-gui

>> test __osmesa_print__.cc
panic: Erreur de segmentation -- stopping myself...
Erreur de segmentation (core dumped)


Julien Bect <jbect>
Thu 09 Apr 2015 06:54:46 PM UTC, comment #53: 

@Rik: Making the OpenGL context current is the responsibility of the underlying toolkit (Qt or FLTK). The toolkit takes care of creating the context and making it current in the current thread, so you can start issuing OpenGL commands. In Qt, you only override QGLWidget::paintGL; as doc says in http://doc.qt.io/qt-4.8/qglwidget.html#paintGL the context has been made current for you. The same system exists for FLTK (as in other UI toolkit).

About the question concerning FLTK and OSMesa, I don't know. Looking at the code, _osmesa__print_ creates its own context and makes it current before issuing other OpenGL commands. I'm not familiar with OSMesa, but I'd expect it to be independent of the toolkit used. My point was that your simple example might not show the same type of error as reported initially in this bug report.

@Andreas: The point is a current context in the current thread. When you use Qt, you create a current context in Qt's eventloop thread, not in octave thread. When you run simple_gl_oct, there is no valid context in octave thread. When you use FLTK, the eventloop is the octave thread, so after the "sombrero" call, there is a current context in the octave thread, the one that was used to plot the figure.

Michael Goffioul <goffioul>
Thu 09 Apr 2015 06:38:49 PM UTC, comment #52: 

@Michael: I always run "sombrero" before testing, shouldn't create this a valid context? Do you think the output below is due to a threading problem?

With Riks patch I get a segfault with qt, fltk runs fine:


>> octave_config_info.features.OSMESA
ans = 0
>> graphics_toolkit qt
>> sombrero
>> simple_gl_oct

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f9fbe3c4700 (LWP 6939)]
0x00007f9fd66f5569 in glGetIntegerv () from /usr/lib/libGL.so.1
(gdb) bt
#0  0x00007f9fd66f5569 in glGetIntegerv () from /usr/lib/libGL.so.1
#1  0x00007f9fdb8f8c49 in Fsimple_gl_oct (args=...)
    at ../../octave-src/libinterp/corefcn/simple_gl_oct.cc:18

>> octave_config_info.features.OSMESA
ans = 0
>> graphics_toolkit fltk
>> sombrero
>> simple_gl_oct
GL_DEPTH_BITS = 24
ans =  24


Same with FLTK


>> octave_config_info.features.OSMESA
ans = 0
>> graphics_toolkit fltk
>> sombrero
>> simple_gl_oct
GL_DEPTH_BITS = 24
ans =  24


Andreas Weber <andy1978>
Group Member
Thu 09 Apr 2015 06:37:56 PM UTC, comment #51: 

@Michael: How are we accomplishing things now?  The code in gl-render.cc has init_gl_context which sets up the context and also does the same sort of calls to glGetIntegerv that are causing a segfault.  I can't easily trace how this function is being called from the Octave thread versus the Qt thread.

This does open up another testing line.  If this is about threading and FLTK is within Octave's thread then will this work?


/run-octave -f --no-gui
graphics_toolkit fltk
sombrero
set (gcf, "visible", "off")
__osmesa_print__ (gcf, "tst.eps", "eps")



Rik <rik5>
Group administrator
Thu 09 Apr 2015 05:58:04 PM UTC, comment #50: 

I think what this simple example demonstrates is that one should not call any OpenGL function when there's no OpenGL current context in the current thread. Because of no existing current context, you're accessing garbage memory.

This is different in FLTK, because drawing occurs synchronously in the octave thread, so there is an OpenGL current context.

Michael Goffioul <goffioul>
Thu 09 Apr 2015 05:24:03 PM UTC, comment #49: 

Thanks for testing.  I think Octave must be doing something wrong in the interaction with Qt and OpenGL.  It sure looks like when we call glGetInterv we are sampling a random memory location.  Sometimes this just gives garbage data, like 32,550.  And at other times the memory location is outside the memory range allocated to the process and the kernel intercepts the access and produces a segfault.


Rik <rik5>
Group administrator
Thu 09 Apr 2015 05:16:28 PM UTC, comment #48: 

after applying your patch:

patch -p1 < nvidia.cset
patching file libinterp/corefcn/module.mk
patching file libinterp/corefcn/simple_gl_oct.cc

aclocal
automake

./configure...
make
make install

octave-4.0.0-rc2 --no-gui

graphics_toolkit fltk
plot (1:10)
simple_gl_oct
GL_DEPTH_BITS = 24
ans =  24

close all

graphics_toolkit qt
plot (1:10)
simple_gl_oct
GL_DEPTH_BITS = 32550
ans =  32550


but in a new octave session
octave-4.0.0-rc2 --no-gui

graphics_toolkit qt
>> plot (1:10)
>> simple_gl_oct
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Segmentation fault


ederag <ederag>
Thu 09 Apr 2015 04:18:01 PM UTC, comment #47: 

Thanks Juan.

I'm attaching a patch that builds the simple_gl_oct function into core Octave rather than having it as a dynamically linked function.  Somebody with an Nvidia driver can apply it, compile, and test as shown below.

What I notice is that I get strange results for the Qt toolkit even without the Nvidia driver.  This makes me think that maybe there is something else Octave is not doing when it initializes OpenGL through Qt.

See below for a series of test commands and the results on my computer.


graphics_toolkit qt
plot (1:10)
simple_gl_oct
ans =  32610
close all
graphics_toolkit fltk
plot (1:10)
simple_gl_oct
ans =  24


24 makes sense, 32610 does not.



(file #33615)

Rik <rik5>
Group administrator
Thu 09 Apr 2015 07:20:27 AM UTC, comment #46: 

Hi Rik,

I tried your instructions



 ./octave-cli-4.0.0-rc2 -f
>> sombrero
>> __osmesa_print__ (1)
error: __osmesa_print__: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?
error: octave_base_value::double_value (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::matrix_value(): wrong type argument '<unknown type>'
error: octave_base_value::matrix_value(): wrong type argument '<unknown type>'


At least there is no segfault! :)
The segfault still occurs if I do the same with ./run-octave

Juan Pablo Carbajal <juanpi>
Group Member
Wed 08 Apr 2015 11:10:38 PM UTC, comment #45: 

@Andreas: Does ordinary plotting in core Octave work with the NVidia drivers?

I notice, obviously, that both _osmesa_print_.cc and your simple example are dynamically loaded.  Maybe there are compile/linker flags that we are not setting correctly?

The first two items of Nvidia's known problems list are


OpenGL and dlopen()

    There are some issues with older versions of the glibc dynamic loader (e.g., the version that shipped with Red Hat Linux 7.2) and applications such as Quake3 and Radiant, that use dlopen(). See Chapter 7, Frequently Asked Questions for more details.

Interaction with pthreads

    Single-threaded applications that use dlopen() to load NVIDIA's libGL library, and then use dlopen() to load any other library that is linked against libpthread will crash in libGL. This does not happen in NVIDIA's new ELF TLS OpenGL libraries (see Chapter 5, Listing of Installed Components for a description of the ELF TLS OpenGL libraries). Possible workarounds for this problem are:

      1)  Load the library that is linked with libpthread before loading libGL.

      2)  Link the application with libpthread.


I can't say whether your system has an old glibc.  But for pthreads, everything seems okay.  When I do 'make clean; make V=1' I see that the lines for core Octave have -pthread and so do the dynamically loaded modules in the dldfcn/ directory.

Maybe, there is a problem with the fact that octave is itself just a small executable that exec's itself out of the way.  Instead of ./run-octave you could do 'make install' and then try directly running octave-cli-4.0.0-rc2 and your test program.

Rik <rik5>
Group administrator
Wed 08 Apr 2015 09:07:57 PM UTC, comment #44: 

After installing a "NVIDIA Corporation G71 [Quadro FX 1500] (rev a1)" with the proprietary driver "NVIDIA-Linux-x86_64-304.125.run" I'm able to reproduce this segfault.

But I don't think this is related to OSMesa. I compiled Octave without OSMesa and build the simple attached OCT file (basically just one glGetIntegerv call) and also get the SIGSEGV in libGL.so

(file #33602)

Andreas Weber <andy1978>
Group Member
Sun 29 Mar 2015 02:38:34 PM UTC, comment #43: 

Could this be a problem (Interaction with pthreads)?
http://us.download.nvidia.com/XFree86/Linux-x86_64/340.24/README/knownissues.html

Anonymous
Sat 28 Mar 2015 11:28:15 PM UTC, comment #42: 

The crash occurs also with octave-4.0.0-rc2, on openSUSE 13.2 with the proprietary nvidia driver.

./run-octave -g --no-gui

test _osmesa_print_.cc-tst

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd5eee700 (LWP 23538)]
0x00007ffff1a177e9 in glGetIntegerv () from /usr/X11R6/lib64/libGL.so.1

So it is indeed using the nvidia libGL.so
(The mesa libGL are in /usr/lib64)


building mesa_demos work, exactly as in comment #12;

osdemo is using the nvidia libGL too:

ldd osdemo | grep libGL
        libGLEW.so.1.10 => /usr/lib64/libGLEW.so.1.10 (0x00007f19280c0000)
        libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00007f1927e40000)
        libGL.so.1 => /usr/X11R6/lib64/libGL.so.1 (0x00007f1927af4000)

ederag <ederag>
Wed 18 Mar 2015 09:40:54 AM UTC, comment #41: 

The log of make octave was removed form the upload. Here it is

Juan Pablo Carbajal <juanpi>
Group Member
Mon 16 Mar 2015 11:44:44 PM UTC, comment #40: 

Here are the logs.

In the mesa log grep for "osdemo"

(file #33373)

Juan Pablo Carbajal <juanpi>
Group Member
Mon 16 Mar 2015 10:48:42 PM UTC, comment #39: 

@Juan: Can you include the log from running make?  I want to see the order of the -L flags when _octave_mesa_.cc is getting compiled.  From the segfault backtrace it is clearly getting linked against the Nvidia libGL which is probably not right.

Can you also get the log from running make on the osdemos?  That will tell us the correct order of flags.


Rik <rik5>
Group administrator
Mon 16 Mar 2015 08:57:36 PM UTC, comment #38: 

Ok,

JWE gave me new valid instructions to debug octave using gdb.
The instructions in comment #37 do not work for me anymore.

After compilation as indicated in comment #37 run octave


sudo ./run-octave -f --no-gui


From within Octave run


system (sprintf ('gnome-terminal --command "gdb --init-eval-command=c -p %d" &', getpid ()))


This will start gdb in another terminal.
We need to set the log (to record the backtrace) by typing in the gdb terminal


set loggin on


After it loads the symbols you get some TTOUT due to some missing files.
Run

continue

in gdb until the octave prompt comes back to life.

Then run the octave commands given in comment #37.

The output of

bt full
bt

is attached


(file #33370)

Juan Pablo Carbajal <juanpi>
Group Member
Mon 16 Mar 2015 03:03:45 PM UTC, comment #37: 

@Juan: Can you build a version of octave with debugging symbols and minimal optimization and then run the simplified code from comment #33.

Here is what I use for this purpose which happens to assume a tcsh shell:


setenv CFLAGS "-g -O0 -pipe"
setenv CXXFLAGS "${CFLAGS}"
setenv FFLAGS "${CFLAGS}"

./configure --prefix=/usr/local --disable-jit |& tee myconfig.log


Also, when you run make, turn on verbose reporting and record the log.


make V=1 |& tee mymake.log


It may be that the linker flags are not set correctly so that the wrong library is being preferred.

Finally, to run


./run-octave -g -f --no-gui
# at gdb prompt
run
# at octave prompt
sombrero
__osmesa_print__ (1)
# at gdb prompt after segfault
bt


I expect the backtrace to show that it is the glEnable call that leads to the segfault, but I'm wondering if it will give a clue as to which library it is going in to when it fails.


Rik <rik5>
Group administrator
Sun 15 Mar 2015 08:33:20 AM UTC, comment #36: 

Andy,

I am not building with JIT, unless this is active by default. To configure I use no parameter at all.

Juan Pablo Carbajal <juanpi>
Group Member
Sat 14 Mar 2015 05:40:51 PM UTC, comment #35: 

Juan Pablo, have you build Octave using LLVM? This is just a wild guess but if I read http://archive.ubuntu.com/ubuntu/pool/main/m/mesa/mesa_10.3.0-0ubuntu3.dsc it looks like the libosmesa in Ubuntu 14.10 was built with llvm-3.5. There is a "classic" OSMesa and a gallium llvmpipe state tracker. Can this conflict with the nvidia driver?

If you've built with llvm, can you try a "--disable-jit" built?
Perhaps ypu want to try classic libosmesa (http://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D#Installing_Classic_OSMesa).

Andreas Weber <andy1978>
Group Member
Sat 14 Mar 2015 03:21:16 PM UTC, comment #34: 

Rik,

Thanks again. I had tried this already (see comment #27). Nevertheless, I did as you told and got the following


octave:1> sombrero
octave:2> __osmesa_print__ (gcf)
18c3caa0
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Segmentation fault (core dumped)


Does the pointer tell you something?

Juan Pablo Carbajal <juanpi>
Group Member
Sat 14 Mar 2015 03:07:28 PM UTC, comment #33: 

@Juan: Could you try the minimal__osmesa_print__.cc file I'm attaching?  Copy it to the libinter/dldfcn directory and rename it to _osmesa_print_.cc.

It avoids using OCTAVE_LOCAL_BUFFER and directly calls malloc to get a buffer.  It also prints out the buffer pointer.  According to OSMESA this must be 4-byte aligned.  Maybe OCTAVE_LOCAL_BUFFER is not doing that.

To test:


sombrero
__osmesa_print__ (gcf)



(file #33343)

Rik <rik5>
Group administrator
Sat 14 Mar 2015 09:10:28 AM UTC, comment #32: 

Hi Andreas,

Any call to gl* functions causes a segfault (in the Octave code, not in the mesa demos). In the code attached in comment #30, I have removed everything except the initialization part of the function and then call the innocent glEnable (GL_DEPTH_TEST); to get an segmentation fault. Replacing that with any other gl* function will also produce the segfault.

It seems that the segfault has nothing to do with the opengl_renderer and/or glps_renderer instantiation.

Juan Pablo Carbajal <juanpi>
Group Member
Sat 14 Mar 2015 08:43:22 AM UTC, comment #31: 

Hi Juan Pablo, you get a segfault even if you remove the opengl_renderer and/or glps_renderer instantiation and the call of the draw method?

Andreas Weber <andy1978>
Group Member
Fri 13 Mar 2015 12:56:03 PM UTC, comment #30: 

Hello Andy,

I have tried what you suggested and some more extreme things.

Nothing works, whenever I call any gl* function I get a segfault.

I have erased the whole function _osmesa_print_.cc  from line 273 and below (after the allocation and setting the environment ctx as current) and just called glEnable (GL_DEPTH_TEST); and I get a segfault. Code attached

It seems that the problem is not in this function, but on the allocation part.

I haven't managed to get the demo running in octave by embedding it into the DLD function. I will keep trying.





(file #33334)

Juan Pablo Carbajal <juanpi>
Group Member
Fri 13 Mar 2015 11:17:02 AM UTC, comment #29: 

@Rik, I was wrong when I said that I couldn't execute

test __osmesa_print__.cc

The savannah system has problems managing the character

_

when it is written as normal text instead of in a verbatim environment, so when I copy and paste your instructions I got the "not exist in path" message.

Well, I still obtain


./run-octave -f --no-gui
octave:1> test __osmesa_print__.cc
panic: Segmentation fault -- stopping myself...
Segmentation fault


José Luis García Pallero <jgpallero>
Fri 13 Mar 2015 10:57:39 AM UTC, comment #28: 

Juan Pablo,

"test osmesa_print.cc" uses two different pathes: One where gl2ps is invoked and the other wehere an image is returned. I think it would help if you try them separately in octave, for example


sombrero ();
__osmesa_print__ (gcf, "out.svg", "svg");


And


sombrero ();
img = __osmesa_print__ (gcf);
imshow (img);


Can you then please comment the "rend.draw (fobj);" call in _osmesa_print_.cc and test again? If the segfault is caused from the "draw" method, can you please copy the render_image() functions from the demos (comment #12) and see if this works and you see the torrus, cone and sphere?

Thanks, Andy



Andreas Weber <andy1978>
Group Member
Fri 13 Mar 2015 12:27:33 AM UTC, comment #27: 

Rik,

Thanks for the instructions.
I tried them in my system as well. I still get the segmentation fault

> test _osmesa_print_.cc

panic: Segmentation fault -- stopping myself...
Segmentation fault (core dumped)

I tried the modification in the mercurial repository as well and got the same result.

I dive into the code and compare it with the demo (see comment #12) that runs on my computer without a problem.

There is no need to Enable the GL_*TEST to retrieve the values of GL_DEPTH_BITS, GL_STENCIL_BITS and GL_ACCUM_RED_BITS.

And I do not think it is a good idea to disable them before doing the actual rendering.

I checked that replacing the call to OCTAVE_LOCAL_BUFFER with the code given in the demo gives the same result.
I also tried to do the retrieval of the values z and s in a local scope, as in the demo... nothing.

If you comment out all this testing part, then the segmentation fault appears later.

I guess the segmentation fault has nothing to do with this chuck of code, but it is something in the configuration of the render that triggers this issue.

We might be barking at the wrong tree.

Juan Pablo Carbajal <juanpi>
Group Member
Thu 12 Mar 2015 08:20:28 PM UTC, comment #26: 

With run-octave you should be able to use


test __osmesa_print__.cc


What happens if you type


which __osmesa_print__


It should be


.../octave-4.0.0-rc1/libinterp/dldfcn/__osmesa_print__.oct



Rik <rik5>
Group administrator
Thu 12 Mar 2015 06:33:53 PM UTC, comment #25: 

@Rik, I suppose you mean test osmesa_print instead of test osmesa_print.cc (which results in ????? osmesa_print.cc does not exist in path)

With test osmesa_print I obtain again a segmentation fault (and also running make check)

José Luis García Pallero <jgpallero>
Thu 12 Mar 2015 06:23:15 PM UTC, comment #24: 

@Jose: I'm attaching a patch to test the idea of enabling the feature before testing for it.  Can you apply, rebuild, and then see if Octave still segfaults?

Instructions:

1) download glenable.diff
2) From top-level Octave source directory,
   cd libinterp/dldfcn
3) patch < glenable.diff
4) cd ../../
5) make
6) ./run-octave -f --no-gui
7) test _osmesa_print_.cc

(file #33319)

Rik <rik5>
Group administrator
Thu 12 Mar 2015 05:52:20 PM UTC, comment #23: 

@Rik, I'm using the 4.0.0-rc1 tarball

José Luis García Pallero <jgpallero>
Thu 12 Mar 2015 05:47:43 PM UTC, comment #22: 

@Jose: Are you using Mercurial sources or the 4.0.0-rc1 tarball?

Actually, what I want to know is what is line 160 in dldfcn/__osmesa_print__.cc?

Is it


glGetIntegerv (GL_STENCIL_BITS, &s);


The depth buffer and stencil buffer are optional.  It may be that we need to initialize them first before querying.  For example, calling


glEnable (GL_DEPTH_TEST)
glEnable (GL_STENCIL_TEST)


before the glGetIntegerv.  On the other hand, all of this code is just doing version testing on OSMESA


  // Test for a bug in OSMesa with version < 9.0
  //
  // Unfortunately the macros OSMESA_MAJOR_VERSION and OSMESA_MINOR_VERSION
  // weren't updated between many releases and can't be used for detection.
  // (Version 8.0 until 9.1.4 all return MAJOR 6, MINOR 5)
  GLint z, s;
  glGetIntegerv (GL_DEPTH_BITS, &z);
  glGetIntegerv (GL_STENCIL_BITS, &s);
  if (z != 16 || s != 0)
    error ("__osmesa_print__: Depth and stencil doesn't match,"
           " are you sure you are using OSMesa >= 9.0?");


Is there some other way we could do this testing that would avoid all of?

Rik <rik5>
Group administrator
Thu 12 Mar 2015 05:18:10 PM UTC, comment #21: 

Rik, thank you for the explanation

The output for test _osmesa_print_.cc-tst is


octave:1> test __osmesa_print__.cc-tst

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd6756700 (LWP 14291)]
0x00007fffc9ada9a2 in ?? () from /usr/lib/x86_64-linux-gnu/libOSMesa.so.8


The output for bt in gdb is


(gdb) bt
#0  0x00007fffc9ada9a2 in ?? () from /usr/lib/x86_64-linux-gnu/libOSMesa.so.8
#1  0x00007fffc9adc65a in ?? () from /usr/lib/x86_64-linux-gnu/libOSMesa.so.8
#2  0x00007fffc9fbf6f2 in F__osmesa_print__ (args=...) at dldfcn/__osmesa_print__.cc:160
#3  0x00007ffff6ce41f5 in octave_builtin::do_multi_index_op (this=0x7fffd0691f50, nargout=0, args=..., lvalue_list=<optimized out>) at octave-value/ov-builtin.cc:131
Python Exception <type 'exceptions.ValueError'> Cannot find type const std::list<octave_value_list, std::allocator<octave_value_list> >::_Node:
#4  0x00007ffff6ce28f4 in octave_builtin::subsref (this=<optimized out>, type="(", idx=std::list, nargout=0, lvalue_list=lvalue_list@entry=0x0) at octave-value/ov-builtin.cc:63
#5  0x00007ffff6ce38cc in octave_builtin::subsref (this=<optimized out>, type=..., idx=..., nargout=<optimized out>) at octave-value/ov-builtin.cc:46
#6  0x00007ffff6de2bf9 in octave_value::subsref (this=<optimized out>, type=..., idx=..., nargout=<optimized out>) at octave-value/ov.cc:1302
Python Exception <type 'exceptions.ValueError'> Cannot find type const std::list<octave_value_list, std::allocator<octave_value_list> >::_Node:
#7  0x00007ffff6de2c75 in octave_value::subsref (this=this@entry=0x7fffd6753020, type="(", idx=std::list, nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0)
    at octave-value/ov.cc:1313
#8  0x00007ffff6e6adbd in tree_index_expression::rvalue (this=this@entry=0x7fffd04908c0, nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0) at parse-tree/pt-idx.cc:436
#9  0x00007ffff6e6bc33 in rvalue (nargout=0, this=0x7fffd04908c0) at parse-tree/pt-idx.cc:284
#10 tree_index_expression::rvalue1 (this=0x7fffd04908c0, nargout=0) at parse-tree/pt-idx.cc:466
#11 0x00007ffff6e505ad in tree_evaluator::visit_statement (this=0x7ffff79695a0 <std_evaluator>, stmt=...) at parse-tree/pt-eval.cc:744
#12 0x00007ffff6e4fbe1 in tree_evaluator::visit_statement_list (this=0x7ffff79695a0 <std_evaluator>, lst=...) at parse-tree/pt-eval.cc:794
#13 0x00007ffff6ddcbf3 in octave_user_function::do_multi_index_op (this=0x7fffd0561170, nargout=0, _args=..., lvalue_list=0x0) at octave-value/ov-usr-fcn.cc:626
Python Exception <type 'exceptions.ValueError'> Cannot find type const std::list<octave_value_list, std::allocator<octave_value_list> >::_Node:
#14 0x00007ffff6dd8158 in octave_user_function::subsref (this=0x7fffd0561170, type="(", idx=std::list, nargout=0, lvalue_list=lvalue_list@entry=0x0) at octave-value/ov-usr-fcn.cc:438
#15 0x00007ffff6dd835c in octave_user_function::subsref (this=<optimized out>, type=..., idx=..., nargout=<optimized out>) at octave-value/ov-usr-fcn.cc:421
#16 0x00007ffff6de2bf9 in octave_value::subsref (this=<optimized out>, type=..., idx=..., nargout=<optimized out>) at octave-value/ov.cc:1302
Python Exception <type 'exceptions.ValueError'> Cannot find type const std::list<octave_value_list, std::allocator<octave_value_list> >::_Node:
#17 0x00007ffff6de2c75 in octave_value::subsref (this=this@entry=0x7fffd6753ac0, type="(", idx=std::list, nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0)
    at octave-value/ov.cc:1313
#18 0x00007ffff6e6adbd in tree_index_expression::rvalue (this=<optimized out>, nargout=0, lvalue_list=lvalue_list@entry=0x0) at parse-tree/pt-idx.cc:436
#19 0x00007ffff6e6bd4b in tree_index_expression::rvalue (this=<optimized out>, nargout=<optimized out>) at parse-tree/pt-idx.cc:284
#20 0x00007ffff6ea67cb in eval_string (eval_str=" __test__( );", silent=silent@entry=false, parse_status=@0x7fffd6753fd4: 0, nargout=nargout@entry=0) at parse-tree/oct-parse.yy:4845
#21 0x00007ffff6ea6a9d in eval_string (arg=..., silent=silent@entry=false, parse_status=@0x7fffd6753fd4: 0, nargout=nargout@entry=0) at parse-tree/oct-parse.yy:4898
#22 0x00007ffff6ea7202 in Feval (args=..., nargout=0) at parse-tree/oct-parse.yy:4964
#23 0x00007ffff6ce41f5 in octave_builtin::do_multi_index_op (this=0x7fffd010f8b0, nargout=0, args=..., lvalue_list=<optimized out>) at octave-value/ov-builtin.cc:131
Python Exception <type 'exceptions.ValueError'> Cannot find type const std::list<octave_value_list, std::allocator<octave_value_list> >::_Node:
#24 0x00007ffff6ce28f4 in octave_builtin::subsref (this=<optimized out>, type="(", idx=std::list, nargout=0, lvalue_list=lvalue_list@entry=0x0) at octave-value/ov-builtin.cc:63
#25 0x00007ffff6ce38cc in octave_builtin::subsref (this=<optimized out>, type=..., idx=..., nargout=<optimized out>) at octave-value/ov-builtin.cc:46
#26 0x00007ffff6de2bf9 in octave_value::subsref (this=<optimized out>, type=..., idx=..., nargout=<optimized out>) at octave-value/ov.cc:1302
Python Exception <type 'exceptions.ValueError'> Cannot find type const std::list<octave_value_list, std::allocator<octave_value_list> >::_Node:
#27 0x00007ffff6de2c75 in octave_value::subsref (this=this@entry=0x7fffd6754530, type="(", idx=std::list, nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0)
    at octave-value/ov.cc:1313
#28 0x00007ffff6e6adbd in tree_index_expression::rvalue (this=this@entry=0x7fffd051ad60, nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0) at parse-tree/pt-idx.cc:436
#29 0x00007ffff6e6bc33 in rvalue (nargout=0, this=0x7fffd051ad60) at parse-tree/pt-idx.cc:284
#30 tree_index_expression::rvalue1 (this=0x7fffd051ad60, nargout=0) at parse-tree/pt-idx.cc:466
#31 0x00007ffff6e505ad in tree_evaluator::visit_statement (this=0x7ffff79695a0 <std_evaluator>, stmt=...) at parse-tree/pt-eval.cc:744
#32 0x00007ffff6e4fbe1 in tree_evaluator::visit_statement_list (this=0x7ffff79695a0 <std_evaluator>, lst=...) at parse-tree/pt-eval.cc:794
#33 0x00007ffff6e5052a in tree_evaluator::visit_statement (this=0x7ffff79695a0 <std_evaluator>, stmt=...) at parse-tree/pt-eval.cc:718
#34 0x00007ffff6e4fbe1 in tree_evaluator::visit_statement_list (this=0x7ffff79695a0 <std_evaluator>, lst=...) at parse-tree/pt-eval.cc:794
#35 0x00007ffff6e5123c in tree_evaluator::visit_try_catch_command (this=0x7ffff79695a0 <std_evaluator>, cmd=...) at parse-tree/pt-eval.cc:907
#36 0x00007ffff6e5052a in tree_evaluator::visit_statement (this=0x7ffff79695a0 <std_evaluator>, stmt=...) at parse-tree/pt-eval.cc:718
#37 0x00007ffff6e4fbe1 in tree_evaluator::visit_statement_list (this=0x7ffff79695a0 <std_evaluator>, lst=...) at parse-tree/pt-eval.cc:794
#38 0x00007ffff6e5052a in tree_evaluator::visit_statement (this=0x7ffff79695a0 <std_evaluator>, stmt=...) at parse-tree/pt-eval.cc:718
#39 0x00007ffff6e4fbe1 in tree_evaluator::visit_statement_list (this=0x7ffff79695a0 <std_evaluator>, lst=...) at parse-tree/pt-eval.cc:794
#40 0x00007ffff6e530ee in tree_evaluator::visit_unwind_protect_command (this=0x7ffff79695a0 <std_evaluator>, cmd=...) at parse-tree/pt-eval.cc:1045
#41 0x00007ffff6e5052a in tree_evaluator::visit_statement (this=0x7ffff79695a0 <std_evaluator>, stmt=...) at parse-tree/pt-eval.cc:718
---Type <return> to continue, or q <return> to quit---
#42 0x00007ffff6e4fbe1 in tree_evaluator::visit_statement_list (this=0x7ffff79695a0 <std_evaluator>, lst=...) at parse-tree/pt-eval.cc:794
#43 0x00007ffff6e5240a in tree_evaluator::visit_simple_for_command (this=0x7ffff79695a0 <std_evaluator>, cmd=...) at parse-tree/pt-eval.cc:349
#44 0x00007ffff6e5052a in tree_evaluator::visit_statement (this=0x7ffff79695a0 <std_evaluator>, stmt=...) at parse-tree/pt-eval.cc:718
#45 0x00007ffff6e4fbe1 in tree_evaluator::visit_statement_list (this=0x7ffff79695a0 <std_evaluator>, lst=...) at parse-tree/pt-eval.cc:794
#46 0x00007ffff6ddcbf3 in octave_user_function::do_multi_index_op (this=0x7fffd0531f60, nargout=0, _args=..., lvalue_list=0x0) at octave-value/ov-usr-fcn.cc:626
Python Exception <type 'exceptions.ValueError'> Cannot find type const std::list<octave_value_list, std::allocator<octave_value_list> >::_Node:
#47 0x00007ffff6dd8158 in octave_user_function::subsref (this=0x7fffd0531f60, type="(", idx=std::list, nargout=0, lvalue_list=lvalue_list@entry=0x0) at octave-value/ov-usr-fcn.cc:438
#48 0x00007ffff6dd835c in octave_user_function::subsref (this=<optimized out>, type=..., idx=..., nargout=<optimized out>) at octave-value/ov-usr-fcn.cc:421
#49 0x00007ffff6de2bf9 in octave_value::subsref (this=<optimized out>, type=..., idx=..., nargout=<optimized out>) at octave-value/ov.cc:1302
Python Exception <type 'exceptions.ValueError'> Cannot find type const std::list<octave_value_list, std::allocator<octave_value_list> >::_Node:
#50 0x00007ffff6de2c75 in octave_value::subsref (this=this@entry=0x7fffd6755700, type="(", idx=std::list, nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0)
    at octave-value/ov.cc:1313
#51 0x00007ffff6e6adbd in tree_index_expression::rvalue (this=this@entry=0x7fffd01a9ef0, nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0) at parse-tree/pt-idx.cc:436
#52 0x00007ffff6e6bc33 in rvalue (nargout=0, this=0x7fffd01a9ef0) at parse-tree/pt-idx.cc:284
#53 tree_index_expression::rvalue1 (this=0x7fffd01a9ef0, nargout=0) at parse-tree/pt-idx.cc:466
#54 0x00007ffff6e505ad in tree_evaluator::visit_statement (this=0x7ffff79695a0 <std_evaluator>, stmt=...) at parse-tree/pt-eval.cc:744
#55 0x00007ffff6e4fbe1 in tree_evaluator::visit_statement_list (this=0x7ffff79695a0 <std_evaluator>, lst=...) at parse-tree/pt-eval.cc:794
#56 0x00007ffff73a420d in main_loop () at corefcn/toplev.cc:599
#57 0x00007ffff68c3139 in octave_execute_interpreter () at octave.cc:917
#58 0x00007ffff7a783ec in octave_cli_thread::run (this=0x7fffffffb810) at src/octave-gui.cc:80
#59 0x00007ffff298670f in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#60 0x00007ffff44ed0a4 in start_thread (arg=0x7fffd6756700) at pthread_create.c:309
#61 0x00007ffff422204d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111


José Luis García Pallero <jgpallero>
Thu 12 Mar 2015 05:03:08 PM UTC, comment #20: 

You do want to run


./run-octave -g -f --no-gui


This will start gdb.  At the gdb prompt, type 'run<RETURN>' to start the executable.

Octave will now be running.  Then you can do


test __osmesa_print__.cc-tst


When this segfaults, it will return you to gdb.  Type 'bt<RETURN' to see the stack backtrace.

Rik <rik5>
Group administrator
Thu 12 Mar 2015 12:51:05 PM UTC, comment #19: 

I've done the same steps as in comment #10. First of all, I've invoked Octave as

./run-octave -g --no-gui

but gdb is started instead of octave, so I can't run any octave command. I suppose the correct call in comment #10 is
+verbatin+
./run-octave -d --no-gui
-verbatim-
this starts octave printing on the screen LOTS of info

Then, I execute

test __osmesa_print__.cc-tst

this print on screen again LOTS of info lines, but finally octave breaks with

panic: Segmentation fault -- stopping myself...
Segmentation fault


As I explained in my previous comment, I'm using Debian Sid. I've installed the official NVIDIA driver (*.run file from nvidia.com), but I've changed the GL and GLES libraries links to the Debian libgl1-mesa-swx11, libgl1-mesa-swx11-dev, libgles1-mesa and libgles2-mesa.

topo@geo-w540:~/Desktop/octave-4.0.0-rc1$ ls -l /usr/lib/x86_64-linux-gnu/libGL*
-rw-r--r-- 1 root root 7700082 ene 15 15:02 /usr/lib/x86_64-linux-gnu/libGL.a
lrwxrwxrwx 1 root root      17 mar 12 12:39 /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so -> libGLESv1_CM.so.1
lrwxrwxrwx 1 root root      21 mar 12 12:39 /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1 -> libGLESv1_CM.so.1.1.0
-rw-r--r-- 1 root root   18232 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0
-rwxr-xr-x 1 root root   51096 feb 27 15:24 /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.346.47
lrwxrwxrwx 1 root root      14 mar 12 12:39 /usr/lib/x86_64-linux-gnu/libGLESv2.so -> libGLESv2.so.2
lrwxrwxrwx 1 root root      18 mar 12 12:39 /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 -> libGLESv2.so.2.0.0
-rw-r--r-- 1 root root   26424 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.0.0
-rwxr-xr-x 1 root root   75416 feb 27 15:24 /usr/lib/x86_64-linux-gnu/libGLESv2.so.346.47
lrwxrwxrwx 1 root root      17 nov 22  2013 /usr/lib/x86_64-linux-gnu/libGLEW.so.1.10 -> libGLEW.so.1.10.0
-rw-r--r-- 1 root root  554088 nov 22  2013 /usr/lib/x86_64-linux-gnu/libGLEW.so.1.10.0
-rw-r--r-- 1 root root     671 feb 27 15:24 /usr/lib/x86_64-linux-gnu/libGL.la
lrwxrwxrwx 1 root root      10 mar 12 12:39 /usr/lib/x86_64-linux-gnu/libGL.so -> libGL.so.1
lrwxrwxrwx 1 root root      14 mar 12 12:39 /usr/lib/x86_64-linux-gnu/libGL.so.1 -> libGL.so.1.6.0
-rw-r--r-- 1 root root 4330248 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libGL.so.1.6.0
-rwxr-xr-x 1 root root 1317432 feb 27 15:24 /usr/lib/x86_64-linux-gnu/libGL.so.346.47
-rw-r--r-- 1 root root  901120 sep 19  2013 /usr/lib/x86_64-linux-gnu/libGLU.a
lrwxrwxrwx 1 root root      15 sep 19  2013 /usr/lib/x86_64-linux-gnu/libGLU.so -> libGLU.so.1.3.1
lrwxrwxrwx 1 root root      15 sep 19  2013 /usr/lib/x86_64-linux-gnu/libGLU.so.1 -> libGLU.so.1.3.1
-rw-r--r-- 1 root root  449144 sep 19  2013 /usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1


The OSMesa libraries I've installed are:

topo@geo-w540:~/Desktop/octave-4.0.0-rc1$ ls -l /usr/lib/x86_64-linux-gnu/libOS*
lrwxrwxrwx 1 root root      18 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libOSMesa.so -> libOSMesa.so.8.0.0
lrwxrwxrwx 1 root root      14 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libOSMesa.so.6 -> libOSMesa.so.8
lrwxrwxrwx 1 root root      18 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libOSMesa.so.8 -> libOSMesa.so.8.0.0
-rw-r--r-- 1 root root 3889448 ene 15 15:02 /usr/lib/x86_64-linux-gnu/libOSMesa.so.8.0.0


In this way, I can use the fltk and qt driver for plotting (the function sombrero() works perfectly), but the test _osmesa_print_.cc-tst call fails as I explained

José Luis García Pallero <jgpallero>
Thu 12 Mar 2015 02:55:01 AM UTC, comment #18: 

This seems to imply that it is not related to the Nvidia replacement GL libraries, since you are using the Mesa ones.

José, can you provide a stack trace to confirm that the error is in the Mesa library and not the Nvidia one? See comment #10.

Mike Miller <mtmiller>
Group Member
Tue 10 Mar 2015 02:48:31 PM UTC, comment #17: 

Grrr, I've had written a long comment, but I don't know why it wasn't complete published. I'll try to reproduce it:

--------------

Then, the GL and GLES libraries point to the ones installed with libgl1-mesa-swx11, libgl1-mesa-swx11-dev, libgles1-mesa and libgles2-mesa and I can use FLTK:

+varbatim+
-rw-r--r-- 1 root root 7700082 ene 15 15:02 /usr/lib/x86_64-linux-gnu/libGL.a
lrwxrwxrwx 1 root root      17 mar 10 15:43 /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so -> libGLESv1_CM.so.1
lrwxrwxrwx 1 root root      21 mar 10 15:43 /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1 -> libGLESv1_CM.so.1.1.0
-rw-r--r-- 1 root root   18232 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0
-rwxr-xr-x 1 root root   51096 feb 27 15:24 /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.346.47
lrwxrwxrwx 1 root root      14 mar 10 15:43 /usr/lib/x86_64-linux-gnu/libGLESv2.so -> libGLESv2.so.2
lrwxrwxrwx 1 root root      18 mar 10 15:43 /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 -> libGLESv2.so.2.0.0
-rw-r--r-- 1 root root   26424 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.0.0
-rwxr-xr-x 1 root root   75416 feb 27 15:24 /usr/lib/x86_64-linux-gnu/libGLESv2.so.346.47
-rw-r--r-- 1 root root     671 feb 27 15:24 /usr/lib/x86_64-linux-gnu/libGL.la
lrwxrwxrwx 1 root root      10 mar 10 15:43 /usr/lib/x86_64-linux-gnu/libGL.so -> libGL.so.1
lrwxrwxrwx 1 root root      14 mar 10 15:43 /usr/lib/x86_64-linux-gnu/libGL.so.1 -> libGL.so.1.6.0
-rw-r--r-- 1 root root 4330248 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libGL.so.1.6.0
-rwxr-xr-x 1 root root 1317432 feb 27 15:24 /usr/lib/x86_64-linux-gnu/libGL.so.346.47
-verbatim-

So now I have installed Octave 4.0 and I've installed the osmesa libraries


lrwxrwxrwx 1 root root      18 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libOSMesa.so -> libOSMesa.so.8.0.0
lrwxrwxrwx 1 root root      14 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libOSMesa.so.6 -> libOSMesa.so.8
lrwxrwxrwx 1 root root      18 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libOSMesa.so.8 -> libOSMesa.so.8.0.0
-rw-r--r-- 1 root root 3889448 ene 15 15:02 /usr/lib/x86_64-linux-gnu/libOSMesa.so.8.0.0


Apparently they don't depend on NVIDIA driver, but I obtain the osmesa crash in make check

José Luis García Pallero <jgpallero>
Tue 10 Mar 2015 02:42:05 PM UTC, comment #16: 

I have also problems with NVIDIA and OpenGL. I use Debian Sid and I have a NVIDIA Quadro K2100M in my laptop. I use the NVIDIA driver directly from nvidia.com (not the official Debian package). The principal problem with the GL NVIDIA libraries is that the FLTK drawing doesn't work. But I can fix this issue changing several symbolic links in /usr/lib/x86_64-linux-gnu/. I have installed the packages libgl1-mesa-swx11, libgl1-mesa-swx11-dev, libgles1-mesa and libgles2-mesa. When I install the NVIDIA driver, the original links to GL and GLES libraries are changed to point to the NVIDIA libraries and then FLTK in Octave crash. I use this script in order to restore the links:


#!/bin/bash
cd /usr/lib/x86_64-linux-gnu
rm libGL.so libGL.so.1
rm libGLESv1_CM.so libGLESv1_CM.so.1
rm libGLESv2.so libGLESv2.so.2
ln -s libGL.so.1.6.0 libGL.so.1
ln -s libGL.so.1 libGL.so
ln -s libGLESv1_CM.so.1.1.0 libGLESv1_CM.so.1
ln -s libGLESv1_CM.so.1 libGLESv1_CM.so
ln -s libGLESv2.so.2.0.0 libGLESv2.so.2
ln -s libGLESv2.so.2 libGLESv2.so


Then, the GL and GLES libraries point to the ones installes with libgl1-mesa-swx11, libgl1-mesa-swx11-dev, libgles1-mesa and libgles2-mesa and I can use FLTK:


-rw-r--r-- 1 root root 7700082 ene 15 15:02 /usr/lib/x86_64-linux-gnu/libGL.a
lrwxrwxrwx 1 root root      17 mar 10 09:15 /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so -> libGLESv1_CM.so.1
lrwxrwxrwx 1 root root      21 mar 10 09:15 /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1 -> libGLESv1_CM.so.1.1.0
-rw-r--r-- 1 root root   18232 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0
-rwxr-xr-x 1 root root   51096 feb 27 15:24 /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.346.47
lrwxrwxrwx 1 root root      14 mar 10 09:15 /usr/lib/x86_64-linux-gnu/libGLESv2.so -> libGLESv2.so.2
lrwxrwxrwx 1 root root      18 mar 10 09:15 /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 -> libGLESv2.so.2.0.0
-rw-r--r-- 1 root root   26424 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.0.0
-rwxr-xr-x 1 root root   75416 feb 27 15:24 /usr/lib/x86_64-linux-gnu/libGLESv2.so.346.47
-rw-r--r-- 1 root root     671 feb 27 15:24 /usr/lib/x86_64-linux-gnu/libGL.la
lrwxrwxrwx 1 root root      10 mar 10 09:15 /usr/lib/x86_64-linux-gnu/libGL.so -> libGL.so.1
lrwxrwxrwx 1 root root      14 mar 10 09:15 /usr/lib/x86_64-linux-gnu/libGL.so.1 -> libGL.so.1.6.0
-rw-r--r-- 1 root root 4330248 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libGL.so.1.6.0
-rwxr-xr-x 1 root root 1317432 feb 27 15:24 /usr/lib/x86_64-linux-gnu/libGL.so.346.47
-verbatin-

The problem is that each time I upgrade Debian, the GL links point again to the official NVIDIA GL libraries (although they were installed via the independent nvidia *.run driver instead from the official Debian packages!), so I should run my script after each system upgrade

But today I have compiled Octave and I have installed the libosmesa6 and libosmesa6-dev packages. I think there is not any osmesa libraries in the NVIDIA driver, but in my Octave make check I obtain the same osmesa_print crash. The osmesa libraries points always to the same files. They don't change even where I install the NVIDIA driver

+verbatim+
lrwxrwxrwx 1 root root      18 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libOSMesa.so -> libOSMesa.so.8.0.0
lrwxrwxrwx 1 root root      14 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libOSMesa.so.6 -> libOSMesa.so.8
lrwxrwxrwx 1 root root      18 ene 15 15:01 /usr/lib/x86_64-linux-gnu/libOSMesa.so.8 -> libOSMesa.so.8.0.0
-rw-r--r-- 1 root root 3889448 ene 15 15:02 /usr/lib/x86_64-linux-gnu/libOSMesa.so.8.0.0


I don't know if this information could help, but someone in the maintainers list recommends me to share it here

José Luis García Pallero <jgpallero>
Tue 10 Mar 2015 01:46:07 AM UTC, comment #15: 

Well we haven't yet proven that it segfaults outside of Octave. That was what Andy was trying to test with the mesa demos he asked to be run. But those example programs apparently do not cause a segfault using OSMesa with Nvidia.

Mike Miller <mtmiller>
Group Member
Tue 10 Mar 2015 01:39:59 AM UTC, comment #14: 

Is there anything Octave can do?  Or is this an upstream bug between Nvidia and OpenGL?

Rik <rik5>
Group administrator
Tue 10 Mar 2015 01:30:12 AM UTC, comment #13: 

Thanks to Juan Pablo for confirming, it seems pretty certain now that this segfault is constrained to systems using the Nvidia proprietary drivers.

It occurred to me that this might have something to do with Nvidia's replacement OpenGL libraries (for those that haven't experienced Nvidia, it requires also installing Nvidia's own version of libGL, etc).

Some light searching does yield a few hits on problems with OSMesa and Nvidia.

Mike Miller <mtmiller>
Group Member
Mon 09 Mar 2015 09:43:36 PM UTC, comment #12: 

I am running Ubuntu 14.10 64 bit with shipped OSMesa 10.5.0
I am using nvidia driver 331
The problem is still there.
As of indication of Andy Weber I tested the following mesa_demos


git clone git://anongit.freedesktop.org/mesa/demos mesa_demos
cd mesa_demos
./autogen.sh
./configure --enable-osmesa
make
cd src/osdemos
./osdemo32 test.tga
./osdemo16 test.tga
./osdemo test.tga


All tests produce a TGA image without problems.


Juan Pablo Carbajal <juanpi>
Group Member
Mon 09 Mar 2015 04:48:56 AM UTC, comment #11: 

I have re-built octave-4.0.0-rc1 after removing the nvidia driver and uninstalling self-built OSMesa.
(Ubuntu 14.04 LTS 64 bit ships OSMesa whose version is 10.5.0.)


octave:1> test __osmesa_print__.cc-tst
PASSES 2 out of 2 tests


Thanks all the help!

Tatsuro MATSUOKA <tmacchant>
Mon 09 Mar 2015 03:24:15 AM UTC, comment #10: 

Mike

I have uninstalled the nvidia driver (304).


./run-octave -g --no-gui
 :
octave:1> test __osmesa_print__.cc-tst


octave:1> test __osmesa_print__.cc-tst
***** testif HAVE_OSMESA
 h = figure ("visible", "off");
 fn = tempname ();
 sombrero ();
 __osmesa_print__ (h, fn, "svg");
 assert (stat (fn).size, 2692270, -0.1);
 unlink (fn);
 img = __osmesa_print__ (h);
 assert (size (img), [get(h, "position")([4, 3]), 3])
 ## Use pixel sum per RGB channel as fingerprint
 img_fp = squeeze (sum (sum (img), 2));
 assert (img_fp, [52942515; 54167797; 56158178], -0.05);
!!!!! test failed
ASSERT errors for:  assert (stat (fn).size,2692270,-0.1)

  Location  |  Observed  |  Expected  |  Reason
     ()          2798       2692270      Rel err 0.99896 exceeds tol 0.1


The origin of fault comes from the nvidia driver.

I am using the Ubuntu 14.04 on GNOME desktop but not Unity.
The unity desktop does not work for my PC with and without the nvidia driver.

I will use my Ubuntu PC without the nvidia driver at the moment.

Thank you for your advise.

Tatsuro MATSUOKA <tmacchant>
Mon 09 Mar 2015 03:03:31 AM UTC, comment #9: 

To Anonymous

I have built osmesa-10.4.6 and built octave against it.


./run-octave -g --no-gui
 :
octave:1> test __osmesa_print__.cc-tst



octave:1> test __osmesa_print__.cc-tst

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd607b700 (LWP 22857)]
0x00007ffff3242569 in glGetIntegerv () from /usr/lib/nvidia-304/libGL.so.1
(gdb) bt
#0  0x00007ffff3242569 in glGetIntegerv () from /usr/lib/nvidia-304/libGL.so.1
#1  0x00007fffc56ac6b2 in F__osmesa_print__ (args=...)
    at ../../octave-4.0.0-rc1/libinterp/dldfcn/__osmesa_print__.cc:160
#2  0x00007ffff6e8055c in octave_builtin::do_multi_index_op (
    this=0x7fffc077d270, nargout=0, args=..., lvalue_list=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-builtin.cc:131
#3  0x00007ffff6e7f791 in octave_builtin::subsref (this=0x7fffc077d270,
    type=..., idx=..., nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-builtin.cc:63
#4  0x00007ffff6e7fe3c in octave_builtin::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-builtin.cc:46
#5  0x00007ffff6f61399 in octave_value::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov.cc:1302
#6  0x00007ffff6f61415 in octave_value::subsref (
    this=this@entry=0x7fffd6077fe0, type=..., idx=...,
    nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov.cc:1313
#7  0x00007ffff6fce5d8 in tree_index_expression::rvalue (this=<optimized out>,
    nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-idx.cc:436
#8  0x00007ffff6fcf0cb in tree_index_expression::rvalue (this=<optimized out>,
---Type <return> to continue, or q <return> to quit---
    nargout=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-idx.cc:284
#9  0x00007ffff6fcb61e in tree_index_expression::rvalue1 (this=0x7fffc05f7b50,
    nargout=0) at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-idx.cc:466
#10 0x00007ffff6fc26f8 in tree_evaluator::visit_statement (
    this=<optimized out>, stmt=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:744
#11 0x00007ffff6fc1d41 in tree_evaluator::visit_statement_list (
    this=0x7ffff7977140 <std_evaluator>, lst=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:794
#12 0x00007ffff6f585e3 in octave_user_function::do_multi_index_op (
    this=0x7fffc05688a0, nargout=0, _args=..., lvalue_list=0x0)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-usr-fcn.cc:626
#13 0x00007ffff6f54885 in octave_user_function::subsref (this=0x7fffc05688a0,
    type=..., idx=..., nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-usr-fcn.cc:438
#14 0x00007ffff6f54a4c in octave_user_function::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-usr-fcn.cc:421
#15 0x00007ffff6f61399 in octave_value::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov.cc:1302
#16 0x00007ffff6f61415 in octave_value::subsref (
---Type <return> to continue, or q <return> to quit---
    this=this@entry=0x7fffd6078aa0, type=..., idx=...,
    nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov.cc:1313
#17 0x00007ffff6fce5d8 in tree_index_expression::rvalue (this=<optimized out>,
    nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-idx.cc:436
#18 0x00007ffff6fcf0cb in tree_index_expression::rvalue (this=<optimized out>,
    nargout=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-idx.cc:284
#19 0x00007ffff6fffc90 in eval_string (eval_str=...,
    silent=silent@entry=false, parse_status=@0x7fffd6078fbc: 0,
    nargout=nargout@entry=0) at parse-tree/oct-parse.yy:4845
#20 0x00007ffff6fffffd in eval_string (arg=..., silent=silent@entry=false,
    parse_status=@0x7fffd6078fbc: 0, nargout=nargout@entry=0)
    at parse-tree/oct-parse.yy:4898
#21 0x00007ffff7000119 in Feval (args=..., nargout=0)
    at parse-tree/oct-parse.yy:4964
#22 0x00007ffff6e8055c in octave_builtin::do_multi_index_op (
    this=0x7fffc010ed60, nargout=0, args=..., lvalue_list=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-builtin.cc:131
#23 0x00007ffff6e7f791 in octave_builtin::subsref (this=0x7fffc010ed60,
    type=..., idx=..., nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-builtin.cc:63
---Type <return> to continue, or q <return> to quit---
#24 0x00007ffff6e7fe3c in octave_builtin::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-builtin.cc:46
#25 0x00007ffff6f61399 in octave_value::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov.cc:1302
#26 0x00007ffff6f61415 in octave_value::subsref (
    this=this@entry=0x7fffd6079520, type=..., idx=...,
    nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov.cc:1313
#27 0x00007ffff6fce5d8 in tree_index_expression::rvalue (this=<optimized out>,
    nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-idx.cc:436
#28 0x00007ffff6fcf0cb in tree_index_expression::rvalue (this=<optimized out>,
    nargout=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-idx.cc:284
#29 0x00007ffff6fcb61e in tree_index_expression::rvalue1 (this=0x7fffc05e8c20,
    nargout=0) at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-idx.cc:466
#30 0x00007ffff6fc26f8 in tree_evaluator::visit_statement (
    this=<optimized out>, stmt=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:744
#31 0x00007ffff6fc1d41 in tree_evaluator::visit_statement_list (
    this=0x7ffff7977140 <std_evaluator>, lst=...)
---Type <return> to continue, or q <return> to quit---
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:794
#32 0x00007ffff6fc2635 in tree_evaluator::visit_statement (
    this=0x7ffff7977140 <std_evaluator>, stmt=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:718
#33 0x00007ffff6fc1d41 in tree_evaluator::visit_statement_list (
    this=0x7ffff7977140 <std_evaluator>, lst=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:794
#34 0x00007ffff6fc389a in tree_evaluator::visit_try_catch_command (
    this=0x7ffff7977140 <std_evaluator>, cmd=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:907
#35 0x00007ffff6fc2635 in tree_evaluator::visit_statement (
    this=0x7ffff7977140 <std_evaluator>, stmt=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:718
#36 0x00007ffff6fc1d41 in tree_evaluator::visit_statement_list (
    this=0x7ffff7977140 <std_evaluator>, lst=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:794
#37 0x00007ffff6fc2635 in tree_evaluator::visit_statement (
    this=0x7ffff7977140 <std_evaluator>, stmt=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:718
#38 0x00007ffff6fc1d41 in tree_evaluator::visit_statement_list (
    this=0x7ffff7977140 <std_evaluator>, lst=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:794
#39 0x00007ffff6fc472e in tree_evaluator::visit_unwind_protect_command (
---Type <return> to continue, or q <return> to quit---
    this=0x7ffff7977140 <std_evaluator>, cmd=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:1045
#40 0x00007ffff6fc2635 in tree_evaluator::visit_statement (
    this=0x7ffff7977140 <std_evaluator>, stmt=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:718
#41 0x00007ffff6fc1d41 in tree_evaluator::visit_statement_list (
    this=0x7ffff7977140 <std_evaluator>, lst=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:794
#42 0x00007ffff6fc2cf2 in tree_evaluator::visit_simple_for_command (
    this=0x7ffff7977140 <std_evaluator>, cmd=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:349
#43 0x00007ffff6fc2635 in tree_evaluator::visit_statement (
    this=0x7ffff7977140 <std_evaluator>, stmt=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:718
#44 0x00007ffff6fc1d41 in tree_evaluator::visit_statement_list (
    this=0x7ffff7977140 <std_evaluator>, lst=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:794
#45 0x00007ffff6f585e3 in octave_user_function::do_multi_index_op (
    this=0x7fffc05ffeb0, nargout=0, _args=..., lvalue_list=0x0)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-usr-fcn.cc:626
#46 0x00007ffff6f54885 in octave_user_function::subsref (this=0x7fffc05ffeb0,
    type=..., idx=..., nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-usr-fcn.cc:438
---Type <return> to continue, or q <return> to quit---
#47 0x00007ffff6f54a4c in octave_user_function::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-usr-fcn.cc:421
#48 0x00007ffff6f61399 in octave_value::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov.cc:1302
#49 0x00007ffff6f61415 in octave_value::subsref (
    this=this@entry=0x7fffd607a700, type=..., idx=...,
    nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov.cc:1313
#50 0x00007ffff6fce5d8 in tree_index_expression::rvalue (this=<optimized out>,
    nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-idx.cc:436
#51 0x00007ffff6fcf0cb in tree_index_expression::rvalue (this=<optimized out>,
    nargout=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-idx.cc:284
#52 0x00007ffff6fcb61e in tree_index_expression::rvalue1 (this=0x7fffc0481160,
    nargout=0) at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-idx.cc:466
#53 0x00007ffff6fc26f8 in tree_evaluator::visit_statement (
    this=<optimized out>, stmt=...)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:744
#54 0x00007ffff6fc1d41 in tree_evaluator::visit_statement_list (
    this=0x7ffff7977140 <std_evaluator>, lst=...)
---Type <return> to continue, or q <return> to quit---
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-eval.cc:794
#55 0x00007ffff73db4dd in main_loop ()
    at ../../octave-4.0.0-rc1/libinterp/corefcn/toplev.cc:599
#56 0x00007ffff6b8d89e in octave_execute_interpreter ()
    at ../../octave-4.0.0-rc1/libinterp/octave.cc:917
#57 0x00007ffff7a7c2bc in octave_cli_thread::run (this=0x7fffffffb830)
    at ../../octave-4.0.0-rc1/libgui/src/octave-gui.cc:80
#58 0x00007ffff37d432f in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#59 0x00007ffff25bd182 in start_thread (arg=0x7fffd607b700)
    at pthread_create.c:312
#60 0x00007ffff62c847d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111



Tatsuro MATSUOKA <tmacchant>
Mon 09 Mar 2015 01:54:42 AM UTC, comment #8: 

Rik

I have check out the recent Mercurial sources and built octave.
The last changeset 19921:57379fcc1aec
author Rik <rik@octave.org>
date Sun, 08 Mar 2015 12:55:21 -0700

The sources include changes of changeset 19917:f48e650a68b5.


./run-octave -g --no-gui
 :
octave:1> test __osmesa_print__.cc-tst



Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd607c700 (LWP 13853)]
0x00007ffff3243569 in glGetIntegerv () from /usr/lib/nvidia-304/libGL.so.1
(gdb) bt
#0  0x00007ffff3243569 in glGetIntegerv () from /usr/lib/nvidia-304/libGL.so.1
#1  0x00007fffc56ac6a2 in F__osmesa_print__ (args=...)
    at ../../octave/libinterp/dldfcn/__osmesa_print__.cc:159
#2  0x00007ffff6e8155c in octave_builtin::do_multi_index_op (
    this=0x7fffc07bb9b0, nargout=0, args=..., lvalue_list=<optimized out>)
    at ../../octave/libinterp/octave-value/ov-builtin.cc:131
#3  0x00007ffff6e80791 in octave_builtin::subsref (this=0x7fffc07bb9b0,
    type=..., idx=..., nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave/libinterp/octave-value/ov-builtin.cc:63
#4  0x00007ffff6e80e3c in octave_builtin::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave/libinterp/octave-value/ov-builtin.cc:46
#5  0x00007ffff6f62399 in octave_value::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave/libinterp/octave-value/ov.cc:1302
#6  0x00007ffff6f62415 in octave_value::subsref (
    this=this@entry=0x7fffd6078f40, type=..., idx=...,
    nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave/libinterp/octave-value/ov.cc:1313
#7  0x00007ffff6fcf5d8 in tree_index_expression::rvalue (this=<optimized out>,
    nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave/libinterp/parse-tree/pt-idx.cc:436
#8  0x00007ffff6fd00cb in tree_index_expression::rvalue (this=<optimized out>,
---Type <return> to continue, or q <return> to quit---
    nargout=<optimized out>) at ../../octave/libinterp/parse-tree/pt-idx.cc:284
#9  0x00007ffff6fcc61e in tree_index_expression::rvalue1 (this=0x7fffc0604f70,
    nargout=0) at ../../octave/libinterp/parse-tree/pt-idx.cc:466
#10 0x00007ffff6fc36f8 in tree_evaluator::visit_statement (
    this=<optimized out>, stmt=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:744
#11 0x00007ffff6fc2d41 in tree_evaluator::visit_statement_list (
    this=0x7ffff7977140 <std_evaluator>, lst=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:794
#12 0x00007ffff6fc3635 in tree_evaluator::visit_statement (
    this=0x7ffff7977140 <std_evaluator>, stmt=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:718
#13 0x00007ffff6fc2d41 in tree_evaluator::visit_statement_list (
    this=0x7ffff7977140 <std_evaluator>, lst=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:794
#14 0x00007ffff6f595e3 in octave_user_function::do_multi_index_op (
    this=0x7fffc05f1f60, nargout=0, _args=..., lvalue_list=0x0)
    at ../../octave/libinterp/octave-value/ov-usr-fcn.cc:626
#15 0x00007ffff6f55885 in octave_user_function::subsref (this=0x7fffc05f1f60,
    type=..., idx=..., nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave/libinterp/octave-value/ov-usr-fcn.cc:438
#16 0x00007ffff6f55a4c in octave_user_function::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
---Type <return> to continue, or q <return> to quit---
    at ../../octave/libinterp/octave-value/ov-usr-fcn.cc:421
#17 0x00007ffff6f62399 in octave_value::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave/libinterp/octave-value/ov.cc:1302
#18 0x00007ffff6f62415 in octave_value::subsref (
    this=this@entry=0x7fffd6079aa0, type=..., idx=...,
    nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave/libinterp/octave-value/ov.cc:1313
#19 0x00007ffff6fcf5d8 in tree_index_expression::rvalue (this=<optimized out>,
    nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave/libinterp/parse-tree/pt-idx.cc:436
#20 0x00007ffff6fd00cb in tree_index_expression::rvalue (this=<optimized out>,
    nargout=<optimized out>) at ../../octave/libinterp/parse-tree/pt-idx.cc:284
#21 0x00007ffff7000b60 in eval_string (eval_str=...,
    silent=silent@entry=false, parse_status=@0x7fffd6079fbc: 0,
    nargout=nargout@entry=0) at parse-tree/oct-parse.yy:4845
#22 0x00007ffff7000ecd in eval_string (arg=..., silent=silent@entry=false,
    parse_status=@0x7fffd6079fbc: 0, nargout=nargout@entry=0)
    at parse-tree/oct-parse.yy:4898
#23 0x00007ffff7000fe9 in Feval (args=..., nargout=0)
    at parse-tree/oct-parse.yy:4964
#24 0x00007ffff6e8155c in octave_builtin::do_multi_index_op (
    this=0x7fffc010f160, nargout=0, args=..., lvalue_list=<optimized out>)
---Type <return> to continue, or q <return> to quit---
    at ../../octave/libinterp/octave-value/ov-builtin.cc:131
#25 0x00007ffff6e80791 in octave_builtin::subsref (this=0x7fffc010f160,
    type=..., idx=..., nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave/libinterp/octave-value/ov-builtin.cc:63
#26 0x00007ffff6e80e3c in octave_builtin::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave/libinterp/octave-value/ov-builtin.cc:46
#27 0x00007ffff6f62399 in octave_value::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave/libinterp/octave-value/ov.cc:1302
#28 0x00007ffff6f62415 in octave_value::subsref (
    this=this@entry=0x7fffd607a520, type=..., idx=...,
    nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave/libinterp/octave-value/ov.cc:1313
#29 0x00007ffff6fcf5d8 in tree_index_expression::rvalue (this=<optimized out>,
    nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave/libinterp/parse-tree/pt-idx.cc:436
#30 0x00007ffff6fd00cb in tree_index_expression::rvalue (this=<optimized out>,
    nargout=<optimized out>) at ../../octave/libinterp/parse-tree/pt-idx.cc:284
#31 0x00007ffff6fcc61e in tree_index_expression::rvalue1 (this=0x7fffc05e8570,
    nargout=0) at ../../octave/libinterp/parse-tree/pt-idx.cc:466
#32 0x00007ffff6fc36f8 in tree_evaluator::visit_statement (
    this=<optimized out>, stmt=...)
---Type <return> to continue, or q <return> to quit---
    at ../../octave/libinterp/parse-tree/pt-eval.cc:744
#33 0x00007ffff6fc2d41 in tree_evaluator::visit_statement_list (
    this=0x7ffff7977140 <std_evaluator>, lst=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:794
#34 0x00007ffff6fc3635 in tree_evaluator::visit_statement (
    this=0x7ffff7977140 <std_evaluator>, stmt=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:718
#35 0x00007ffff6fc2d41 in tree_evaluator::visit_statement_list (
    this=0x7ffff7977140 <std_evaluator>, lst=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:794
#36 0x00007ffff6fc489a in tree_evaluator::visit_try_catch_command (
    this=0x7ffff7977140 <std_evaluator>, cmd=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:907
#37 0x00007ffff6fc3635 in tree_evaluator::visit_statement (
    this=0x7ffff7977140 <std_evaluator>, stmt=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:718
#38 0x00007ffff6fc2d41 in tree_evaluator::visit_statement_list (
    this=0x7ffff7977140 <std_evaluator>, lst=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:794
#39 0x00007ffff6fc3635 in tree_evaluator::visit_statement (
    this=0x7ffff7977140 <std_evaluator>, stmt=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:718
#40 0x00007ffff6fc2d41 in tree_evaluator::visit_statement_list (
---Type <return> to continue, or q <return> to quit---
    this=0x7ffff7977140 <std_evaluator>, lst=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:794
#41 0x00007ffff6fc572e in tree_evaluator::visit_unwind_protect_command (
    this=0x7ffff7977140 <std_evaluator>, cmd=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:1045
#42 0x00007ffff6fc3635 in tree_evaluator::visit_statement (
    this=0x7ffff7977140 <std_evaluator>, stmt=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:718
#43 0x00007ffff6fc2d41 in tree_evaluator::visit_statement_list (
    this=0x7ffff7977140 <std_evaluator>, lst=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:794
#44 0x00007ffff6fc3cf2 in tree_evaluator::visit_simple_for_command (
    this=0x7ffff7977140 <std_evaluator>, cmd=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:349
#45 0x00007ffff6fc3635 in tree_evaluator::visit_statement (
    this=0x7ffff7977140 <std_evaluator>, stmt=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:718
#46 0x00007ffff6fc2d41 in tree_evaluator::visit_statement_list (
    this=0x7ffff7977140 <std_evaluator>, lst=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:794
#47 0x00007ffff6f595e3 in octave_user_function::do_multi_index_op (
    this=0x7fffc05ff800, nargout=0, _args=..., lvalue_list=0x0)
    at ../../octave/libinterp/octave-value/ov-usr-fcn.cc:626
---Type <return> to continue, or q <return> to quit---
#48 0x00007ffff6f55885 in octave_user_function::subsref (this=0x7fffc05ff800,
    type=..., idx=..., nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave/libinterp/octave-value/ov-usr-fcn.cc:438
#49 0x00007ffff6f55a4c in octave_user_function::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave/libinterp/octave-value/ov-usr-fcn.cc:421
#50 0x00007ffff6f62399 in octave_value::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave/libinterp/octave-value/ov.cc:1302
#51 0x00007ffff6f62415 in octave_value::subsref (
    this=this@entry=0x7fffd607b700, type=..., idx=...,
    nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave/libinterp/octave-value/ov.cc:1313
#52 0x00007ffff6fcf5d8 in tree_index_expression::rvalue (this=<optimized out>,
    nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave/libinterp/parse-tree/pt-idx.cc:436
#53 0x00007ffff6fd00cb in tree_index_expression::rvalue (this=<optimized out>,
    nargout=<optimized out>) at ../../octave/libinterp/parse-tree/pt-idx.cc:284
#54 0x00007ffff6fcc61e in tree_index_expression::rvalue1 (this=0x7fffc01906f0,
    nargout=0) at ../../octave/libinterp/parse-tree/pt-idx.cc:466
#55 0x00007ffff6fc36f8 in tree_evaluator::visit_statement (
    this=<optimized out>, stmt=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:744
---Type <return> to continue, or q <return> to quit---
#56 0x00007ffff6fc2d41 in tree_evaluator::visit_statement_list (
    this=0x7ffff7977140 <std_evaluator>, lst=...)
    at ../../octave/libinterp/parse-tree/pt-eval.cc:794
#57 0x00007ffff73dc3ad in main_loop ()
    at ../../octave/libinterp/corefcn/toplev.cc:599
#58 0x00007ffff6b8e89e in octave_execute_interpreter ()
    at ../../octave/libinterp/octave.cc:917
#59 0x00007ffff7a7c9bc in octave_cli_thread::run (this=0x7fffffffbd10)
    at ../../octave/libgui/src/octave-gui.cc:80
#60 0x00007ffff37d532f in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#61 0x00007ffff25be182 in start_thread (arg=0x7fffd607c700)
    at pthread_create.c:312
#62 0x00007ffff62c947d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111


Tatsuro MATSUOKA <tmacchant>
Sun 08 Mar 2015 11:10:29 PM UTC, comment #7: 

Thanks Mike
First I tried:
Or set LD_LIBRARY_PATH so the mesa libGL.so is found instead of the nvidia version.


$ locate libGL.so
/usr/lib/i386-linux-gnu/mesa/libGL.so.1
/usr/lib/i386-linux-gnu/mesa/libGL.so.1.2.0
/usr/lib/nvidia-304/libGL.so
/usr/lib/nvidia-304/libGL.so.1
/usr/lib/nvidia-304/libGL.so.304.125
/usr/lib/x86_64-linux-gnu/libGL.so
/usr/lib/x86_64-linux-gnu/mesa/libGL.so
/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0
/usr/lib32/nvidia-304/libGL.so
/usr/lib32/nvidia-304/libGL.so.1
/usr/lib32/nvidia-304/libGL.so.304.125


So I have set LD_LIBRARY_PATH as:


export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/mesa/:$LD_LIBRARY_PATH

./run-octave -g --no-gui
octave:1> test __osmesa_print__.cc-tst



octave:1> test __osmesa_print__.cc-tst
[New Thread 0x7fffc0a44700 (LWP 11144)]
[New Thread 0x7fffc0243700 (LWP 11145)]
libGL error: No matching fbConfigs or visuals found
[Thread 0x7fffc0a44700 (LWP 11144) exited]
[Thread 0x7fffc0243700 (LWP 11145) exited]
libGL error: failed to load driver: swrast
[Thread 0x7fffd3fff700 (LWP 10106) exited]
PASSES 2 out of 2 tests


Test passes but


libGL error: No matching fbConfigs or visuals found


appeared. I will check temporally uninstall nvidia driver and execute the test.
 
I

Tatsuro MATSUOKA <tmacchant>
Sun 08 Mar 2015 01:30:02 PM UTC, comment #6: 

Could this be related? http://gfs.sourceforge.net/wiki/index.php/Standalone_OSMesa can you build osmesa as described here http://wiki.octave.org/Build_libosmesa ?

Anonymous
Sun 08 Mar 2015 12:58:51 PM UTC, comment #5: 

The function that is segfaulting according to gdb is glGetIntegerv and the function prototype says that the variable reference passed in should be of type GLint.  The code in _osmesa_print_.cc is using just int.  It is possible that the C++ int and GLint differ in size so a different amount of memory is being written by the Nvidia routines which should have been compiled against the OpenGL headers.

This is unlikely to be the source of the problem, but was bad practice anyways so I changed it (http://hg.savannah.gnu.org/hgweb/octave/rev/f48e650a68b5).

@Tatsuro, you should be able to build from Mercurial sources on Ubuntu easily.  If you can check whether this helps that would be great.

Rik <rik5>
Group administrator
Sun 08 Mar 2015 02:44:36 AM UTC, comment #4: 

I had thought running under xvfb would help isolate you from the nvidia driver, but it is still using the libGL.so provided by nvidia, so this didn't tell us much. Is there a way to uninstall or temporarily disable the nvidia drivers on your system without breaking everything? Or set LD_LIBRARY_PATH so the mesa libGL.so is found instead of the nvidia version?

Mike Miller <mtmiller>
Group Member
Sun 08 Mar 2015 12:08:41 AM UTC, comment #3: 

In text mode (Pressed after CTRL+ALT+F1),

./run-octave -g --no-gui
test _osmesa_print_.cc-tst

was successful.

Tatsuro MATSUOKA <tmacchant>
Sat 07 Mar 2015 11:46:06 PM UTC, comment #2: 

Thank for your support!


$ xvfb-run ./run-octave
Xlib:  extension "RANDR" missing on display ":99".


I cannot see octave gui under xvfb-run. (I can see it without xvfb-run).

Then I tried:


$ xvfb-run ./run-octave -g --no-gui

octave:1> test __osmesa_print__.cc-tst[Thread 0x7fffd3fff700 (LWP 21151) exited]

Xlib:  extension "GLX" missing on display ":99".
Xlib:  extension "GLX" missing on display ":99".
Xlib:  extension "GLX" missing on display ":99".
Xlib:  extension "GLX" missing on display ":99".
Xlib:  extension "GLX" missing on display ":99".

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd2a0a700 (LWP 21153)]
0x00007ffff3242569 in glGetIntegerv () from /usr/lib/nvidia-304/libGL.so.1
(gdb) bt
#0  0x00007ffff3242569 in glGetIntegerv () from /usr/lib/nvidia-304/libGL.so.1
#1  0x00007fffc272a6b2 in F__osmesa_print__ (args=...)
    at ../../octave-4.0.0-rc1/libinterp/dldfcn/__osmesa_print__.cc:160
#2  0x00007ffff6e8055c in octave_builtin::do_multi_index_op (
    this=0x7fffbc79b350, nargout=0, args=..., lvalue_list=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-builtin.cc:131
#3  0x00007ffff6e7f791 in octave_builtin::subsref (this=0x7fffbc79b350,
    type=..., idx=..., nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-builtin.cc:63
#4  0x00007ffff6e7fe3c in octave_builtin::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-builtin.cc:46
#5  0x00007ffff6f61399 in octave_value::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov.cc:1302
#6  0x00007ffff6f61415 in octave_value::subsref (
    this=this@entry=0x7fffd2a06fe0, type=..., idx=...,
    nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov.cc:1313
#7  0x00007ffff6fce5d8 in tree_index_expression::rvalue (this=<optimized out>,
    nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-idx.cc:436
#8  0x00007ffff6fcf0cb in tree_index_expression::rvalue (this=<optimized out>,
---Type <return> to continue, or q <return> to quit---


Tatsuro MATSUOKA <tmacchant>
Sat 07 Mar 2015 11:28:25 PM UTC, comment #1: 

Thanks for the backtrace on this crash. Can you try running the same test in xvfb-run?


$ sudo apt-get install xvfb
$ xvfb-run ./run-octave -g
>> test __osmesa_print__.cc-tst


This should allow Octave to be run with an X display but without a dependency on your video card.

Or can you switch to the nouveau driver temporarily to see if the crash doesn't occur?

Mike Miller <mtmiller>
Group Member
Sat 07 Mar 2015 10:56:37 PM UTC, original submission:  

platform : Ubuntu 14.04 LTS 64 bit
Compiler : gcc-4.8.2

Start octave: ./run-octave -g --no-gui

Error:


octave:1> test __osmesa_print__.cc-tst

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd607b700 (LWP 2650)]
0x00007ffff3242569 in glGetIntegerv () from /usr/lib/nvidia-304/libGL.so.1
(gdb) bt
#0  0x00007ffff3242569 in glGetIntegerv () from /usr/lib/nvidia-304/libGL.so.1
#1  0x00007fffc57516b2 in F__osmesa_print__ (args=...)
    at ../../octave-4.0.0-rc1/libinterp/dldfcn/__osmesa_print__.cc:160
#2  0x00007ffff6e8055c in octave_builtin::do_multi_index_op (
    this=0x7fffc07aaa00, nargout=0, args=..., lvalue_list=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-builtin.cc:131
#3  0x00007ffff6e7f791 in octave_builtin::subsref (this=0x7fffc07aaa00,
    type=..., idx=..., nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-builtin.cc:63
#4  0x00007ffff6e7fe3c in octave_builtin::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov-builtin.cc:46
#5  0x00007ffff6f61399 in octave_value::subsref (this=<optimized out>,
    type=..., idx=..., nargout=<optimized out>)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov.cc:1302
#6  0x00007ffff6f61415 in octave_value::subsref (
    this=this@entry=0x7fffd6077fe0, type=..., idx=...,
    nargout=nargout@entry=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/octave-value/ov.cc:1313
#7  0x00007ffff6fce5d8 in tree_index_expression::rvalue (this=<optimized out>,
    nargout=0, lvalue_list=lvalue_list@entry=0x0)
    at ../../octave-4.0.0-rc1/libinterp/parse-tree/pt-idx.cc:436
#8  0x00007ffff6fcf0cb in tree_index_expression::rvalue (this=<optimized out>,
---Type <return> to continue, or q <return> to quit---


Is the above related to nvidia-304 ?

Tatsuro MATSUOKA <tmacchant>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #37132:  osmesa-fltk-foo.cc added by jwe (2KiB - text/x-c++src)
file #37131:  osmesa-foo.cc added by jwe (960B - text/x-c++src)
file #33615:  nvidia.cset added by rik5 (2KiB - application/octet-stream)
file #33602:  simple_gl_oct.tar.gz added by andy1978 (616B - application/x-gzip)
file #33373:  mymake_mesa.log added by juanpi (928KiB - text/x-log)
file #33370:  gdb.txt added by juanpi (14KiB - text/plain)
file #33343:  minimal__osmesa_print__.cc added by rik5 (6KiB - text/x-c++src)
file #33334:  __osmesa_print__.cc added by juanpi (5KiB - text/x-c++src)
file #33319:  glenable.diff added by rik5 (761B - text/x-diff)

 

Carbon-Copy List
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by jbect (Posted a comment)
  • -email is unavailable- added by ederag (Posted a comment)
  • -email is unavailable- added by jbect
  • -email is unavailable- added by andy1978 (Posted a comment)
  • -email is unavailable- added by jgpallero (Posted a comment)
  • -email is unavailable- added by juanpi (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by tmacchant (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 22 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-03 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2017-12-30 sebald Attached File- Added octave-nvidia_octave-olp_utility_djs2017dec29.patch, #42760
    2016-07-01 rik5 Severity3 - Normal 4 - Important
    2016-05-11 jwe Attached File- Added osmesa-fltk-foo.cc, #37132
    2016-05-11 jwe Attached File- Added osmesa-foo.cc, #37131
    2016-05-06 mtmiller Dependencies- bugs #47849 is dependent
    2015-08-08 mtmiller Dependencies- bugs #45719 is dependent
    2015-08-08 andy1978 Summarytest _osmesa_print_.cc-tst crashes on Ubuntu with Nvidia drivers test _osmesa_print_.cc-tst crashes with Nvidia drivers
    2015-06-02 jwe Release4.0.0-rc1 4.0.0
    2015-04-09 rik5 Attached File- Added nvidia.cset, #33615
    2015-04-08 andy1978 Attached File- Added simple_gl_oct.tar.gz, #33602
    2015-03-17 jbect Carbon-Copy- Added jbect
    2015-03-16 juanpi Attached File- Added mymake_mesa.log, #33373
    2015-03-16 juanpi Attached File- Added gdb.txt, #33370
    2015-03-14 rik5 Attached File- Added minimal__osmesa_print__.cc, #33343
    2015-03-13 juanpi Attached File- Added _osmesa_print_.cc, #33334
    2015-03-12 rik5 Attached File- Added glenable.diff, #33319
    2015-03-10 mtmiller StatusNeed Info Confirmed
    2015-03-09 rik5 Summary test _osmesa_print_.cc-tst crashes on ubuntu test _osmesa_print_.cc-tst crashes on Ubuntu with Nvidia drivers
    2015-03-07 mtmiller CategoryNone Plotting with OpenGL
        StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code