I have now tested Remo 3D as well, and it actually segfaults in exactly
the same way. GDB shows:
Starting program: /opt/remo3d/remo3d-bin
[Thread debugging using libthread_db enabled]
Missing separate debuginfo for /opt/remo3d/libstdc++.so.6
Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.47.el6.i686 libX11-1.3-2.el6.i686 libXau-1.0.5-1.el6.i686
libXext-1.1-3.el6.i686 libXpm-3.5.8-2.el6.i686 libgcc-4.4.6-3.el6.i686
libjpeg-6b-46.el6.i686 libselinux-2.0.94-5.2.el6.i686
libxcb-1.5-1.el6.i686 mesa-libGLU-7.11-3.el6.i686
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x00c238d1 in pthread_once () from /lib/libpthread.so.0
#2 0x00b83de6 in ?? () from /usr/lib/libGL.so.1
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
So perhaps Nvidia is the one to blame?
Rgds,
Peter
On Tue, 24 Jan 2012, Peter Åstrand wrote:
2.5 years later, I'm trying to install "latest version of Google Earth on
latest RHEL", which is Google Earth google-earth-stable-6.1.0.5001-0.x86_64
on RHEL6. I've also tried older GE versions. Does not work at all. Initially,
I got "bad elf interpreter". After installing tons of 32-bit packages (yes,
the 64-bit package actually contains 32-bit binaries...), I now get segfault
instead. This is both with and without vglrun, both in a TigerVNC session as
well as using X11 forwarding to a real workstation. The machine has a Nvidia
Quadro FX 1800, and I have installed the latest Nvidia drivers (290.10).
Unfortunately I'm not able to test on the physical console, since it's far
away.
Anyone else been able to run GE on RHEL6, with or without VirtualGL? I've
found bug reports such as
http://code.google.com/p/earth-issues/issues/detail?id=1212, but it's still
unresolved.
Rgds,
Peter
On Wed, 29 Jul 2009, James Pearson wrote:
DRC wrote:
That is a known issue caused by a bug in the 180 series nVidia drivers.
VirtualGL 2.1.3 is able to work around the bug in most cases, but the
bug is still there, and doing 'vglrun /bin/hostname' reveals it. The
nVidia version of libGL.so.1 is overriding dlopen() and dlsym() for some
reason, and their version of dlsym() is buggy. The act of preloading
librrfaker.so into an executable causes libGL.so.1 to be loaded ahead of
libdl.so.2, which overrides the native version of dlsym() with the buggy
one.
In most cases, you won't need to run 'vglrun /bin/hostname', unless
'/bin/hostname' is in a script that is used to launch a 3D app. In that
case, use the technique described in Ch. 12 of the VirtualGL User's
Guide to save the value of LD_PRELOAD within the script and recall it
right before the 3D application is actually launched.
Thus far, it seems like the workaround in VGL 2.1.3 is working. If you
do encounter a problem with launching an actual 3D app, though, please
post it here. I suspect that any 3D app which tried to use
dlsym(RTLD_NEXT, ...) would encounter problems, but fortunately, we
haven't encountered such an app yet. For those apps, assuming they
exist, a further workaround would be to downgrade to the nVidia 170
series drivers.
See:
http://www.nvnews.net/vbulletin/showthread.php?t=132259
for a description of the bug.
I've also submitted this using the nVidia support E-Mail alias, but they
have completely ignored me.
Thanks - we need to use 180 series (or later) nVidia drivers for a
particular OpenGL bug fix. I've tested the latest 190.18 beta drivers -
and it still has the same issue with VirtualGL
/bin/hostname was in a script that I called with vglrun - so I'll try
and get LD_PRELOAD 'closer' to the final binary.
James Pearson
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
VirtualGL-Users mailing list
VirtualGL-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-users
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
VirtualGL-Users mailing list
VirtualGL-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-users
