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
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.
|
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.
|
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.
|
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).
|
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.
|
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.
|
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.
|
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]
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.
|
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".
|
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.
|
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.
|
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).
|
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.
|
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?
|
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)."
|
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).
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.
|
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:
|
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.
|
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:
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?)
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.)
|
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:
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.
|
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):
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:
in a string of commands pertaining to frame buffer resizing and stuff. At the end of this string of function calls and code is
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
rather than getting the
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:
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.
|
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
might work.
|
Thu 12 May 2016 12:42:32 AM UTC, comment #94:
On second thought, looking at these results from the object file list:
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
indicates it is creating a valid context. And in this bare-bones example
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:
and see how that runs when -lGL is not linked in... Does not crash, but comes back:
Interesting, so it could be OSMesaMakeCurrent() that is failing. I'll look at the source code to see what it is doing.
|
Wed 11 May 2016 10:22:38 PM UTC, comment #93:
Yes, I think the multiple function names is the issue. Check this out:
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?
|
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:
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.
|
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.
|
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.
|
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?
|
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?
|
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:
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.
|
Wed 11 May 2016 08:34:48 PM UTC, comment #86:
I compile the second example with
|
Wed 11 May 2016 08:26:23 PM UTC, comment #85:
What are the link flags for FLTK?
|
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)
|
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.
|
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?
|
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:
I see
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?
|
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
On a system with the Mesa OpenGL libraries, I see
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
Is there something wrong with the example program?
(file #37131)
|
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"
|
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
|
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.
|
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
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:
But at least this can be used
|
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.
|
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).
|
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?
|
Wed 04 May 2016 05:03:15 PM UTC, comment #72:
For me, when doing
with nvidia drivers installed, Octave is crashing here:
This crash does not happen for me if I use the nouveau driver.
|
Mon 14 Mar 2016 10:08:48 AM UTC, comment #71:
Still there in 4.0.1-rc4
|
Tue 19 Jan 2016 11:46:07 AM UTC, comment #70:
Still there in 4.0.1-rc3
|
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
|
Fri 11 Dec 2015 11:20:29 PM UTC, comment #68:
Does this link http://askubuntu.com/questions/541343/problems-with-libgl-fbconfigs-swrast-through-each-update help?
|
Fri 11 Dec 2015 09:10:12 PM UTC, comment #67:
Still there in 4.0.1-rc1
|
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
|
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?
|
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.
|
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.
|
Tue 02 Jun 2015 04:36:03 PM UTC, comment #62:
Retagging release from 4.0.0-rc1 to 4.0.0.
|
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.
|
Wed 20 May 2015 03:37:27 PM UTC, comment #60:
Looking at the warning messages,
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.
|
Mon 18 May 2015 09:12:32 AM UTC, comment #59:
It also works here:
Ubuntu vivid, nvidia-346
|
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:
but no crash afterwards.
|
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?
my testscript:
This works with --no-gui, --no-gui-libs and the GUI with FLTK. When using Qt I get
|
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).
|
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?
|
Sat 09 May 2015 06:59:01 AM UTC, comment #54:
Just tried building Octave 4.0.rc4 again. The problem is still here:
|
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.
|
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:
Same with FLTK
|
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?
|
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.
|
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.
|
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
but in a new octave session
octave-4.0.0-rc2 --no-gui
|
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.
24 makes sense, 32610 does not.
(file #33615)
|
Thu 09 Apr 2015 07:20:27 AM UTC, comment #46:
Hi Rik,
I tried your instructions
At least there is no segfault! :)
The segfault still occurs if I do the same with ./run-octave
|
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
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.
|
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)
|
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
|
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)
|
Wed 18 Mar 2015 09:40:54 AM UTC, comment #41:
The log of make octave was removed form the upload. Here it is
|
Mon 16 Mar 2015 11:44:44 PM UTC, comment #40:
Here are the logs.
In the mesa log grep for "osdemo"
(file #33373)
|
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.
|
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
From within Octave run
This will start gdb in another terminal.
We need to set the log (to record the backtrace) by typing in the gdb terminal
After it loads the symbols you get some TTOUT due to some missing files.
Run
in gdb until the octave prompt comes back to life.
Then run the octave commands given in comment #37.
The output of
is attached
(file #33370)
|
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:
Also, when you run make, turn on verbose reporting and record the log.
It may be that the linker flags are not set correctly so that the wrong library is being preferred.
Finally, to run
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.
|
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.
|
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).
|
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
Does the pointer tell you something?
|
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:
(file #33343)
|
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.
|
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?
|
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)
|
Fri 13 Mar 2015 11:17:02 AM UTC, comment #29:
@Rik, I was wrong when I said that I couldn't execute
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
|
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
And
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
|
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.
|
Thu 12 Mar 2015 08:20:28 PM UTC, comment #26:
With run-octave you should be able to use
What happens if you type
It should be
|
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)
|
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)
|
Thu 12 Mar 2015 05:52:20 PM UTC, comment #23:
@Rik, I'm using the 4.0.0-rc1 tarball
|
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
The depth buffer and stencil buffer are optional. It may be that we need to initialize them first before querying. For example, calling
before the glGetIntegerv. On the other hand, all of this code is just doing version testing on OSMESA
Is there some other way we could do this testing that would avoid all of?
|
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
The output for bt in gdb is
|
Thu 12 Mar 2015 05:03:08 PM UTC, comment #20:
You do want to run
This will start gdb. At the gdb prompt, type 'run<RETURN>' to start the executable.
Octave will now be running. Then you can do
When this segfaults, it will return you to gdb. Type 'bt<RETURN' to see the stack backtrace.
|
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
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
this print on screen again LOTS of info lines, but finally octave breaks with
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.
The OSMesa libraries I've installed are:
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
|
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.
|
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
Apparently they don't depend on NVIDIA driver, but I obtain the osmesa crash in make check
|
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:
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:
|
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.
|
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?
|
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.
|
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
All tests produce a TGA image without problems.
|
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.)
Thanks all the help!
|
Mon 09 Mar 2015 03:24:15 AM UTC, comment #10:
Mike
I have uninstalled the nvidia driver (304).
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.
|
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.
|
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.
|
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.
So I have set LD_LIBRARY_PATH as:
Test passes but
appeared. I will check temporally uninstall nvidia driver and execute the test.
I
|
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 ?
|
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.
|
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?
|
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.
|
Sat 07 Mar 2015 11:46:06 PM UTC, comment #2:
Thank for your support!
I cannot see octave gui under xvfb-run. (I can see it without xvfb-run).
Then I tried:
|
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?
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?
|
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:
Is the above related to nvidia-304 ?
|