virtualgl-devel — VirtualGL Developer Discussion (moved to Google Groups-- see http://www.VirtualGL.org/About/MailingLists)

[VirtualGL-Devel] VirtualGL and TurboVNC mailing lists have moved to Google Groups

[DRC <dco...@us...>]

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

[VirtualGL-Devel] 10 bpc support - RGB10_A2

[Antoine M. <an...@na...>]

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

[VirtualGL-Devel] VirtualGL 2.5.2 has been released

[DRC <dco...@us...>]

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/

[VirtualGL-Devel] TurboVNC and VirtualGL continuous integration systems are now online

[DRC <dco...@us...>]

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

[VirtualGL-Devel] VirtualGL 2.5.1 has been released

[DRC <dco...@us...>]

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

Re: [VirtualGL-Devel] VirtualGL and steam

[DRC <dco...@us...>]

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

Re: [VirtualGL-Devel] VirtualGL and steam

[DRC <dco...@us...>]

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
> 

Re: [VirtualGL-Devel] Fconfig deadlock from _fini()

[Nathan K. <nat...@sp...>]

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

Re: [VirtualGL-Devel] Fconfig deadlock from _fini()

[DRC <dco...@us...>]

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

Re: [VirtualGL-Devel] Fconfig deadlock from _fini()

[Nathan K. <nat...@sp...>]

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

Re: [VirtualGL-Devel] Fconfig deadlock from _fini()

[DRC <dco...@us...>]

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.

Re: [VirtualGL-Devel] Fconfig deadlock from _fini()

[Nathan K. <nat...@sp...>]

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

Re: [VirtualGL-Devel] Fconfig deadlock from _fini()

[DRC <dco...@us...>]

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.

Re: [VirtualGL-Devel] Fconfig deadlock from _fini()

[Nathan K. <nat...@sp...>]

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

Re: [VirtualGL-Devel] Fconfig deadlock from _fini()

[DRC <dco...@us...>]

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

Re: [VirtualGL-Devel] Fconfig deadlock from _fini()

[Nathan K. <nat...@sp...>]

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

Re: [VirtualGL-Devel] Fconfig deadlock from _fini()

[DRC <dco...@us...>]

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

Re: [VirtualGL-Devel] VirtualGL and steam

[DRC <dco...@us...>]

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
> 

Re: [VirtualGL-Devel] VirtualGL and steam

[DRC <dco...@us...>]

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

Re: [VirtualGL-Devel] Fconfig deadlock from _fini()

[DRC <dco...@us...>]

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.

Re: [VirtualGL-Devel] Fconfig deadlock from _fini()

[Nathan K. <nat...@sp...>]

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

Re: [VirtualGL-Devel] Fconfig deadlock from _fini()

[DRC <dco...@us...>]

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

Re: [VirtualGL-Devel] Fconfig deadlock from _fini()

[Nathan K. <nat...@sp...>]

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

Re: [VirtualGL-Devel] Fconfig deadlock from _fini()

[DRC <dco...@us...>]

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
> 

Re: [VirtualGL-Devel] Fconfig deadlock from _fini()

[Nathan K. <nat...@sp...>]

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