You can subscribe to this list here.
2011 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(56) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
(2) |
Oct
(1) |
Nov
(7) |
Dec
(36) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2012 |
Jan
|
Feb
(9) |
Mar
(5) |
Apr
(5) |
May
(1) |
Jun
(3) |
Jul
|
Aug
(17) |
Sep
(6) |
Oct
(30) |
Nov
(13) |
Dec
(16) |
2013 |
Jan
(1) |
Feb
(18) |
Mar
(4) |
Apr
|
May
(2) |
Jun
(4) |
Jul
(3) |
Aug
(20) |
Sep
(8) |
Oct
(18) |
Nov
(8) |
Dec
|
2014 |
Jan
(6) |
Feb
|
Mar
(5) |
Apr
(1) |
May
(6) |
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(13) |
Oct
(5) |
Nov
(22) |
Dec
(4) |
2015 |
Jan
(4) |
Feb
|
Mar
(15) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(2) |
Aug
(1) |
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
2016 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
|
May
|
Jun
(21) |
Jul
(10) |
Aug
(7) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: DRC <dco...@us...> - 2017-08-09 19:34:48
|
SourceForge removed the ability for project admins to view/manage the members of mailing lists, which was the final straw. Given that there is some cross-pollination between our projects and TigerVNC, and TigerVNC is using Google Groups, I decided to do likewise with both VirtualGL and TurboVNC. You can join the new groups either using a Google account (which gives you full access to the group from the web interface) or a non-Google e-mail address (which gives you access to post from e-mail only.) Links for joining all of the groups can be found here: http://www.virtualgl.org/About/MailingLists http://www.turbovnc.org/About/MailingLists (Note that you have to be logged in with a Google account in order to join with that account.) To unsubscribe from the old lists, visit one or more of the following URLs: https://sourceforge.net/projects/virtualgl/lists/virtualgl-announce/unsubscribe https://sourceforge.net/projects/virtualgl/lists/virtualgl-users/unsubscribe https://sourceforge.net/projects/virtualgl/lists/virtualgl-devel/unsubscribe https://sourceforge.net/projects/turbovnc/lists/turbovnc-announce/unsubscribe https://sourceforge.net/projects/turbovnc/lists/turbovnc-users/unsubscribe https://sourceforge.net/projects/turbovnc/lists/turbovnc-devel/unsubscribe The direct addresses for e-mailing the new groups are: vir...@go... vir...@go... tur...@go... tur...@go... Other notes: -- If you join with a non-Google e-mail address, Google makes you go through a really annoying Turing test. I apologize in advance for that. -- The old mailing lists will be retained on SourceForge for archival purposes, but they are no longer linked from our SourceForge project pages. To view the archives, visit the links on VirtualGL.org and TurboVNC.org (see above.) -- The new mailing lists have already been added to mail-archive.com. -- The new lists are public (anyone can join or view the messages), but the subscriber lists are visible only to me. -- As with the existing lists, only members can post (and only I can post to the announcement lists.) -- The new lists are configured such that your Google profile will not be revealed if you post. Only your chosen display name will be shown. Reminders: -- If a topic is specific to TurboVNC and does not necessarily involve VirtualGL, then please use one of the TurboVNC lists to discuss that topic. -- We also have a Facebook group (https://www.facebook.com/VirtualGL) and a LinkedIn group (https://www.linkedin.com/groups/3182945) that receive release announcements. You can also use those groups to post questions and concerns. Please e-mail me directly (http://www.virtualgl.org/About/Contact) or post a GitHub tracker issue (https://github.com/VirtualGL/virtualgl/issues/new or https://github.com/TurboVNC/turbovnc/issues/new) should you have any questions, concerns, or problems subscribing to the new lists. The old lists will be closed to new messages shortly, so please transfer your subscriptions immediately. DRC |
From: Antoine M. <an...@na...> - 2017-07-28 10:27:30
|
Hi, Please find attached a patch that enhances VirtualGL to allow it to forward 10 bits per channel pixel data using RGB10_A2 / GL_UNSIGNED_INT_2_10_10_10_REV. The seemingly unofficial fourcc code that I have found for this is "r210" so that's what I've used. ("R210" is for big endian) The string "RGB10_A2" matches the OpenGL pixel format, but lacks the endianness distinction. You can find all you need for testing and visually verifying that the extra bits are being forwarded without any subsampling here: http://xpra.org/trac/ticket/1577#comment:2 Please let me know how you would like to proceed for merging this code, in particular any other required changes I might have missed, and where I should update the documentation, if anywhere. Thanks Antoine |
From: DRC <dco...@us...> - 2017-03-03 02:56:40
|
Official binaries and source tarball are here: https://sourceforge.net/projects/virtualgl/files/2.5.2/ Change log is here: https://github.com/VirtualGL/virtualgl/releases/tag/2.5.2/ |
From: DRC <dco...@us...> - 2016-10-29 15:33:36
|
We are now spinning continuous "official" pre-release builds from the VirtualGL master (2.5.x) branch and the TurboVNC master (2.1.x) and dev (2.2.x) branches, using Travis and AppVeyor. Refer to: http://www.virtualgl.org/DeveloperInfo/PreReleases and http://www.turbovnc.org/DeveloperInfo/PreReleases for more information. There are not many notable changes in the TurboVNC dev branch yet, but the TurboVNC dev pre-release builds incorporate the evolving version of libjpeg-turbo 1.6, so they include the AVX2 SIMD work that has been done thus far (which should make those builds significantly faster on recent CPUs.) DRC |
From: DRC <dco...@us...> - 2016-10-01 18:25:41
|
Official binaries and source tarball are here: https://sourceforge.net/projects/virtualgl/files/2.5.1/ Change log is here: https://github.com/VirtualGL/virtualgl/releases/tag/2.5.1 |
From: DRC <dco...@us...> - 2016-09-16 21:31:23
|
Update: The underlying cause of these problems is that gameoverlayrenderer.so interposes dlsym(), glXGetProcAddress(), and glXGetProcAddressARB(), thus creating a situation similar to the one that used to exist when the nVidia 180.xx drivers were interposing dlsym() (refer to https://sourceforge.net/p/virtualgl/mailman/message/22260702 and https://sourceforge.net/p/virtualgl/mailman/message/21377897 for historical context.) However, in this case, setting VGL_GLLIB doesn't work around it. gameoverlayrenderer.so is closed-source, so it's difficult to ascertain exactly what's happening, but this seems to be an approximation: * VirtualGL attempts to obtain the symbols for glXGetProcAddress() or glXGetProcAddressARB() using dlsym(RTLD_NEXT, ...). - NOTE: Since VGL interposes glXGetProcAddress() and glXGetProcAddressARB(), it has to use dlopen()/dlsym() to obtain pointers to the "real" versions of those functions. VGL subsequently calls the "real" glXGetProcAddress[ARB]() function to obtain pointers to the "real" versions of other GLX/OpenGL functions. It does the latter because certain libGL implementations (specifically, this was known to be the case with the AMD Catalyst drivers, although I'm not sure if it still is) failed to properly expose some of the OpenGL PBO functions in the LD version script for libGL.so.1, so the only way to invoke those functions was by loading them using glXGetProcAddress[ARB](). * Because gameoverlayrenderer.so intercepts dlsym(), VirtualGL's call to dlsym(RTLD_NEXT, "glXGetProcAddress[ARB]") returns a pointer to gameoverlayrenderer.so's interposed version of glXGetProcAddress[ARB](). Even if gameoverlayrenderer.so did not interpose dlsym(), then this would still occur, because it is the next library in the dynamic link order after libvglfaker.so. * When the application (the game running in Steam) calls a GLX function that VirtualGL interposes, VirtualGL calls glXGetProcAddress[ARB]() to obtain a pointer to the "real" version of that function from libGL. However, VirtualGL's pointer to glXGetProcAddress[ARB]() is actually pointing to the interposed version of that function in gameoverlayrenderer.so. * glXGetProcAddress[ARB]() in gameoverlayrenderer.so sees that it doesn't interpose the function that VirtualGL is requesting, so it apparently uses its own version of dlsym() to try to obtain a pointer to the "real" function from libGL. For reasons that aren't fully understood, gameoverlayrenderer.so's version of dlsym() returns VirtualGL's interposed version of the requested GLX/OpenGL function instead. My best guess is that gameoverlayrenderer.so's version of dlsym() is not using the RTLD_NEXT handle like it should. * VirtualGL thinks that it is getting a pointer to the "real" version of the GLX/OpenGL function, but it is actually getting a pointer to its own interposed version of that function. Thus invoking the "real" version of the function causes an infinite recursion, locking up the program or segfaulting it once the stack space is exhausted. Things I tried: * Specifying VGL_GLLIB=libGL.so.1, which causes VirtualGL to load GLX/OpenGL function symbols directly from libGL.so.1 rather than from the next library in the dynamic link order. In this case, when VirtualGL calls dlsym() to obtain the address of glXGetProcAddress[ARB](), gameoverlayrenderer.so intercepts the dlsym() call. A similar problem to the above occurs, whereby gameoverlayrenderer.so's version of dlsym() returns a pointer to VirtualGL's interposed version of glXGetProcAddress[ARB](), for reasons that aren't fully understood. * Modifying vglrun so that it adds the VirtualGL fakers to the end of the existing LD_PRELOAD environment variable rather than the beginning. I had hoped that, with this modification, I could invoke 'LD_PRELOAD=~/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so:~/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so vglrun -ldafter steam' and achieve a similar effect to the one I achieved by manually modifying the game launch scripts. However, Steam still adds ~/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so:~/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so to the end of the LD_PRELOAD variable, and things still go awry (because, since gameoverlayrenderer.so is still specified after the VGL fakers, RTLD_NEXT still picks up symbols from that library instead of libGL.) This wouldn't have been a particularly good idea anyhow, since it would have caused gameoverlayrenderer.so to be preloaded into the entire Steam process rather than just the games. * Using a TLS variable to ensure that, if VirtualGL called gameoverlayrenderer.so's version of glXGetProcAddress[ARB]() and, in turn, gameoverlayrenderer.so's version of glXGetProcAddress[ARB]() called back VirtualGL's version of glXGetProcAddress[ARB](), VirtualGL would return the "real" OpenGL/GLX symbols rather than the fake ones. However, this revealed that gameoverlayrenderer.so is never actually calling VGL's version of glXGetProcAddress[ARB](). It is apparently implementing its version of glXGetProcAddress[ARB]() using its own (presumably broken) version of dlsym(). * Avoiding the use of glXGetProcAddress[ARB]() altogether in the VGL symbol loader, i.e. using the Solaris code in faker-sym.cpp, which works more similarly to the function loader in VGL 2.4.x. This allows the program to run up until the first call to glXSwapBuffers(), but apparently VirtualGL's call to the "real" glXSwapBuffers() function is intercepted by gameoverlayrenderer.so. Its version of glXSwapBuffers() doesn't like being passed a Pbuffer handle and throws a GLX error, and for reasons not well understood, when gameoverlayrenderer.so throws this error, a segfault occurs: #0 0x00000000 in ?? () #1 0xf7666856 in ?? () from /home/drc/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so #2 0xf74b47c6 in _XError () from /lib/libX11.so.6 #3 0xf74b0ff6 in handle_error () from /lib/libX11.so.6 #4 0xf74b25c0 in _XReply () from /lib/libX11.so.6 #5 0xf74a7cf2 in XQueryTree () from /lib/libX11.so.6 #6 0xf766340a in ?? () from /home/drc/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so #7 0xf765a177 in glXSwapBuffers () from /home/drc/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so #8 0xf76c8317 in _glXSwapBuffers (drawable=23068674, dpy=0x94ac058) at /home/drc/src/vglhead/server/faker-sym.h:368 #9 vglserver::VirtualDrawable::OGLDrawable::swap (this=0x95454d0) at /home/drc/src/vglhead/server/VirtualDrawable.cpp:185 Setting VGL_TRAPX11=1 works around the segfault and allows execution to continue, but VirtualGL traps and reports numerous BadWindow and BadDrawable errors from gameoverlayrenderer.so. It does at least appear that the buffer is being swapped, despite these errors being thrown, but (predictably) the in-game overlay doesn't display. NOTE: Trying this approach with VGL_GLLIB=libGL.so.1 doesn't work, because, per above, any call to gameoverlayrenderer.so's interposed version of dlsym() will return a pointer to VirtualGL's interposed version of the requested function unless RTLD_NEXT is specified as the handle. Workarounds: * Per above, modifying the game launch scripts so that LD_PRELOAD is set to a new value which places the VGL fakers after gameoverlayrenderer.so. Problems: 1. Not all games that are affected by this issue have launch scripts. 2. This solution is not particularly user-friendly. 3. The modifications to the launch scripts may not survive an update of the games in question. * dd7b701 introduces a new (and currently undocumented) environment variable (VGL_DLSYM) that, when set to 1, will cause VGL to use the aforementioned Solaris code path, thus avoiding the use of glXGetProcAddress[ARB]() to load GLX/OpenGL symbols. This, in combination with VGL_TRAPX11=1, allows Steam games to run, but the in-game overlay doesn't work properly with this method. gameoverlayrenderer.so was designed to work properly when it intercepts calls specifically made by the Steam game, and VirtualGL was designed to work properly when it makes calls directly to libGL. In short, the only approach that allows all of the features in Steam to fully work is to reverse the LD_PRELOAD order set within Steam, per above. * 4a38fb7 allows VirtualGL to detect dynamic linker recursion issues that would cause the VGL faker to call its own interposed functions instead of the "real" GLX/OpenGL functions. This at least makes it easier to determine why the Steam game is failing. Note that I can no longer reproduce the lock-up when exiting Dota. That may have been due to my own error. Longer-term, my best advice would be to encourage Valve to change the order of LD_PRELOAD so that gameoverlayrenderer.so is put ahead of any other interposers, or to allow such behavior to be configured with an environment variable. It seems that we're not the only ones having problems with gameoverlayrenderer.so (GhostSquad57/Steam-Installer-for-Wheezy#37). On 9/13/16 2:30 PM, DRC wrote: > This is definitely related to LD_PRELOAD. What seems to be happening is > that Steam adds > ~/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so:~/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so > to the existing LD_PRELOAD variable set by vglrun, so the resulting > LD_PRELOAD variable is: > > > libdlfaker.so:libvglfaker.so:~/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so:~/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so > > Because I have no access to the gameoverlayrenderer.so source, I'm not > sure exactly what that interposer is doing, but in my testing, it is > clear that gameoverlayrenderer.so has to be preloaded ahead of VirtualGL > for things to work properly. For instance, if I edit > > ~/.local/share/Steam/steamapps/common/dota 2 beta/game/dota.sh > > and add > > export > LD_PRELOAD=~/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so:~/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so:libdlfaker.so:libvglfaker.so > > to the top, I can make Dota 2 launch and play correctly. This exposes a > second issue whereby the game locks up when exiting it (still > investigating that.) > > As far as I can tell, the LD_PRELOAD variable is modified within some > non-hackable part of Steam. I think a good argument could be made that > this is incorrect behavior on Steam's part. gameoverlayrenderer.so > should be as close to the application in the preload order as possible, > and other interposers should be placed after it. > > Still investigating how I might be able to work around this within > VirtualGL, but I wanted to share my findings thus far. Note that I also > tried disabling the in-game overlay, in hopes that that would make Steam > stop trying to preload gameoverlayrenderer.so, but no such luck. :| > I'll keep you posted. > > > On 6/28/16 12:22 PM, Marco Marino wrote: >> I'm able to play stream, but games nit working.. Please can you create >> a steam account and try to play half life2 or dota?? They are free to >> play games. >> Thamk you >> >> Il 28 Giu 2016 19:19, "DRC" <dco...@us... >> <mailto:dco...@us...>> ha scritto: >> >> Did installing both RPMs work? I am able to launch Steam with no errors >> on F22 using the same packages you are using, and with both VirtualGL >> RPMs installed: >> >> VirtualGL-2.5-20160215.x86_64 >> VirtualGL-2.5-20160215.i386 >> >> But I have no ability to actually test games, as I do not have a Steam >> account. >> >> >> On 6/26/16 11:33 AM, DRC wrote: >> > No, on RPM-based systems, you can simply co-install the i386 and x86_64 >> > RPMs. >> >> ------------------------------------------------------------------------------ >> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San >> Francisco, CA to explore cutting-edge tech and listen to tech luminaries >> present their vision of the future. This family event has something for >> everyone, including kids. Get more information and register today. >> http://sdm.link/attshape >> _______________________________________________ >> VirtualGL-Devel mailing list >> Vir...@li... >> <mailto:Vir...@li...> >> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel >> >> >> >> ------------------------------------------------------------------------------ >> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San >> Francisco, CA to explore cutting-edge tech and listen to tech luminaries >> present their vision of the future. This family event has something for >> everyone, including kids. Get more information and register today. >> http://sdm.link/attshape >> >> >> >> _______________________________________________ >> VirtualGL-Devel mailing list >> Vir...@li... >> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel >> |
From: DRC <dco...@us...> - 2016-09-13 19:30:20
|
This is definitely related to LD_PRELOAD. What seems to be happening is that Steam adds ~/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so:~/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so to the existing LD_PRELOAD variable set by vglrun, so the resulting LD_PRELOAD variable is: libdlfaker.so:libvglfaker.so:~/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so:~/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so Because I have no access to the gameoverlayrenderer.so source, I'm not sure exactly what that interposer is doing, but in my testing, it is clear that gameoverlayrenderer.so has to be preloaded ahead of VirtualGL for things to work properly. For instance, if I edit ~/.local/share/Steam/steamapps/common/dota 2 beta/game/dota.sh and add export LD_PRELOAD=~/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so:~/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so:libdlfaker.so:libvglfaker.so to the top, I can make Dota 2 launch and play correctly. This exposes a second issue whereby the game locks up when exiting it (still investigating that.) As far as I can tell, the LD_PRELOAD variable is modified within some non-hackable part of Steam. I think a good argument could be made that this is incorrect behavior on Steam's part. gameoverlayrenderer.so should be as close to the application in the preload order as possible, and other interposers should be placed after it. Still investigating how I might be able to work around this within VirtualGL, but I wanted to share my findings thus far. Note that I also tried disabling the in-game overlay, in hopes that that would make Steam stop trying to preload gameoverlayrenderer.so, but no such luck. :| I'll keep you posted. On 6/28/16 12:22 PM, Marco Marino wrote: > I'm able to play stream, but games nit working.. Please can you create > a steam account and try to play half life2 or dota?? They are free to > play games. > Thamk you > > Il 28 Giu 2016 19:19, "DRC" <dco...@us... > <mailto:dco...@us...>> ha scritto: > > Did installing both RPMs work? I am able to launch Steam with no errors > on F22 using the same packages you are using, and with both VirtualGL > RPMs installed: > > VirtualGL-2.5-20160215.x86_64 > VirtualGL-2.5-20160215.i386 > > But I have no ability to actually test games, as I do not have a Steam > account. > > > On 6/26/16 11:33 AM, DRC wrote: > > No, on RPM-based systems, you can simply co-install the i386 and x86_64 > > RPMs. > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > VirtualGL-Devel mailing list > Vir...@li... > <mailto:Vir...@li...> > https://lists.sourceforge.net/lists/listinfo/virtualgl-devel > > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > > > > _______________________________________________ > VirtualGL-Devel mailing list > Vir...@li... > https://lists.sourceforge.net/lists/listinfo/virtualgl-devel > |
From: Nathan K. <nat...@sp...> - 2016-09-13 19:28:19
|
On 13/09/16 03:02 PM, DRC wrote: > Cool. Did you get a chance to ask them for a list of applications that > were affected by this? We only confirmed the bug and fix with ANSYS Maxwell and ANSYS HFSS, though I think it probable other ANSYS modules were affected. -Nathan |
From: DRC <dco...@us...> - 2016-09-13 19:02:24
|
Cool. Did you get a chance to ask them for a list of applications that were affected by this? On 9/7/16 10:07 AM, Nathan Kidd wrote: > On 09/08/16 12:13 AM, DRC wrote: >> A proper fix for this, resulting from today's remote debugging session, >> has been pushed to master. Please see >> >> https://github.com/VirtualGL/virtualgl/commit/a143bf303940b46bf8b9a993907ac352709871b8 >> >> for my analysis and a roll-up of past MainWin and/or ANSYS issues that >> are directly related to this or have similar causality. Let me know if >> there are further problems. > > FYI QA has been testing this patch for a few weeks; no issues have come up. > > -Nathan |
From: Nathan K. <nat...@sp...> - 2016-09-07 15:07:25
|
On 09/08/16 12:13 AM, DRC wrote: > A proper fix for this, resulting from today's remote debugging session, > has been pushed to master. Please see > > https://github.com/VirtualGL/virtualgl/commit/a143bf303940b46bf8b9a993907ac352709871b8 > > for my analysis and a roll-up of past MainWin and/or ANSYS issues that > are directly related to this or have similar causality. Let me know if > there are further problems. FYI QA has been testing this patch for a few weeks; no issues have come up. -Nathan |
From: DRC <dco...@us...> - 2016-08-10 13:56:13
|
On 8/9/16 9:25 PM, Nathan Kidd wrote: > In my experience the _init()/_fini() calling sequence is at least system > dependent (I could reproduce things on one Linux distro, not another), > and I don't suppose Linux is that different from Solaris when it comes > to the insanity described here: > https://blogs.oracle.com/rie/entry/init_and_fini_processing_who Yeah, and I strongly suspect that the faker's C++ global static destructor is called from within the same function that would call whatever C destructor I would implement, which is probably why I opted for the C++ destructor approach to begin with. As far as Solaris dynamic linking, don't get me started ... :| Literally half of the time I spent at Sun was spent chasing down Solaris-specific issues (at the time, we still had to support Solaris 8, so I couldn't even rely on things like mktemp and which and bash being available. I do not miss those days.) One thing I will say is that my assertions regarding shared memory may be out of date, because of the above. Would probably be good to re-test that. |
From: Nathan K. <nat...@sp...> - 2016-08-10 02:25:45
|
On 09/08/16 04:31 PM, DRC wrote: > One thing I haven't investigated is whether creating our own equivalent > of _fini() would change the destruction order. At one time, I couldn't > set up a global destructor function because the versions of Solaris and > Sun Studio we were supporting didn't allow for that, but that is no > longer the case. However, unless it would change the destruction order, > thus guaranteeing that the faker is destroyed last, then it wouldn't > allow us to simplify anything. In my experience the _init()/_fini() calling sequence is at least system dependent (I could reproduce things on one Linux distro, not another), and I don't suppose Linux is that different from Solaris when it comes to the insanity described here: https://blogs.oracle.com/rie/entry/init_and_fini_processing_who > And yes, I get how deadYet checks create a developer-proofness problem, > but realistically, how often do new X11 functions get introduced into > the VirtualGL code? No point beating our heads against the wall to make > a very rare case slightly easier. It takes exactly two seconds to > copy/paste the deadYet check from another function. The deadYet check > is just one of several checks that we have to perform on a > function-by-function basis, such as making sure that the XCB functions > aren't interposed if they are called within the body of an > already-interposed X11 function, and in some cases making sure that the > X11 functions aren't interposed if they are called within the body of an > already-interposed GLX function. Given that I do most of the > development on VirtualGL, I certainly want to make it as straightforward > as possible to develop, but there's only so much that can be done in > this case. Fair enough. -Nathan |
From: DRC <dco...@us...> - 2016-08-09 20:31:25
|
On 8/9/16 1:59 PM, Nathan Kidd wrote: > On 09/08/16 02:21 PM, DRC wrote: >> The primary reason the destructor exists is to free the shared memory >> segment that VirtualGL uses for its GUI interface. Shared memory >> doesn't get freed automatically. > > If that were the only gotcha, the destructor could handle the shm > segment only, with the GUI activation doing a single "am I dead" check. > It would be nice if every new faker hook/resource access didn't have to > remember about deadYet checks. The whole issue is pretty unintuitive > from a code POV. "I said exit() what do you mean I'm not dead?" Yeah, but... Once the shared memory segment is destroyed, then we no longer have access to the faker config, and if we no longer have access to the faker config, then it would be very difficult to keep the interposer running with any semblance of normalcy. That's the problem that launched this whole discussion to begin with. The XCB interposer was trying to access fconfig after the singleton had been destroyed. Also, as indicated in the commit message, we really cannot rely on the correct behavior of mutexes when MainWin is shutting down. One thing I haven't investigated is whether creating our own equivalent of _fini() would change the destruction order. At one time, I couldn't set up a global destructor function because the versions of Solaris and Sun Studio we were supporting didn't allow for that, but that is no longer the case. However, unless it would change the destruction order, thus guaranteeing that the faker is destroyed last, then it wouldn't allow us to simplify anything. And yes, I get how deadYet checks create a developer-proofness problem, but realistically, how often do new X11 functions get introduced into the VirtualGL code? No point beating our heads against the wall to make a very rare case slightly easier. It takes exactly two seconds to copy/paste the deadYet check from another function. The deadYet check is just one of several checks that we have to perform on a function-by-function basis, such as making sure that the XCB functions aren't interposed if they are called within the body of an already-interposed X11 function, and in some cases making sure that the X11 functions aren't interposed if they are called within the body of an already-interposed GLX function. Given that I do most of the development on VirtualGL, I certainly want to make it as straightforward as possible to develop, but there's only so much that can be done in this case. |
From: Nathan K. <nat...@sp...> - 2016-08-09 18:59:46
|
On 09/08/16 02:21 PM, DRC wrote: > The primary reason the destructor exists is to free the shared memory > segment that VirtualGL uses for its GUI interface. Shared memory > doesn't get freed automatically. If that were the only gotcha, the destructor could handle the shm segment only, with the GUI activation doing a single "am I dead" check. It would be nice if every new faker hook/resource access didn't have to remember about deadYet checks. The whole issue is pretty unintuitive from a code POV. "I said exit() what do you mean I'm not dead?" -Nathan |
From: DRC <dco...@us...> - 2016-08-09 18:21:16
|
The primary reason the destructor exists is to free the shared memory segment that VirtualGL uses for its GUI interface. Shared memory doesn't get freed automatically. On 8/9/16 1:09 PM, Nathan Kidd wrote: > On 09/08/16 12:13 AM, DRC wrote: >> A proper fix for this, resulting from today's remote debugging session, >> has been pushed to master. Please see >> >> https://github.com/VirtualGL/virtualgl/commit/a143bf303940b46bf8b9a993907ac352709871b8 >> >> for my analysis and a roll-up of past MainWin and/or ANSYS issues that >> are directly related to this or have similar causality. Let me know if >> there are further problems. > > Thanks. > > Re: "This issue may have also affected other > +applications that use MainWin." > > I know for a fact ANSYS Maxwell was also affected, and expect others. > I'll ask QA when they test this instead of the patches I've been carrying. > > I've been pondering what benefit we actually get from the VGL > destructors. Once the process exits all memory will be freed. Once any > X sockets disconnect the X server will free any associated resources. > We wouldn't need any isDead resource guards if we didn't kill anything > and let the OS/X server handle it. Can you think of a down side? > > -Nathan |
From: Nathan K. <nat...@sp...> - 2016-08-09 18:09:48
|
On 09/08/16 12:13 AM, DRC wrote: > A proper fix for this, resulting from today's remote debugging session, > has been pushed to master. Please see > > https://github.com/VirtualGL/virtualgl/commit/a143bf303940b46bf8b9a993907ac352709871b8 > > for my analysis and a roll-up of past MainWin and/or ANSYS issues that > are directly related to this or have similar causality. Let me know if > there are further problems. Thanks. Re: "This issue may have also affected other +applications that use MainWin." I know for a fact ANSYS Maxwell was also affected, and expect others. I'll ask QA when they test this instead of the patches I've been carrying. I've been pondering what benefit we actually get from the VGL destructors. Once the process exits all memory will be freed. Once any X sockets disconnect the X server will free any associated resources. We wouldn't need any isDead resource guards if we didn't kill anything and let the OS/X server handle it. Can you think of a down side? -Nathan |
From: DRC <dco...@us...> - 2016-08-09 04:14:05
|
A proper fix for this, resulting from today's remote debugging session, has been pushed to master. Please see https://github.com/VirtualGL/virtualgl/commit/a143bf303940b46bf8b9a993907ac352709871b8 for my analysis and a roll-up of past MainWin and/or ANSYS issues that are directly related to this or have similar causality. Let me know if there are further problems. DRC On 7/8/16 9:33 AM, Nathan Kidd wrote: > On 07/07/16 06:01 PM, DRC wrote: >> I'll need to sit down and focus on this when I have no distractions, >> because it raises a couple of red flags in my mind. Stand by. > > Some things I mulled over, not long enough or distraction-less enough: > > 1. this no longer blocks any globalMutex-checking caller from using VGL > resources during cleanup() > > 2. but XFree() is the only call, besides (newly) xcb_poll_for_event() > attempting to use this guard for resource access and they're both via > isDead() which will do the right thing (i.e. not access if dead) > > 3. which makes me think about whether we need isDead protection for all > resource access (since _fini() proves we aren't dead just because we > said exit(1). But that way seems cumbersome and non-performant, not to > mention and the way of more potential deadlocks. > > Worthy of a long think indeed. > > /me returns to other distractions |
From: DRC <dco...@us...> - 2016-07-17 23:22:00
|
Created a GitHub issue to track this: https://github.com/VirtualGL/virtualgl/issues/25 On 7/17/16 6:21 PM, DRC wrote: > I've reproduced the problem, but I'm clueless as to what's causing it. > Symptomatically, what's happening is that, when the VGL faker attempts > to load a symbol from libGL using dlsym(), dlsym() returns the > interposed symbol from the VGL faker instead. No idea why, but it seems > that Steam is somehow interfering with VGL's function dispatching > mechanism. When I've seen such problems in the past with other > applications, I was able to work around them by setting > VGL_GLLIB=/usr/lib64/libGL.so.1 or VGL_GLLIB=/usr/lib/libGL.so.1, which > forces VirtualGL to load the "real" OpenGL functions directly from the > underlying OpenGL library instead of relying on the dynamic loader to > pick those symbols from the next library in the search order. That > doesn't work with Steam, however. > > I've spent nearly two full days' work looking at this, but I'm afraid > that there isn't much else I can do without help from the community. > With a closed-source application like Steam, it could easily take me 30 > or 40 more hours of hacking to determine why it isn't working with > VirtualGL, and even if I can determine exactly what's causing the issue, > sometimes issues like these still aren't solvable. If someone else is > willing to take the lead on this, then I'd be more than happy to liaise > with them, but for me personally, I can't spare those hours from the > General Fund to donate to this cause, so I'd need the work to be > sponsored financially if I'm going to solve it without community help. > > I want to support the gaming market as much as I can, but unfortunately, > the reality is that my business model makes it difficult to do so. I > get paid generally by corporations or other organizations who are using > VirtualGL internally or selling it as part of their product, and these > customers are primarily focused on CAD and visualization applications. > > > On 6/28/16 12:22 PM, Marco Marino wrote: >> I'm able to play stream, but games nit working.. Please can you create >> a steam account and try to play half life2 or dota?? They are free to >> play games. >> Thamk you > |
From: DRC <dco...@us...> - 2016-07-17 23:21:13
|
I've reproduced the problem, but I'm clueless as to what's causing it. Symptomatically, what's happening is that, when the VGL faker attempts to load a symbol from libGL using dlsym(), dlsym() returns the interposed symbol from the VGL faker instead. No idea why, but it seems that Steam is somehow interfering with VGL's function dispatching mechanism. When I've seen such problems in the past with other applications, I was able to work around them by setting VGL_GLLIB=/usr/lib64/libGL.so.1 or VGL_GLLIB=/usr/lib/libGL.so.1, which forces VirtualGL to load the "real" OpenGL functions directly from the underlying OpenGL library instead of relying on the dynamic loader to pick those symbols from the next library in the search order. That doesn't work with Steam, however. I've spent nearly two full days' work looking at this, but I'm afraid that there isn't much else I can do without help from the community. With a closed-source application like Steam, it could easily take me 30 or 40 more hours of hacking to determine why it isn't working with VirtualGL, and even if I can determine exactly what's causing the issue, sometimes issues like these still aren't solvable. If someone else is willing to take the lead on this, then I'd be more than happy to liaise with them, but for me personally, I can't spare those hours from the General Fund to donate to this cause, so I'd need the work to be sponsored financially if I'm going to solve it without community help. I want to support the gaming market as much as I can, but unfortunately, the reality is that my business model makes it difficult to do so. I get paid generally by corporations or other organizations who are using VirtualGL internally or selling it as part of their product, and these customers are primarily focused on CAD and visualization applications. On 6/28/16 12:22 PM, Marco Marino wrote: > I'm able to play stream, but games nit working.. Please can you create > a steam account and try to play half life2 or dota?? They are free to > play games. > Thamk you |
From: DRC <dco...@us...> - 2016-07-17 01:48:56
|
I was never able to exactly reproduce the problem, but I think I came close. My attempt is in a temporary branch called "yamwb" (Yet Another MainWin Bug) on GitHub: git clone https://github.com/VirtualGL/virtualgl.git cd virtualgl git checkout yamwb git checkout HEAD~1 The penultimate commit in that branch (https://github.com/VirtualGL/virtualgl/commit/ea45a4121aeb26e70ff3da3c0dcf4af1f156e031) creates a shared library with _init() and _fini() functions, calls XGetSelectionOwner() in the body of _fini(), and links the shared lib with GLXspheres. When running this modified version of GLXspheres in VGL, it doesn't actually lock up, but it does demonstrate a failure in CriticalSection::lock() that occurs when one of VirtualGL's interposed functions is called from another shared lib's global destructor. Basically, at that point in the execution, we can't rely on any mutexes except the global one, and that could very well be what's causing MainWin to lock up. Basically, the issue is that, by the time the shared lib's destructor function is called, the GlobalCleanup destructor in VGL's faker has already been called (and if the faker had a global destructor function, it would have already been called as well.) At that point, it is difficult or impossible for VGL to operate with any semblance of normalcy, particularly given that mutexes don't work properly. So how is VGL supposed to sanely handle an application calling an interposed X11 or OpenGL function after the interposer itself has been essentially shut down? If we're lucky and this is just confined to the XCB interposer, meaning that fixing it is a simple matter of disabling said interposer, then do git checkout yamwb to see my proposed solution (https://github.com/VirtualGL/virtualgl/commit/5328fe5c0d725b4b04c926aaf53eb657548a9028). Symptomatically, what happens is as follows: (1) GLXspheres returns from main(). (2) GlobalCleanup::~GlobalCleanup() is called in the faker. (3) _fini() is called in the shared library. (4) _fini() calls XGetSelectionOwner() [not interposed]. (5) XGetSelectionOwner() calls xcb_poll_for_event() [interposed]. (6) The interposed xcb_poll_for_event() function attempts to access fconfig to read the status of fconfig.fakeXCB. (7) fconfig_instance() attempts to lock the mutex guarding its singleton instance. (8) The CriticalSection lock fails and attempts to throw an error. NOTE: This is where MainWin locks up, but my modified version of GLXspheres doesn't. Rather, the error is caught by the catch() handler in xcb_poll_for_event(), safeExit() is called, and the application exits without returning from XGetSelectionOwner() or _fini(). But that's still incorrect behavior, because _fini() never returns. What the proposed solution does: -- It sets the faker level to 1 within the body of GlobalCleanup::~GlobalCleanup(), effectively disabling any further XCB interposition. -- It re-arranges the if() statements within faker-xcb.cpp so that the faker level is checked prior to attempting to access the FakerConfig singleton. That eliminates the problem with my test application, but you'll have to tell me whether it fixes the problem with MainWin or not. DRC On 7/11/16 4:34 PM, Nathan Kidd wrote: > On 11/07/16 03:54 PM, DRC wrote: >> I need to be able to reproduce this before I can fix it, but my attempts >> to reproduce it by adding a destructor to GLXspheres and calling >> XGetSelectionOwner() within the destructor failed. I also tried calling >> xcb_poll_for_event() within the body of my destructor function, but it >> just returned NULL without doing anything. > > Does it make a difference if you try to do X things from a separate SO's > _fini()? > >> Please help me understand exactly what's going on here and how I can >> reproduce the problem without using MainWin. > > Ha, "reproduce the problem without using MainWin", the story of my life. > It's going to take some time before I'll get a chance to try. |
From: Nathan K. <nat...@sp...> - 2016-07-11 21:35:04
|
On 11/07/16 03:54 PM, DRC wrote: > I need to be able to reproduce this before I can fix it, but my attempts > to reproduce it by adding a destructor to GLXspheres and calling > XGetSelectionOwner() within the destructor failed. I also tried calling > xcb_poll_for_event() within the body of my destructor function, but it > just returned NULL without doing anything. Does it make a difference if you try to do X things from a separate SO's _fini()? > Please help me understand exactly what's going on here and how I can > reproduce the problem without using MainWin. Ha, "reproduce the problem without using MainWin", the story of my life. It's going to take some time before I'll get a chance to try. -Nathan |
From: DRC <dco...@us...> - 2016-07-11 19:54:45
|
I need to be able to reproduce this before I can fix it, but my attempts to reproduce it by adding a destructor to GLXspheres and calling XGetSelectionOwner() within the destructor failed. I also tried calling xcb_poll_for_event() within the body of my destructor function, but it just returned NULL without doing anything. Please help me understand exactly what's going on here and how I can reproduce the problem without using MainWin. On 7/8/16 9:33 AM, Nathan Kidd wrote: > On 07/07/16 06:01 PM, DRC wrote: >> I'll need to sit down and focus on this when I have no distractions, >> because it raises a couple of red flags in my mind. Stand by. > Some things I mulled over, not long enough or distraction-less enough: > > 1. this no longer blocks any globalMutex-checking caller from using VGL > resources during cleanup() > > 2. but XFree() is the only call, besides (newly) xcb_poll_for_event() > attempting to use this guard for resource access and they're both via > isDead() which will do the right thing (i.e. not access if dead) > > 3. which makes me think about whether we need isDead protection for all > resource access (since _fini() proves we aren't dead just because we > said exit(1). But that way seems cumbersome and non-performant, not to > mention and the way of more potential deadlocks. > > Worthy of a long think indeed. > > /me returns to other distractions > > |
From: Nathan K. <nat...@sp...> - 2016-07-08 14:34:03
|
On 07/07/16 06:01 PM, DRC wrote: > I'll need to sit down and focus on this when I have no distractions, > because it raises a couple of red flags in my mind. Stand by. Some things I mulled over, not long enough or distraction-less enough: 1. this no longer blocks any globalMutex-checking caller from using VGL resources during cleanup() 2. but XFree() is the only call, besides (newly) xcb_poll_for_event() attempting to use this guard for resource access and they're both via isDead() which will do the right thing (i.e. not access if dead) 3. which makes me think about whether we need isDead protection for all resource access (since _fini() proves we aren't dead just because we said exit(1). But that way seems cumbersome and non-performant, not to mention and the way of more potential deadlocks. Worthy of a long think indeed. /me returns to other distractions |
From: DRC <dco...@us...> - 2016-07-07 22:01:25
|
I'll need to sit down and focus on this when I have no distractions, because it raises a couple of red flags in my mind. Stand by. On 7/7/16 4:08 PM, Nathan Kidd wrote: > On 04/07/16 10:14 PM, Nathan Kidd wrote: >> >> This naive patch works around this specific case, though obviously it >> isn't a general solution: >> >> diff --git a/server/faker-xcb.cpp b/server/faker-xcb.cpp >> index f6f2d23..661cd1f 100644 >> --- a/server/faker-xcb.cpp >> +++ b/server/faker-xcb.cpp >> @@ -224,7 +224,7 @@ xcb_generic_event_t >> *xcb_poll_for_event(xcb_connection_t *conn) >> >> TRY(); >> >> - if((e=_xcb_poll_for_event(conn))!=NULL && fconfig.fakeXCB >> + if((e=_xcb_poll_for_event(conn))!=NULL && !isDead() && >> fconfig.fakeXCB >> && vglfaker::getFakerLevel()==0) >> handleXCBEvent(conn, e); >> > > Which exposes the below deadlock, caused by safeExit holding the global > lock while it tries to kill the X11Trans thread which is blocked waiting > for the global lock. > >> Thread 2 (Thread 0x7fca26e2e700 (LWP 18636)): >> #0 0x0000003e9840e51d in __lll_lock_wait () from /lib64/libpthread.so.0 >> #1 0x0000003e9840a136 in _L_lock_870 () from /lib64/libpthread.so.0 >> #2 0x0000003e9840a02f in pthread_mutex_lock () from /lib64/libpthread.so.0 >> #3 0x00007fca2bb67f6c in vglutil::CriticalSection::lock (this=0x1378060, errorCheck=false) >> at virtualgl/util/Mutex.cpp:186 >> #4 0x00007fca2baf1b2d in isDead () at virtualgl/server/faker.h:76 >> #5 0x00007fca2baf2eed in xcb_poll_for_event (conn=0x14c50a0) >> at virtualgl/server/faker-xcb.cpp:227 >> #6 0x0000003e9b0426b8 in poll_for_event () from /lib64/libX11.so.6 >> #7 0x0000003e9b043108 in _XReply () from /lib64/libX11.so.6 >> #8 0x0000003e9b03ea2d in XSync () from /lib64/libX11.so.6 >> #9 0x00007fca2bb0d61b in fbx_write (fb=0x14bff18, srcX_=0, srcY_=0, dstX_=0, dstY_=0, width_=800, height_=800) >> at virtualgl/util/fbx.c:510 >> #10 0x00007fca2bb0bd7f in vglcommon::FBXFrame::redraw (this=0x14bfdf0) >> at virtualgl/common/Frame.cpp:659 >> #11 0x00007fca2bb04428 in vglserver::X11Trans::run (this=0x14bfae0) >> at virtualgl/server/X11Trans.cpp:52 >> #12 0x00007fca2bb68665 in vglutil::Thread::threadFunc (param=0x14bfae0) >> at virtualgl/util/Thread.cpp:92 >> #13 0x0000003e98407ee5 in start_thread () from /lib64/libpthread.so.0 >> #14 0x0000003e97cf4d1d in clone () from /lib64/libc.so.6 >> >> Thread 1 (Thread 0x7fca2ba6c840 (LWP 18609)): >> #0 0x0000003e98409237 in pthread_join () from /lib64/libpthread.so.0 >> #1 0x00007fca2bb6849f in vglutil::Thread::stop (this=0x14bfdd0) >> at virtualgl/util/Thread.cpp:52 >> #2 0x00007fca2bb04cc7 in vglserver::X11Trans::~X11Trans (this=0x14bfae0, __in_chrg=<optimized out>) >> at virtualgl/server/X11Trans.h:37 >> #3 0x00007fca2bb04eb8 in vglserver::X11Trans::~X11Trans (this=0x14bfae0, __in_chrg=<optimized out>) >> at virtualgl/server/X11Trans.h:42 >> #4 0x00007fca2bb0102e in vglserver::VirtualWin::~VirtualWin (this=0x1458300, __in_chrg=<optimized out>) >> at virtualgl/server/VirtualWin.cpp:92 >> ---Type <return> to continue, or q <return> to quit--- >> #5 0x00007fca2bacab07 in vglserver::WindowHash::detach (this=0x1419fd0, entry=0x141a040) >> at virtualgl/server/WindowHash.h:153 >> #6 0x00007fca2bacb898 in vglserver::Hash<char*, unsigned long, vglserver::VirtualWin*>::killEntry ( >> this=0x1419fd0, entry=0x141a040) at virtualgl/server/Hash.h:137 >> #7 0x00007fca2bacb93e in vglserver::Hash<char*, unsigned long, vglserver::VirtualWin*>::kill (this=0x1419fd0) >> at virtualgl/server/Hash.h:44 >> #8 0x00007fca2bac93f5 in vglfaker::cleanup () at virtualgl/server/faker.cpp:56 >> #9 0x00007fca2bac9461 in vglfaker::safeExit (retcode=1) at virtualgl/server/faker.cpp:71 >> #10 0x00007fca2badf763 in glXMakeContextCurrent (dpy=0x1388680, draw=4194306, read=4194306, ctx=0x141a160) >> at virtualgl/server/faker-glx.cpp:1841 >> #11 0x0000003ea5a27213 in fgSetWindow () from /lib64/libglut.so.3 >> #12 0x0000003ea5a26154 in fgDestroyWindow () from /lib64/libglut.so.3 >> #13 0x0000003ea5a22648 in glutMainLoopEvent () from /lib64/libglut.so.3 >> #14 0x0000003ea5a22f89 in glutMainLoop () from /lib64/libglut.so.3 >> #15 0x00000000004011bf in main () > > Avoided by additional patch, attached. > > -Nathan > > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > > > > _______________________________________________ > VirtualGL-Devel mailing list > Vir...@li... > https://lists.sourceforge.net/lists/listinfo/virtualgl-devel > |
From: Nathan K. <nat...@sp...> - 2016-07-07 21:08:20
|
On 04/07/16 10:14 PM, Nathan Kidd wrote: > > This naive patch works around this specific case, though obviously it > isn't a general solution: > > diff --git a/server/faker-xcb.cpp b/server/faker-xcb.cpp > index f6f2d23..661cd1f 100644 > --- a/server/faker-xcb.cpp > +++ b/server/faker-xcb.cpp > @@ -224,7 +224,7 @@ xcb_generic_event_t > *xcb_poll_for_event(xcb_connection_t *conn) > > TRY(); > > - if((e=_xcb_poll_for_event(conn))!=NULL && fconfig.fakeXCB > + if((e=_xcb_poll_for_event(conn))!=NULL && !isDead() && > fconfig.fakeXCB > && vglfaker::getFakerLevel()==0) > handleXCBEvent(conn, e); > Which exposes the below deadlock, caused by safeExit holding the global lock while it tries to kill the X11Trans thread which is blocked waiting for the global lock. > Thread 2 (Thread 0x7fca26e2e700 (LWP 18636)): > #0 0x0000003e9840e51d in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x0000003e9840a136 in _L_lock_870 () from /lib64/libpthread.so.0 > #2 0x0000003e9840a02f in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x00007fca2bb67f6c in vglutil::CriticalSection::lock (this=0x1378060, errorCheck=false) > at virtualgl/util/Mutex.cpp:186 > #4 0x00007fca2baf1b2d in isDead () at virtualgl/server/faker.h:76 > #5 0x00007fca2baf2eed in xcb_poll_for_event (conn=0x14c50a0) > at virtualgl/server/faker-xcb.cpp:227 > #6 0x0000003e9b0426b8 in poll_for_event () from /lib64/libX11.so.6 > #7 0x0000003e9b043108 in _XReply () from /lib64/libX11.so.6 > #8 0x0000003e9b03ea2d in XSync () from /lib64/libX11.so.6 > #9 0x00007fca2bb0d61b in fbx_write (fb=0x14bff18, srcX_=0, srcY_=0, dstX_=0, dstY_=0, width_=800, height_=800) > at virtualgl/util/fbx.c:510 > #10 0x00007fca2bb0bd7f in vglcommon::FBXFrame::redraw (this=0x14bfdf0) > at virtualgl/common/Frame.cpp:659 > #11 0x00007fca2bb04428 in vglserver::X11Trans::run (this=0x14bfae0) > at virtualgl/server/X11Trans.cpp:52 > #12 0x00007fca2bb68665 in vglutil::Thread::threadFunc (param=0x14bfae0) > at virtualgl/util/Thread.cpp:92 > #13 0x0000003e98407ee5 in start_thread () from /lib64/libpthread.so.0 > #14 0x0000003e97cf4d1d in clone () from /lib64/libc.so.6 > > Thread 1 (Thread 0x7fca2ba6c840 (LWP 18609)): > #0 0x0000003e98409237 in pthread_join () from /lib64/libpthread.so.0 > #1 0x00007fca2bb6849f in vglutil::Thread::stop (this=0x14bfdd0) > at virtualgl/util/Thread.cpp:52 > #2 0x00007fca2bb04cc7 in vglserver::X11Trans::~X11Trans (this=0x14bfae0, __in_chrg=<optimized out>) > at virtualgl/server/X11Trans.h:37 > #3 0x00007fca2bb04eb8 in vglserver::X11Trans::~X11Trans (this=0x14bfae0, __in_chrg=<optimized out>) > at virtualgl/server/X11Trans.h:42 > #4 0x00007fca2bb0102e in vglserver::VirtualWin::~VirtualWin (this=0x1458300, __in_chrg=<optimized out>) > at virtualgl/server/VirtualWin.cpp:92 > ---Type <return> to continue, or q <return> to quit--- > #5 0x00007fca2bacab07 in vglserver::WindowHash::detach (this=0x1419fd0, entry=0x141a040) > at virtualgl/server/WindowHash.h:153 > #6 0x00007fca2bacb898 in vglserver::Hash<char*, unsigned long, vglserver::VirtualWin*>::killEntry ( > this=0x1419fd0, entry=0x141a040) at virtualgl/server/Hash.h:137 > #7 0x00007fca2bacb93e in vglserver::Hash<char*, unsigned long, vglserver::VirtualWin*>::kill (this=0x1419fd0) > at virtualgl/server/Hash.h:44 > #8 0x00007fca2bac93f5 in vglfaker::cleanup () at virtualgl/server/faker.cpp:56 > #9 0x00007fca2bac9461 in vglfaker::safeExit (retcode=1) at virtualgl/server/faker.cpp:71 > #10 0x00007fca2badf763 in glXMakeContextCurrent (dpy=0x1388680, draw=4194306, read=4194306, ctx=0x141a160) > at virtualgl/server/faker-glx.cpp:1841 > #11 0x0000003ea5a27213 in fgSetWindow () from /lib64/libglut.so.3 > #12 0x0000003ea5a26154 in fgDestroyWindow () from /lib64/libglut.so.3 > #13 0x0000003ea5a22648 in glutMainLoopEvent () from /lib64/libglut.so.3 > #14 0x0000003ea5a22f89 in glutMainLoop () from /lib64/libglut.so.3 > #15 0x00000000004011bf in main () Avoided by additional patch, attached. -Nathan |