VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Wed Mar 05 2014 - 16:40:49 CST

That's very odd that it stops at only 10 frames. The Apple
debugger must be modified in some way. Can you use the
built-in "help" command to see if you can get it to give a more complete
traceback and not only the last 10 stack frames? I would normally
expect a crash inside VMD to result in a traceback that's at least 20
or 30 frames deep if it occurs during rendering, so what you've got
there either indicates evil driver badness or that it's just showing
you an incomplete traceback...

Cheers,
  John

On Wed, Mar 05, 2014 at 10:38:16PM +0000, Phillips, Carolyn L. wrote:
> HI John,
> Thanks for digging into this deeper.
> This is the output of backtrace 60
> (gdb) backtrace 60
> #0 0x0000000100777e42 in ?? ()
> #1 0x00007fff5fbfbb80 in ?? ()
> #2 0x00000001007299ed in ?? ()
> #3 0x0000000100b5c720 in ?? ()
> #4 0x7fffffffffffffff in ?? ()
> #5 0x00007fff5fbfbc20 in ?? ()
> #6 0x00007fff8af7787e in ?? ()
> #7 0x00007fff5fbfbbb0 in ?? ()
> #8 0x0000000100b5c720 in ?? ()
> #9 0x00007fff5fbfbe70 in ?? ()
> #10 0x0000000000000000 in ?? ()
> On Mar 5, 2014, at 3:15 PM, John Stone <johns_at_ks.uiuc.edu> wrote:
>
> Carolyn,
> Okay, if you still get no symbols, that would indicate that the crash
> is occuring in one of the system's runtime libraries, in this case it's
> likely an OpenGL issue. We can dig deeper to figure this out however.
> What happens if you type "backtrace 60" in the debugger?
>
> Cheers,
> John
>
> On Wed, Mar 05, 2014 at 10:07:25PM +0000, Phillips, Carolyn L. wrote:
>
> Hi John
> That is a traceback from my build. I did exactly what you suggest
> (added
> -g to the compiler flags). It did not change the output. This
> surprised
> me as well.
> I do not actually use a CUDA build of vmd
> Here are my configure options
>
> ./configure MACOSXX86_64 FLTKOPENGL FLTK IMD TK TCL SILENT PTHREADS
> LIBTACHYON NETCDF PYTHON NUMPY LP64
>
> So perhaps it is my OpenGL driver. However I have worked with
> another
> code that uses OpenGL without seeing any problems.
> -Carolyn
> On Mar 5, 2014, at 8:43 AM, John Stone <johns_at_ks.uiuc.edu> wrote:
>
> Carolyn,
> Is that traceback from your build, or from one of the stock VMD
> binaries? If it's from your build, you can just edit your
> Makefiles
> to add "-g" to your compiler flags, and then you'll have debugging
> symbols for the code in VMD. I would guess from your description
> that there's some issue with the OpenGL driver on your machine,
> although I hadn't heard anyone else report something like this on
> MacOS X Mavericks yet. You appear to have a very new machine
> though
> (based on your GPU model), so this may be specific to your
> particular
> type of GPU. Just to verify, you have the same problem when you
> run
> a non-CUDA build of VMD, or not? I ask because there's an
> interaction
> between CUDA and OpenGL in that they both make use of
> NVIDIA's special TLS (thread local storage) library, and if
> there's
> any mismatched version going on there, I could envision that
> causing
> trouble. If the same problem occurs both with and without CUDA,
> then
> I would assume it is purely an OpenGL issue.
>
> Cheers,
> John Stone
> vmd_at_ks.uiuc.edu
>
> On Wed, Mar 05, 2014 at 01:50:32AM +0000, Phillips, Carolyn L.
> wrote:
>
> Fyi, I figured out to change the *vmd* script so it calls ggdb
> instead,
> but the output when it crashes is not very helpful (to me at
> least)
> This appears when I grab and rotate the molecule
> vmd > [New Thread 0x160b of process 52175]
> [New Thread 0x1703 of process 52175]
> [New Thread 0x1803 of process 52175]
> [New Thread 0x1903 of process 52175]
> [New Thread 0x1a03 of process 52175]
> [New Thread 0x1b03 of process 52175]
> [New Thread 0x1c03 of process 52175]
> [New Thread 0x1d03 of process 52175]
> [New Thread 0x1e03 of process 52175]
> [New Thread 0x1f03 of process 52175]
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000100777e42 in ?? ()
> (gdb) where
> #0 0x0000000100777e42 in ?? ()
> #1 0x00007fff5fbfbac0 in ?? ()
> #2 0x00000001007299ed in ?? ()
> #3 0x0000000113f097d0 in ?? ()
> #4 0x7fffffffffffffff in ?? ()
> #5 0x00007fff5fbfbb60 in ?? ()
> #6 0x00007fff8af7787e in ?? ()
> #7 0x00007fff5fbfbaf0 in ?? ()
> #8 0x0000000113f097d0 in ?? ()
> #9 0x00007fff5fbfbdb0 in ?? ()
> #10 0x0000000000000000 in ?? ()
> On Mar 4, 2014, at 6:39 PM, Phillips, Carolyn L.
> <cphillips_at_anl.gov>
> wrote:
>
> Ignore my last.
> I forgot what caused crashing. From my local build from
> source,
> I can
> open a molecule file, but the moment I try to rotate it, I
> get the
> following.
> rlwrap: warning: vmd killed by SIGSEGV.
> rlwrap has not crashed, but for transparency,
> it will now kill itself (without dumping core)with the same
> signal
> Segmentation fault
> John, you had some advice on how to apply a debugger to vmd?
>
> ggdb vmd does not work because
> "/usr/local/bin/vmd": not in executable format: File format
> not
> recognize*
> On Mar 4, 2014, at 6:31 PM, Phillips, Carolyn L.
> <cphillips_at_anl.gov>
> wrote:
>
> FYI, fixing this problem fixed my local build of VMD from
> sources as
> well. All is good again in the world.
>
> Thanks for your help.
> Carolyn
>
> On Mar 4, 2014, at 2:39 PM, John Stone <johns_at_ks.uiuc.edu>
> wrote:
>
> Joshua,
> I suspect that the intent of the SDK directions there is
> make
> it
> easy
> to run the CUDA samples, but the unintended consequence
> is
> that it
> will break _all_ apps like VMD that do ship with their
> own
> .dylib,
> if that version is not precisely the same rev that was
> installed
> with the toolkit.
>
> Using the static libcudart will cure this, but that
> requires
> using
> CUDA 5.5, which obsoletes older revs of MacOS, and the
> versions
> of OptiX that I've had the most mileage on were based on
> CUDA
> 5.0
> which doesn't have the static lib, so it's always tricky
> with
> these library versioning issues.
>
> I'm going to try a VMD MacOS build for CUDA 5.5 using
> the
> static
> CUDA libs
> and see how far I get with that as one of the options in
> the
> early
> beta revs of VMD 1.9.2.
>
> Cheers,
> John Stone
> vmd_at_ks.uiuc.edu
>
> On Tue, Mar 04, 2014 at 12:01:15PM -0700, Joshua
> Anderson
> wrote:
>
> Yes, the NVIDIA docs do say that - but they also tell
> application
> developers to bundle libcudart and link to the bundled
> lib
> so that
> users do not need to install the CUDA toolkit.
>
> I haven't checked recently, but you may need
> DYLD_LIBRARY_PATH set
> to run simple applications built by "nvcc -o output
> input.cu". It
> was needed back in the CUDA 1.0 days. Executables
> built by
> cmake
> link insert an rpath to the lib and do not need a
> DYLD_LIBRARY_PATH set.
> ------
> Joshua A. Anderson, Ph.D.
> Research Area Specialist, Chemical Engineering,
> University
> of
> Michigan
> Phone: 734-647-8244
> http://www-personal.umich.edu/~joaander/
>
> On Mar 4, 2014, at 10:09 AM, Phillips, Carolyn L.
> wrote:
>
> I removed it from my .bashrc, and indeed now VMD
> starts up
> without a problem!
>
> This is the opposite of what NVIDA advises you to
> do, btw?
> curious
>
> http://docs.nvidia.com/cuda/cuda-getting-started-guide-for-mac-os-x/index.html
>
> ? Define the environment variables.
> ? The PATH variable needs to include
> /Developer/NVIDIA/CUDA-5.5/bin
> ? DYLD_LIBRARY_PATH needs to contain
> /Developer/NVIDIA/CUDA-5.5/lib
> To change the environment variables for 32-bit
> operating
> systems:
>
> export PATH=/Developer/NVIDIA/CUDA-5.5/bin:$PATH
> export
> DYLD_LIBRARY_PATH=/Developer/NVIDIA/CUDA-5.5/lib:$DYLD_LIBRARY_PATH
>
> To change the environment variables for 64-bit
> operating
> systems:
>
> export PATH=/Developer/NVIDIA/CUDA-5.5/bin:$PATH
> export
> DYLD_LIBRARY_PATH=/Developer/NVIDIA/CUDA-5.5/lib:$DYLD_LIBRARY_PATH
>
> On Mar 4, 2014, at 9:55 AM, Maxim Belkin
> <mbelkin_at_ks.uiuc.edu>
> wrote:
>
> Hi Carolyn,
>
> As John suggested, I was able to reproduce your
> problem
> by
> setting DYLD_LIBRARY_PATH. Run ?unset
> DYLD_LIBRARY_PATH?
> and
> try launching VMD then.
>
> Maxim
>
> On Mar 4, 2014, at 9:51 AM, John Stone
> <johns_at_ks.uiuc.edu>
> wrote:
>
> Carolyn,
> Have you checked your environment variables to
> see if
> they
> are
> interfering with VMD's usage of the .dylib
> that's
> shipped
> with it?
> Anything in DYLD_FRAMEWORK_PATH or
> LD_LIBRARY_PATH
> that adds
> CUDA?
>
> Cheers,
> John
>
> On Tue, Mar 04, 2014 at 03:45:23PM +0000,
> Phillips,
> Carolyn
> L. wrote:
>
> So I have now updated my cuda driver to 5.5.47
> and
> then
> grabbed the VMD
> 1.9.1 binary again
> Same problem
> /Applications/VMD\ 1.9.1\
> 2.app/Contents/MacOS/startup.command ; exit;
> dyld: Library not loaded:
> @executable_path/libcudart.dylib
> Referenced from: /Applications/VMD 1.9.1
> 2.app/Contents/MacOS/../Resources/VMD.app/Contents/MacOS/VMD
> Reason: Incompatible library version: VMD
> requires
> version 1.1.0 or
> later, but libcudart.dylib provides version
> 0.0.0
> /Applications/VMD 1.9.1
> 2.app/Contents/MacOS/startup.command: line 7:
> 47884 Trace/BPT trap: 5
> "$p/../Resources/VMD.app/Contents/MacOS/VMD"
> $*
> logout
>
> From the error message above I wonder if your
>
> install_name_tool and otool
> is finding the libcudart.dylib at all.
> (version
> 0.0.0 ??)
>
> Also, I noticed that the the /usr/local/cuda
> directory all
> points to the
> Developer folder as well
> lrwxr-xr-x 1 root wheel 35 Nov 21 09:06
> EULA.txt ->
> /Developer/NVIDIA/CUDA-5.5/EULA.txt
> lrwxr-xr-x 1 root wheel 30 Nov 21 09:06
> bin ->
> /Developer/NVIDIA/CUDA-5.5/bin
> lrwxr-xr-x 1 root wheel 30 Nov 21 09:06
> doc ->
> /Developer/NVIDIA/CUDA-5.5/doc
> lrwxr-xr-x 1 root wheel 33 Nov 21 09:06
> extras
> ->
> /Developer/NVIDIA/CUDA-5.5/extras
> lrwxr-xr-x 1 root wheel 34 Nov 21 09:06
> include
> ->
> /Developer/NVIDIA/CUDA-5.5/include
> drwxr-xr-x 28 root wheel 952 Mar 4 08:34
> lib
> lrwxr-xr-x 1 root wheel 36 Nov 21 09:06
> libnsight ->
> /Developer/NVIDIA/CUDA-5.5/libnsight
> lrwxr-xr-x 1 root wheel 34 Nov 21 09:06
> libnvvp
> ->
> /Developer/NVIDIA/CUDA-5.5/libnvvp
> lrwxr-xr-x 1 root wheel 31 Nov 21 09:06
> nvvm ->
> /Developer/NVIDIA/CUDA-5.5/nvvm
> lrwxr-xr-x 1 root wheel 33 Nov 21 09:06
> open64
> ->
> /Developer/NVIDIA/CUDA-5.5/open64
> lrwxr-xr-x 1 root wheel 34 Nov 21 09:06
> samples
> ->
> /Developer/NVIDIA/CUDA-5.5/samples
> lrwxr-xr-x 1 root wheel 30 Nov 21 09:06
> src ->
> /Developer/NVIDIA/CUDA-5.5/src
> lrwxr-xr-x 1 root wheel 32 Nov 21 09:06
> tools
> ->
> /Developer/NVIDIA/CUDA-5.5/tools
> and in lib
> lrwxr-xr-x 1 root wheel 46 Nov 21 09:06
> libcudart.dylib ->
> /Developer/NVIDIA/CUDA-5.5/lib/libcudart.dylib
> On Mar 3, 2014, at 9:08 AM, John Stone
> <johns_at_ks.uiuc.edu>
> wrote:
>
> Carolyn,
> Let us know if Maxim's suggestion makes any
> difference.
> Maxim, Thanks for the tip.
>
> Another thing to check is to see which CUDA
> runtime
> .dylib your locally
> compiled VMD is actually picking up when it
> runs.
> Since you have several on your system, one
> question
> I
> would ask is
> whether
> anything would have changed your
> DYLD_FRAMEWORK_PATH or
> LD_LIBRARY_PATH
> or similar environment variables in such a
> way that
> VMD
> is now picking
> up the wrong .dylib where it had not
> previously.
>
> In the binaries we produce, we use the MacOS
> X
> 'install_name_tool' and
> 'otool' commands to set some of our library
> dependency
> paths in such a
> way that they are unlikely to be overridden
> by
> environment variable
> changes like the ones above, but if you
> compile VMD
> from
> source and
> don't do this on your own, then anything
> could
> potentially happen if
> system-wide paths are changed such that the
> wrong
> .dylib
> shows up
> earlier
> in the search path.
>
> It should be easy to attach a debugger to
> your VMD
> during
> startup to
> help track down what's going on there. When
> the
> debugger
> attaches, it
> will
> usually print out what shared libraries the
> app is
> linked
> against and
> what
> they were resolved to, and this would help
> track
> down if
> there's
> something
> bad going on with mismatched .dylib files...
>
> Cheers,
> John Stone
>
> On Sun, Mar 02, 2014 at 05:54:44PM -0600,
> Maxim
> Belkin
> wrote:
>
> Hi Carolyn,
>
> The issue you are facing is caused by CUDA
> drivers. Try
> installing the
> latest CUDA 5.5.43 drivers. Until this
> version,
> CUDA
> didn?t work on a
> great deal of GPUs under Mavericks.
>
> Maxim
>
> On Mar 2, 2014, at 4:54 PM, Phillips,
> Carolyn L.
> <cphillips_at_anl.gov>
> wrote:
>
> A little search turned up these versions.
>
>
> ./NVIDIA/CUDA-5.5/lib/libcudart.dylib
> ./VMD
> 1.9.1.app/Contents/vmd/libcudart.dylib
> ./MATLAB_R2013b.app/bin/maci64/libcudart.dylib
> /local/cuda/lib/libcudart.dylib
>
> I think the first it the one it should be
> finding.
> I don?t know why such a library is
> included in
> vmd,
> but I am going
> to assume its legitimate
> Same for the Matlab one
> I assume it may be the /local version
> that is
> creating the problem.
>
> FYI,
>
> which nvcc
> /Developer/NVIDIA/CUDA-5.5/bin/nvcc
>
> -Carolyn
> On Mar 2, 2014, at 3:20 PM, Axel
> Kohlmeyer
> <akohlmey_at_gmail.com>
> wrote:
>
> On Sun, Mar 2, 2014 at 3:42 PM,
> Phillips,
> Carolyn
> L.
> <cphillips_at_anl.gov> wrote:
>
> Hello,
>
> I am trying to pin down why my
> version of
> VMD
> 1.91.1 built from
> source has
> started seg faulting. (Note, i
> cannot
> run vmd
> -debug because
> gdb is no
> longer included with Xcode on
> Mavericks as
> a
> command line tool,
> you can get
> it from macports but it is now called
> ggdb
> )
>
> I started with verifying if I
> download and
> run
> the VMD1.9.1
> binary that it
> still works. What I found is that
> this
> version
> does work,
> MacOS X OpenGL
> (32-bit Intel x86) (Apple MacOS-X
> 10.5.x or
> later).
>
> This version crashes, MacOS X
> OpenGL, CUDA
> (32-bit Intel x86)
> (Apple
> MacOS-X 10.5.x or later with CUDA)
>
> It cannot seem to interface with the
> cuda
> library
> correctly
>
> /Volumes/VMD-1.9.1/VMD\
> 1.9.1.app/Contents/MacOS/startup.command
> ; exit;
> dyld: Library not loaded:
> @executable_path/libcudart.dylib
> Referenced from:
> /Volumes/VMD-1.9.1/VMD
> 1.9.1.app/Contents/MacOS/../Resources/VMD.app/Contents/MacOS/VMD
> Reason: Incompatible library version:
> VMD
> requires version 1.1.0
> or later,
> but libcudart.dylib provides version
> 0.0.0
>
> hi carolyn,
>
> this looks like VMD picks up some old
> and
> incompatible version of
> the
> cuda runtime library from somewhere.
>
> axel.
>
> /Volumes/VMD-1.9.1/VMD
> 1.9.1.app/Contents/MacOS/startup.command:
> line 7:
> 2533 Trace/BPT trap: 5
> "$p/../Resources/VMD.app/Contents/MacOS/VMD"
> $*
> logout
>
> [Process completed]
>
> My system is
>
> Mac OSX 10.9.1
> Graphics NVIDIA GeForce GT 750M 2048
> MB
> Processor 2.3 GHz Intel Core i7
>
> -Carolyn
>
> --
> Dr. Axel Kohlmeyer akohlmey_at_gmail.com
> http://goo.gl/1wk0
> College of Science & Technology, Temple
> University,
> Philadelphia
> PA, USA
> International Centre for Theoretical
> Physics,
> Trieste. Italy.
>
> --
> NIH Center for Macromolecular Modeling and
> Bioinformatics
> Beckman Institute for Advanced Science and
> Technology
> University of Illinois, 405 N. Mathews Ave,
> Urbana,
> IL
> 61801
> http://www.ks.uiuc.edu/~johns/
> Phone:
> 217-244-3349
> http://www.ks.uiuc.edu/Research/vmd/
>
> --
> NIH Center for Macromolecular Modeling and
> Bioinformatics
> Beckman Institute for Advanced Science and
> Technology
> University of Illinois, 405 N. Mathews Ave,
> Urbana, IL
> 61801
> http://www.ks.uiuc.edu/~johns/ Phone:
> 217-244-3349
> http://www.ks.uiuc.edu/Research/vmd/
>
> --
> NIH Center for Macromolecular Modeling and
> Bioinformatics
> Beckman Institute for Advanced Science and Technology
> University of Illinois, 405 N. Mathews Ave, Urbana, IL
> 61801
> http://www.ks.uiuc.edu/~johns/ Phone:
> 217-244-3349
> http://www.ks.uiuc.edu/Research/vmd/
>
> --
> NIH Center for Macromolecular Modeling and Bioinformatics
> Beckman Institute for Advanced Science and Technology
> University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> http://www.ks.uiuc.edu/~johns/ Phone: 217-244-3349
> http://www.ks.uiuc.edu/Research/vmd/
>
> --
> NIH Center for Macromolecular Modeling and Bioinformatics
> Beckman Institute for Advanced Science and Technology
> University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> http://www.ks.uiuc.edu/~johns/ Phone: 217-244-3349
> http://www.ks.uiuc.edu/Research/vmd/ 

-- 
NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
http://www.ks.uiuc.edu/Research/vmd/