Community Functional Verification vManager crashes when analyzing multiple sessions simultaneously...

Stats

  • Locked Locked
  • Replies 3
  • Subscribers 65
  • Views 4640
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

vManager crashes when analyzing multiple sessions simultaneously with a fatal error detected by the Java Runtime Environment

HanPeng

When analyzing multiple sessions simultaneously Verisium Manager crashed and reported below error messages:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007efc52861b74, pid=14182, tid=18380
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.3+7 (17.0.3+7) (build 17.0.3+7)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.3+7 (17.0.3+7, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  [libucis.so+0x238b74]

......

For more details please refer to the attached log file "hs_err_pid21143.log".

Two approaches were tried to solve this problem but neither has worked.
Method.1:

Setting larger heap size of Java process by "-memlimit" options.For example "vmanager -memlimit 8G".

Method.2:

Enlarging stack memory size limit of the Coverage engine by setting "IMC_NATIVE_STACKSIZE" environment variable to a larger value. For example "setenv IMC_NATIVE_STACKSIZE 1024000"

According to "hs_err_pid*.log" it is almost certain that the memory overflow triggered Java's CrashOnOutOfMemoryError and caused Verisium Manager to crash. There are some arguments about memory management of Java like "Xms, Xmx, ThreadStackSize, Xss5048k etc" and maybe this problem can be fixed by setting these arguments during analysis. However, how exactly does Verisium Manager specify these arguments during analysis? I tried to set them by the form of setting environment variables before analysis but it didn't work in analysis and their values didn't change.

Is there something wrong with my operation or is there a better solution?

Thank you very much.

  • Please do not use this forum to get support for tool problems - you need to file a support request at support.cadence.com so that it can be properly tracked through to resolution. 

    All I can really suggest here is that if you've got very large coverage data files or a huge number of them, you might need to request more than 8GB of RAM, you could try 16 or 32 for example. Make sure also that your queue job has a sufficiently high limit, so that the job manager (LSF/SGE/etc) doesn't kill vManager for taking too much RAM.

  • in reply to StephenH

    Thank you for you suggestion very much, Stephen.

    I'm sorry and I would get support from support.cadence.com later.

    I have tried larger memlimit even 64G but it didn't work, however.

    I have contacted my colleagues in the IT department of our company and confirmed that it is not the job manager problem.

    I've fill a support in support.cadence.com and cadence's technical support personel would contact me later.

    Best regards. 

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.