ThrCSUnlock: PANIC: #unlock > #lock

[COLOR=navy][FONT=Arial]Hi All, [/color]

I am currently a Unix admin, have no experience with wM IS or any related product. I took over responsibilities over a few SAP and SAP related servers about six months ago and am in quite pickle about a failure that wM IS has been experiencing. Of course, I don’t support the application (only the OS) and the ball has been bouncing back and forth between my team and the developers / mantainers for a while now.

The specific error is:

ThrCSUnlock: PANIC: #unlock > #lock

After this, wM IS coredumps and exits.

Of course I have tried to look at the corefile, but it is not a plain text file such as -nix cores and appaerently we do not have whatever tool is required to look at it again, wM n00b disclaimer here.

There seems to be nothing wrong on the OS side, apart from ‘normal’ NFS delays (we are running on OOOOOOLD infrastructure, HP N4000s). We have ~460 delays a day, which are resolved within the next minute. wM IS does not seem to crash in sync with NFS ‘disconnects’ (as the dev team likes to call 'em), nor does any other of the six applications running on the cluster experience issues. The crashes are sporadic and far apart from each other, on both nodes of the cluster indistinctly.

[SIZE=2]As far as I can tell (I have no access to the code), whatever is running on IS is Java and not FLOW. The little other information I have managed to pull out (of the logged stdout) is that a [/size][/FONT][COLOR=navy][FONT=Arial]SIGSEV hits the PID when trying to access
The library file seems to be where it is supposed to be.

The only thing I have been able to draft no IS or Java experience, only -nix and C is that a thread is locking some element and not doing a clean release before the next thread tries to unlock it. How mistaken I am ?

Has anyone experienced anything like this before ?

[SIZE=2]Thank you for your time!

I forgot to mention, there are 36503 (yes, thousand) MQ Code 2, Reason 2033 expected to receive a message, but was not delivered messages in the stdout.
The application support group said they can be discarded, as they offer no proof of an error. I would personally not discard something that happens 36k+ times, but I am no MQ expert.

Again, thanks for your time!


I would suggest you to contact SoftwareAG support center for investigating webMethods IS crash. Take thread dumps when IScoredumps ,that should help in investigating the cause of IS crash.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.