Running some applications with bumblebee yields a segmentation fault. From what I can tell it seems to be a virtualGL issue. In this particular case i tried running supermeatboy and got it. I debugged and attached the backtrace.
The segfault appears to be occurring within one of the OpenGL functions, not within the VirtualGL code. Thus, I have no clue why it could be occurring. Another user has discovered some bizarre interaction issues with SDL and VirtualGL that we have yet to find a solution for:
Not sure if this is related. One of the issues discovered with CoreBreach was that the OpenGL context was mysteriously being destroyed within the body of some OpenGL calls, even though glXDestroyContext() had not been called by the app or its underlying libraries. This points to some sort of issue with the nVidia drivers, but I have no idea what. There were other issues that seemed to occur only with SDL, such as the display string memory mysteriously disappearing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had the same segfault with supermeatboy too. here's the stacktrace (valgrind) if it can help :
==3353== Jump to the invalid address stated on the next line
==3353== at 0x0: ???
==3353== by 0x40906CE: pbdrawable::clear() (in /usr/lib/librrfaker.so)
==3353== by 0x4098EFB: pbwin::clear() (in /usr/lib/librrfaker.so)
==3353== by 0x405D46D: glXMakeCurrent (in /usr/lib/librrfaker.so)
==3353== by 0x418DAE1: X11_GL_MakeCurrent (in /usr/local/games/supermeatboy/x86/libSDL-1.2.so.0)
==3353== by 0x418DBD2: X11_GL_CreateContext (in /usr/local/games/supermeatboy/x86/libSDL-1.2.so.0)
==3353== by 0x4193768: X11_SetVideoMode (in /usr/local/games/supermeatboy/x86/libSDL-1.2.so.0)
==3353== by 0x417E55E: SDL_SetVideoMode (in /usr/local/games/supermeatboy/x86/libSDL-1.2.so.0)
==3353== by 0x82C6088: TWindow::TWindow(WindowSetupProps const*) (in /usr/local/games/supermeatboy/x86/SuperMeatBoy-x86)
==3353== by 0x828309B: TEngine::TEngine(EngineParams const*) (in /usr/local/games/supermeatboy/x86/SuperMeatBoy-x86)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please try the latest subversion code and see if it fixes this. I believe more strongly now that this issue has at least the same underlying cause as #3459360, which I think I just fixed. See that bug report for more details.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can any of you do some debugging on this? Since I have no way to get the application without buying the game, I have no way of diagnosing this myself, so I need some additional information that I can only get from a debug build of VirtualGL. Specifically, I'm trying to figure out where the NULL pointer is that's being executed when the segfault occurs. If the pointer is actually within the VirtualGL code, then that may at least give a clue as to what's happening.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes. Can you back out to the scope of pbuffer::clear() and verify if the address of glClearColor() is NULL? Seems like it must be, but I have no idea how or why that would happen, as that's not one of the functions that VirtualGL intercepts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You might want to try the latest code in SVN trunk. I checked in a pretty major fix that addresses issues with applications interfering with the OpenGL states that affect pixel readback (and thus causing VirtualGL to read back the 3D pixels improperly, sometimes overrunning the holding buffer.)
It may not be related, but it's possible that it is. If that doesn't fix the issue, my next suggestion would be to use APItrace:
to capture an OpenGL trace file from the application, from launch up until the seg fault. Then you can play back the trace using 'vglrun glretrace {file}' and see if the seg fault still occurs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To clarify, you would run the application on the "local" display without VirtualGL to capture the GL trace, and run the application up until the point where it usually segfaults. Then you can play back the trace using VirtualGL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is this issue still occurring with the latest versions of VirtualGL and the application? I'll make you the same deal I made another game user, which is that if you'll donate the price of the game + $50 to our project, I'll debug the issue ($50 refunded if no resolution can be found.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Closing due to lack of user response. I now have an Ubuntu installation that I could use to test this, but I have no access to the game nor any funding to purchase it. There is a chance that one of the modifications that I made post-2.3.2 fixed this issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs (closed - use GitHub)"
Debug
The segfault appears to be occurring within one of the OpenGL functions, not within the VirtualGL code. Thus, I have no clue why it could be occurring. Another user has discovered some bizarre interaction issues with SDL and VirtualGL that we have yet to find a solution for:
https://sourceforge.net/tracker/?func=detail&aid=3459360&group_id=117509&atid=678327
Not sure if this is related. One of the issues discovered with CoreBreach was that the OpenGL context was mysteriously being destroyed within the body of some OpenGL calls, even though glXDestroyContext() had not been called by the app or its underlying libraries. This points to some sort of issue with the nVidia drivers, but I have no idea what. There were other issues that seemed to occur only with SDL, such as the display string memory mysteriously disappearing.
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs (closed - use GitHub)"
Debugged several applications which acted like this. The segmentation fault appears to be consistently caused by the call to SDL_SetVideoMode ().
I had the same segfault with supermeatboy too. here's the stacktrace (valgrind) if it can help :
==3353== Jump to the invalid address stated on the next line
==3353== at 0x0: ???
==3353== by 0x40906CE: pbdrawable::clear() (in /usr/lib/librrfaker.so)
==3353== by 0x4098EFB: pbwin::clear() (in /usr/lib/librrfaker.so)
==3353== by 0x405D46D: glXMakeCurrent (in /usr/lib/librrfaker.so)
==3353== by 0x418DAE1: X11_GL_MakeCurrent (in /usr/local/games/supermeatboy/x86/libSDL-1.2.so.0)
==3353== by 0x418DBD2: X11_GL_CreateContext (in /usr/local/games/supermeatboy/x86/libSDL-1.2.so.0)
==3353== by 0x4193768: X11_SetVideoMode (in /usr/local/games/supermeatboy/x86/libSDL-1.2.so.0)
==3353== by 0x417E55E: SDL_SetVideoMode (in /usr/local/games/supermeatboy/x86/libSDL-1.2.so.0)
==3353== by 0x82C6088: TWindow::TWindow(WindowSetupProps const*) (in /usr/local/games/supermeatboy/x86/SuperMeatBoy-x86)
==3353== by 0x828309B: TEngine::TEngine(EngineParams const*) (in /usr/local/games/supermeatboy/x86/SuperMeatBoy-x86)
Are any of the applications in which this occurs freely downloadable? SuperMeatBoy is not.
Please try the latest subversion code and see if it fixes this. I believe more strongly now that this issue has at least the same underlying cause as #3459360, which I think I just fixed. See that bug report for more details.
Assuming fixed due to lack of user response. Please let me know if that is not the case.
Just tried running Super Meat Boy with a Ubuntu 12.04 installation, still a segmentation fault.
The VirtualGL (or the package) version is "2.3.1-2~preciseppa1".
Can any of you do some debugging on this? Since I have no way to get the application without buying the game, I have no way of diagnosing this myself, so I need some additional information that I can only get from a debug build of VirtualGL. Specifically, I'm trying to figure out where the NULL pointer is that's being executed when the segfault occurs. If the pointer is actually within the VirtualGL code, then that may at least give a clue as to what's happening.
Is this the information you need?
http://pastebin.ca/2159709
Yes. Can you back out to the scope of pbuffer::clear() and verify if the address of glClearColor() is NULL? Seems like it must be, but I have no idea how or why that would happen, as that's not one of the functions that VirtualGL intercepts.
Sorry, but I'd need line-by-line instructions how to do that, if possible. I'm a total gdb noob.
probably just
up
print glClearColor
would work.
You might want to try the latest code in SVN trunk. I checked in a pretty major fix that addresses issues with applications interfering with the OpenGL states that affect pixel readback (and thus causing VirtualGL to read back the 3D pixels improperly, sometimes overrunning the holding buffer.)
It may not be related, but it's possible that it is. If that doesn't fix the issue, my next suggestion would be to use APItrace:
https://github.com/apitrace/apitrace
to capture an OpenGL trace file from the application, from launch up until the seg fault. Then you can play back the trace using 'vglrun glretrace {file}' and see if the seg fault still occurs.
To clarify, you would run the application on the "local" display without VirtualGL to capture the GL trace, and run the application up until the point where it usually segfaults. Then you can play back the trace using VirtualGL.
Is this issue still occurring with the latest versions of VirtualGL and the application? I'll make you the same deal I made another game user, which is that if you'll donate the price of the game + $50 to our project, I'll debug the issue ($50 refunded if no resolution can be found.)
Closing due to lack of user response. I now have an Ubuntu installation that I could use to test this, but I have no access to the game nor any funding to purchase it. There is a chance that one of the modifications that I made post-2.3.2 fixed this issue.