Strange things happening with IC5.033

Hi,

It's really strange what I experience. I have Cadence 5.033 installed
under RH 8.0 in my office.
It already happened several times that if I try to start it one day,
icfb hangs or rather, waits for something to happen. It eventually
loads after several minutes, but then the same thing happens if I try
to open Library manager for example. Even closing the damn thing takes
long time. It is completely unusable. Then I leave it for a day. The
next day I go into Linux again, start icfb and every thing works
pefectly. This already happened several times. Yesterday too. And today
it works fine. I suspect that something might be happening with my LAN.
I have my laptop and my desktop connected in a network through a
Linksys router. I checked what is in the Linksys setup yesterday and it
seemed that for some strange reason the router was associating the
physical address of my desktop NIC to the IP address of the laptop NIC
and vice versa. Today when I checked the same, it was as it should be.
So, it seems logical to me that when I start cadence on a wrong day it
tries to access the license on the wrong machine. I don't understand
how this could happen.
Anyone has any idea how I can fix it? Or an explanation why one day it
is bad and the next it is ok? Thnx.

 

It already happened several times that if I try to start it one day,

My office experienced something similar. The problems disappeared when
we replaecd the router (Netgear) with a dumb ethernet "switch." In
your case, you should be able to configure your router to make sure it's
using a totally different LAN subnet.

I have been told that if you use just the LAN-ports of the router (and
leave the WAN-port unplugged), the router is *supposed* to be smart enough
to auto-disable the NAT/router functionality. In our experience, this
just wasn't true.

 

This can happen for a variety of reasons with icfb:
1) your network is broken so "getHostByBame" fails - and this hangs the
machine as it is trying to find out its name from a DNS server. Sorting
network problems should fix this - try pinging your DNS server to see
if the network to it is ok
2) you LM_LICENSE_FILE mentions a remote license server which is
uncontactable eg because the network is screwed or that machine no
longer exists or has changed name etc
3) you library has lock files in it referring to a machine and/or user
that can't be found on the network, so when it tries to contact the
original owner to get a lock it fails and hangs

steps to take:
a) check your DNS server is visible
b) check your $LM_LICENSE_FILE and any hosts mentioned in it
c) check all libraries mentioned in you cdslib file and see if they
have any dead lock files (maybe you tar'd up someone else's library
while their session was still live and copied it to another machine)

Cheers

JB

 

Network anomalies, as others have suggested.

I'm not at work right now (and a direct lightning hit to my house
yesterday took out most of the electronics... <sigh>), so I'm recalling
some of these paths from memory... you may need to adjust this a bit.

First, set LD_LIBRARY_PATH to include
<cdsroot>/tools/lib:<cdsroot>/tools/dfII/lib

Then invoke icfb.exe directly through strace:

strace -f -o /tmp/icfb.log -t <cdsroot>/tools/dfII/32bit/icfb.exe

The flags mean:
-f follow fork() calls (process creation)
-o ... writes the output to /tmp/icfb.log
-t puts a timestamp at each system call.

Then look for a gap in the timestamps and that will show you the
offending system call... which ideally will be some sort of networking
operation involving a hostname or somesuch which doesn't exist.

In my experience, these kinds of hangs are almost always FlexLM-related
(which is very sensitive to networking issues).

Dave