A fix is available
APAR status
Closed as program error.
Error description
WebSphere MQ v7.0.1 .NET application intermittently crashes after several hours runtime. The application crashes with error message "Access Violation at address FFFFFFFFFFFFFFFF" A First Failure report is generated with the following: Probe Id :- XC130031 Component :- xehExceptionHandler UserID :- USER1 Major Errorcode :- xecF_E_UNEXPECTED_SYSTEM_RC Probe Description :- AMQ6109: An internal WebSphere MQ error has occurred. Comment1 :- Access Violation at address FFFFFFFFFFFFFFFF when reading Stack: xcsWaitThread ccxFreeConv reqFreeSess reqFreeConn rzstMQDISC tmzstMQDISC MQDISC Trace shows: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. at IBM.WMQ.Nmqi.Native.MQDISC ... at IBM.WMQ.MQQueueManager.Disconnect()
Local fix
Problem summary
**************************************************************** USERS AFFECTED: Users of MQ v7.0.1 .net client calling multiple connect/disconnect under high load. Platforms affected: Windows **************************************************************** PROBLEM SUMMARY: A dot net client crashes with an access violation exception during disconnect with a stack trace as below: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. at IBM.WMQ.Nmqi.Native.MQDISC(Int32& hConn, Int32& compCode, Int32& reason) at IBM.WMQ.Nmqi.UnmanagedNmqiMQ.MQDISC(Phconn phconn, Int32& pCompCode, Int32& pReason) at IBM.WMQ.MQQueueManager.Disconnect() An FDC with probe ID XC130003 is generated reporting an access violation which causes the WebSphere MQ client application to crash. The client calls multiple connect and disconnect calls and sporadically encounters this exception under heavy load. The FDC has the following stack: MQQueueManager.Disconnect()1 UnmanagedNmqiMQ.MQDISC(Phconn,out int,out int) MQDISC MQDISC reqFreeConn reqFreeSess ccxFreeConv xcsWaitThread xcsFFST This happens when the disconnect call is waiting for the receiver thread to end and the receiver thread is already ending and is waiting for a mutex which has been held by another thread.
Problem conclusion
The fix ensures that MQ checks to see if the thread is active before trying to close it in the xcsWaitThread method. Also the code change ensures that the thread locking the mutex required by the receive thread, performs its work without holding a lock on the mutex as its not required. --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: Version Maintenance Level v7.0 7.0.1.12 The latest available maintenance can be obtained from 'WebSphere MQ Recommended Fixes' http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037 If the maintenance level is not yet available information on its planned availability can be found in 'WebSphere MQ Planned Maintenance Release Dates' http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309 ---------------------------------------------------------------
Temporary fix
Comments
APAR Information
APAR number
IC97860
Reported component name
WMQ WINDOWS V7
Reported component ID
5724H7220
Reported release
701
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2013-11-21
Closed date
2013-12-04
Last modified date
2013-12-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
WMQ WINDOWS V7
Fixed component ID
5724H7220
Applicable component levels
R701 PSY
UP
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSDEZSF","label":"IBM WebSphere MQ Managed File Transfer for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0.1","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
31 March 2023