Menu

#38 VirtualGl segmentation fault

General issue
closed-no-response
DRC
VirtualGL (44)
5
2014-07-12
2012-01-26
Anonymous
No

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.

Discussion

  • DRC

    DRC - 2012-01-26

    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.

     
  • Anonymous

    Anonymous - 2012-02-01

    Debugged several applications which acted like this. The segmentation fault appears to be consistently caused by the call to SDL_SetVideoMode ().

     
  • Fabre Florian

    Fabre Florian - 2012-02-01

    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)

     
  • DRC

    DRC - 2012-02-14

    Are any of the applications in which this occurs freely downloadable? SuperMeatBoy is not.

     
  • DRC

    DRC - 2012-02-18

    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.

     
  • DRC

    DRC - 2012-03-11

    Assuming fixed due to lack of user response. Please let me know if that is not the case.

     
  • DRC

    DRC - 2012-03-11
    • status: open --> closed-fixed
     
  • Heikki

    Heikki - 2012-06-08

    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".

     
  • DRC

    DRC - 2012-06-08
    • status: closed-fixed --> open
     
  • DRC

    DRC - 2012-06-08

    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.

     
  • Heikki

    Heikki - 2012-06-09

    Is this the information you need?

    http://pastebin.ca/2159709

     
  • DRC

    DRC - 2012-06-12

    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.

     
  • Heikki

    Heikki - 2012-06-12

    Sorry, but I'd need line-by-line instructions how to do that, if possible. I'm a total gdb noob.

     
  • DRC

    DRC - 2012-06-12

    probably just

    up
    print glClearColor

    would work.

     
  • DRC

    DRC - 2012-08-23

    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.

     
  • DRC

    DRC - 2012-08-23

    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.

     
  • DRC

    DRC - 2013-03-02

    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.)

     
  • DRC

    DRC - 2013-07-24

    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.

     
  • DRC

    DRC - 2013-07-24
    • status: open --> closed
     
  • DRC

    DRC - 2014-03-28
    • status: closed --> closed-no-response
     

Log in to post a comment.