Hi!
One of our customer is facing random crashes of the JVM when using webMethods. They’re using version 5, i know it is a very old version, we will ask them to update/upgrade it, but first we must know what causing the crash.
Based on the mdmp file created after the crashes, we see that the call trace references to the awssl50jn.dll. The crash log (hs_err_pidXXXX.log) is pointing to the smartheap dll, and the java stack ends with the The strange thing is it seems this dll uses a memory management dll, what we’re also using in our app, the dll name is shsmp.dll (SmartHeap developed by MicroQuill).
This part of the stack print is:
"…
Stack: [0x4bc10000,0x4bc80000], sp=0x4bc7d9d0, free space=438k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [SHSMP.dll+0x2f15]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j COM.activesw.API.client.ssl.AwSSLNative.createClientSocket(JILjava/lang/String;II)LCOM/activesw/API/client/ssl/AwSSLSocketInfo;+0
j COM.activesw.API.client.BrokerConnection.init()V+468
j COM.activesw.API.client.BrokerConnection.getConnection(Ljava/lang/String;IZLCOM/activesw/API/client/BrokerSSLInfo;)LCOM/activesw/API/client/BrokerConnection;+321
j COM.activesw.API.client.BrokerClient.initClient(ZZ)V+165
j COM.activesw.API.client.BrokerClient.attemptReconnect()V+23
j COM.activesw.API.client.BrokerClient.sendWithReconnect(Ljava/lang/String;Ljava/lang/String;[B)I+275
j COM.activesw.API.client.BrokerClient.destroy()V+34
j com.lucent.eai.PublisherManager.ping(LCOM/activesw/API/client/BrokerClient;)Z+18
j com.lucent.eai.PublisherManager.getBrokerClient(Ljava/util/Properties;)LCOM/activesw/API/client/BrokerClient;+126
j com.lucent.eai.PublisherManager.getPublisher(Ljava/util/Properties;)Lcom/lucent/eai/Publisher;+20
…"
My question is that do this dll use the mentioned shsmp.dll?
(or the stack/call trace is invalid)
Thanks:
Peter
Did you mean your wM version is 5?
What is your JDK version?
Yes, the wM (webMethods) version is 5. So it is an old version, but first we must find what causes the error, then we should ask them to update it.
The JDK is Oracle’s JDK version 1.7 update 45 (tried also with different subversions, like update 25 and update 51)
Tomcat version 7.0 (tried with different subversions)
awssl50jn.dll is on the system PATH, client50.jar is in the lib folder of Tomcat (not in WEB-INF/lib of the webapp)
Hi Peter,
Any JVM update? OS upgrade? Patch Install? :roll:
:arrow: Suggest to run old binaries/Broker on supported JVMs otherwise it may crash.
Thanks,
Rankesh
@ Peter,
I don’t think that SAG support webMethods 5. To start your investigation we need to think of the below points
1> From when did you start facing the issue?
2> Did you update your JDK recently?
3> Was it working fine before, if YES what was the JDK version?
4> Try downgrading the JDK to 1.2 or 1.3 or 1.4 and then see if you have the same issue. It might be the issue with JDK version and webMethods is causing the random JVM crashes (I just guess).
5> How do you assume that webMethods is causing the JVM crash 
Let me know the updates on this.
As far as I remember there was only a wM Broker version 5.
The corresponding IS was 4.6 with Service- & Feature-Packs.
The supported JVM-Versions should end with JDK 1.4, with luck eventually JDK 1.5.
You should definitely consider upgrading to a supported Version (currently the 9.x stream with JDK 1.7 supported).
As this version is quite old, it will be very difficult to get the latest Fixes or requirements documentation from Software AG. Try to contact support for assistance.
Can you share the exact version for the components?
i.e.:
Regards,
Holger
Thanks for your quick responses!
@Rankesh:
- as i mentioned we’ve tried many subversions (also the updated version) of Java7 and other components
- the OS where the application is running is Win2k3 server, and it is updated
- about patches, i haven’t found any, because it is an old version (wM)
@Mahesh:
The issue happen from the first time they’re trying to use the new version of the webapp, there are many modifications made on it, like we’ve added SmartHeap support. It was working before, but i do not know what was the version of the components like JDK or Tomcat, but they surely were old versions.
I cannot downgrade to older Java, because the components have been built using JDK7.
About question #5, i’m not sure about the root of the error, because the stack can be corrupt, all i know is the current dump/log files are pointing to the wM java and jni calls.
@Holger
Sorry, but i cannot run “awbroker -version”, because we don’t have access to their server, we have only 2 files needed to connect to it (the client part), actually they put these files to a war file (and of course after deployment there is a batch file need to be run, to put the files to the right place, and set some configuration automatically). So we have only the war file that contains client50.jar and awssl50jn.dll.
We made a thorough investigation on this error, all we know right now:
- the webapp is working fine for 2-3 days before the crash
- the JVM crashes in native code, when calling the MemAllocAligned function of the shsmp.dll, but based on the mdmp files, it points to awssl50jn.dll, just like the Java frames in the crash log generated by the JVM
We will ask the customer to update wM to the latest version if we’re sure about that the error is with this version of wM. I haven’t found reference to shsmp.dll in awssl50jn.dll, but cannot exclude that it checks that the mentioned dll is available, and uses that for memory management.
That’s why i asked that wM using Microquill’s SmartHeap or not…
Many Thanks:
Peter