From: Robert Wohlhueter (bobwohlhueter_at_earthlink.net)
Date: Wed Nov 27 2013 - 10:00:38 CST

John, Josh,

Addendum: I did run `vmd -debug` (as John requested), but forgot to
include its output in previous email. Also ran `nvidia-smi` -- both
outputs pasted below.

Bob W.

bobw_at_winter-linux: ...vmd/vmd-1.9.1 [6]> vmd -debug
vmd -debug
***
*** Running VMD in debugger, type 'run' at debugger prompt
***
GNU gdb (GDB) 7.6.1-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/lib/vmd/vmd-1.9.1/vmd_LINUXAMD64...(no
debugging symbols found)...done.
(gdb) run
Starting program: /usr/local/lib/vmd/vmd-1.9.1/vmd_LINUXAMD64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Info) VMD for LINUXAMD64, version 1.9.1 (February 1, 2012)
Info) http://www.ks.uiuc.edu/Research/vmd/
Info) Email questions and bug reports to vmd_at_ks.uiuc.edu
Info) Please include this reference in published work using VMD:
Info) Humphrey, W., Dalke, A. and Schulten, K., `VMD - Visual
Info) Molecular Dynamics', J. Molec. Graphics 1996, 14.1, 33-38.
Info) -------------------------------------------------------------
Info) Multithreading available, 4 CPUs detected.
Info) Free system memory: 6903MB (86%)

Program received signal SIGSEGV, Segmentation fault.
0x0000000000725aee in vmd_cuda_device_props ()
(gdb) where
#0 0x0000000000725aee in vmd_cuda_device_props ()
#1 0x0000000000000000 in ?? ()
(gdb)

bobw_at_winter-linux: ...vmd/test_cuda [2]> nvidia-smi
nvidia-smi
Wed Nov 27 10:44:55 2013
+------------------------------------------------------+
| NVIDIA-SMI 5.319.32 Driver Version: 319.32 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile
Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util
Compute M. |
|===============================+======================+======================|
| 0 GeForce GTX 275 Off | 0000:04:00.0 N/A
| N/A |
| 40% 63C N/A N/A / N/A | 69MB / 895MB | N/A Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Compute processes: GPU Memory |
| GPU PID Process name Usage |
|=============================================================================|
| 0 Not
Supported |
+-----------------------------------------------------------------------------+

On 11/26/13 8:08 PM, John Stone wrote:
> Robert, Josh,
> Regarding rlwrap, if it causes you trouble, feel free to disable it...
> VMD doesn't care about rlwrap. This is something that we added to the
> VMD startup script to please users that prefer command interfaces with
> up/down arrow command histories and similar features as one might have
> popular command shells and various GNU tools on Linux. VMD itself doesn't
> know anything about rlwrap and will run just fine without it.
>
> Cheers,
> John Stone
> vmd_at_ks.uiuc.edu
>
> On Tue, Nov 26, 2013 at 06:42:09PM -0600, Josh Vermaas wrote:
>> Hi Robert,
>>
>> Based on when the segfault is occurring, and the general list of things
>> that break on an upgrade, it might just be a version mismatch caused by
>> conflicting versions of the nvidia driver package. This happens to me when
>> nvidia-current gets upgraded, as it will pick up the new driver, but won't
>> get rid of the old ones. One thing I would check is the result of ldd
>> vmd_LINUXAMD64 in /usr/local/lib. On my system, which uses version 319.37,
>> this is what a fraction of it looks like:
>> libGL.so.1 => /usr/lib/nvidia-current/libGL.so.1 (0x00002b4635b53000)
>> libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1
>> (0x00002b4635e82000)
>> libcudart.so.4 => not found
>> libnvidia-tls.so.319.37 =>
>> /usr/lib/nvidia-current/tls/libnvidia-tls.so.319.37 (0x00002b4637a31000)
>> libnvidia-glcore.so.319.37 =>
>> /usr/lib/nvidia-current/libnvidia-glcore.so.319.37 (0x00002b4637c34000)
>> Libcudart isn't actually needed unless you need one of the commands that
>> uses GPU acceleration, but the other 4 had better resolve, and should all
>> resolve to libraries corresponding to the right version (in my case
>> 319.37). Manually removing old installed versions of the nvidia drivers is
>> how I tend to fix these problems when they come up.
>>
>> In terms of the rlwrap "fun" you've been having, I know this seems like a
>> stupid thing to do, but unless you need rlwrap for something else, the
>> stock VMD distribution actually works better without rlwrap installed, as
>> then the script just complains about a missing rlwrap command rather than
>> a malformatted command that causes an exit and will load vmd. In using
>> this approach, it doesn't look like anything obvious is broken.
>>
>> -Josh Vermaas
>>
>> On 11/26/13, 4:15 PM, Robert Wohlhueter wrote:
>>
>> Using Ubuntu 13.10 on an AMD64 computer with NVIDIA GTX275 and NVIDIA
>> driver 319.32:
>> vmd-1.9.1 binary distribution is broken. The same binary on same the
>> hardware (with NVIDIA 304 driver)
>> under Ubuntu 12.10 worked fine.
>>
>> Using the original installed vmd.csh script, startup seems to hang
>> because of inability to set
>> rlwrap (though in fact the file "vmd_completion.dat" is present):
>>
>> ############################################################################
>> bobw_at_winter-linux: ...lib/vmd [56]> /usr/local/bin/vmd
>> /usr/local/bin/vmd.wrap
>> rlwrap: No match.
>> ############################################################################
>>
>> If I comment out the lines relevant to loading vmd_completion.dat, then
>> run the script, the "rlwrap"-error is avoided, but I get no output at
>> all:
>>
>> ###########################################################################
>> obw_at_winter-linux: ...lib/vmd [59]> /usr/local/bin/vmd.nowrap
>> /usr/local/bin/vmd
>> bobw_at_winter-linux: ...lib/vmd [60]>
>> ###########################################################################
>>
>> But these are probably minor problems. If I by pass the script entirely
>> (but with VMDDIR and
>> MASTERVMDDIR envvars set manually), I get a little further, before
>> dumping core:
>>
>> ############################################################################
>> bobw_at_winter-linux: ...vmd/vmd-1.9.1 [60]>./vmd_LINUXAMD64
>> ./vmd_LINUXAMD64
>> Info) VMD for LINUXAMD64, version 1.9.1 (February 1, 2012)
>> Info) http://www.ks.uiuc.edu/Research/vmd/
>> Info) Email questions and bug reports to vmd_at_ks.uiuc.edu
>> Info) Please include this reference in published work using VMD:
>> Info) Humphrey, W., Dalke, A. and Schulten, K., `VMD - Visual
>> Info) Molecular Dynamics', J. Molec. Graphics 1996, 14.1, 33-38.
>> Info) -------------------------------------------------------------
>> Info) Multithreading available, 4 CPUs detected.
>> Info) Free system memory: 6482MB (81%)
>> Segmentation fault (core dumped)
>> ###########################################################################
>>
>> I would guess the problem lies not with Ubuntu 13.10 per se, but with
>> the
>> change in video driver between 12.10 and 13.10. I'm reluctant to muck
>> around
>> with video drivers, in particular to try to revert to NVIDIA 304.x,
>> since this
>> always breaks a lot of programs. Still my hardward/video driver must be
>> fairly commomplace.
>>
>> Anyone have clues to what's wrong? I'm grateful for any pointers.
>>
>> Bob Wohlhueter