Description

When Opening Vivado design tools on a Linux platform machine, the GUI opens as expected. 

However, after a short delay (between 10 to 30 seconds) the GUI closes unexpectedly.

#
# An unexpected error has occurred (11)
#
Stack:
/home/xilinx/Vivado/2013.3/tps/lnx64/jre/lib/amd64/server/libjvm.so(+0x741cc9) [0x7f0394386cc9]
/home/xilinx/Vivado/2013.3/tps/lnx64/jre/lib/amd64/server/libjvm.so(JVM_handle_linux_signal+0xa7) [0x7f039438b547]
/lib64/libpthread.so.0() [0x345c20f500]
/home/xilinx/Vivado/2013.3/tps/lnx64/jre/lib/amd64/server/libjvm.so(+0x508c89) [0x7f039414dc89]
/home/xilinx/Vivado/2013.3/tps/lnx64/jre/lib/amd64/server/libjvm.so(+0x7ac435) [0x7f03943f1435]
/home/xilinx/Vivado/2013.3/tps/lnx64/jre/lib/amd64/server/libjvm.so(+0x667593) [0x7f03942ac593]
/home/xilinx/Vivado/2013.3/tps/lnx64/jre/lib/amd64/server/libjvm.so(+0x6684c5) [0x7f03942ad4c5]
/home/xilinx/Vivado/2013.3/tps/lnx64/jre/lib/amd64/server/libjvm.so(+0x668af2) [0x7f03942adaf2]
/home/xilinx/Vivado/2013.3/tps/lnx64/jre/lib/amd64/server/libjvm.so(+0x668c30) [0x7f03942adc30]
/home/xilinx/Vivado/2013.3/tps/lnx64/jre/lib/amd64/server/libjvm.so(+0x668e46) [0x7f03942ade46]
/home/xilinx/Vivado/2013.3/tps/lnx64/jre/lib/amd64/server/libjvm.so(+0x547b05) [0x7f039418cb05]
[0x7f038d60e0c8]

Solution

The underlying problem is that the JAVA Runtime Environment (JRE), which the Vivado IDE relies on, is being closed or fails shortly after the GUI is launched if the auto update check is active.

Typical situations where this crash has been seen are where the user is on a secure network and the internet proxy is not set or access to the internet is otherwise not available.

• If this setting exists, change it from "AUTO_CHECK_FOR_UPDATES=true" to  "AUTO_CHECK_FOR_UPDATES=false".


• If this setting does not exist, add the line "AUTO_CHECK_FOR_UPDATES=false"

• In one case, the user re-installed the Linux OS and the issue was resolved.


• Three system administrators reported that they created new accounts for their users that saw the problem and the users did not see the problem when using the new accounts.


• In one case, the user checked the content on the /var/log/messages file for one customer and found the following content:
  

  Sep 11 08:28:22 linux15 gconfd (ariel-17323): GConf server is not in use, shutting down.
  Sep 11 08:28:22 linux15 gconfd (ariel-17323): Exiting

  The problem in this case was with a storage (NetApp filer) that did not support NFS locking in NFS3 protocol.
  
  In order to continue using the same storage, the NFS4 protocol should be used for the user's home directory mounting.
  NetApp supports nfs locking starting with the NFS4 protocol.
  
  The user noted the following::
  
  Java applications use the Gconf mechanism, and then it must have NFS locking on the NetApp file server, and RHEL servers must run nfslock service.
  Netapp uses UDP in its locking mechanism, and then the file: /etc/syscnfig/nfs should be edited to uncomment the line: LOCKD_UDPPORT=32769
  Save, quit and restart the nfs services using
  

  service nfs restart.

  An alternative solution was to create a home directory for "tempuser" on the local hard drive of the Linux server.
  
  RedHat Linux 5+ also supports nfs locking for the NFS3 protocol.
  
  Users were advised to use "su tempuser" when working with the Vivado tool.