2. Support
  3. AR# 56419: 2013.x Vivado - Vivado IDE exits unexpectedly shortly after launch on Linux platform

AR# 56419

|

2013.x Vivado - Vivado IDE exits unexpectedly shortly after launch on Linux platform

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.

The content of the hs_err_pidXXXXX.log file will look similar to the following:
#
# 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.

The easiest workaround is to turn off the automatic check for updates. 

This can be done as follows:

1) Open the vivado.ini file in your $HOME/.Xilinx/Vivado/2013.4 directory

2) Look for the text "AUTO_CHECK_FOR_UPDATES"

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

Note If there is a current instance of Vivado open (e.g. In Tcl mode or running a batch script) it should be closed or the .ini file changes will be overwritten when the open instance of Vivado is closed.

The automatic check for updates has been removed from Vivado IDE 2014.1. 

Automated checks for Vivado updates in Vivado 2014.1 and later will be controlled in the Xilinx Information Center (XIC) application.
 

Other users have reported success in resolving this issue in the following ways:

 
  • 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.
AR# 56419
Date 07/10/2014
Status Archive
Type Known Issues
Tools
People Also Viewed