IBM Support

IT37359: IBM MQ channel process amqrmppa hangs after memory exception

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.


APAR status

  • Closed as program error.

Error description

  • The IBM MQ channel process amqrmppa was not responding after
    reporting memory exception (e.g. SIGSEGV)". The problem could
    also occur on other IBM MQ processes (e.g. runmqchl, amqcrsta)
    and MQ client applications. The stack trace captured from the
    affected process is likely to show functions ctime and
    Thread stack:
        #0  0x00007f9c263456ec in __lll_lock_wait_private () from
        #1  0x00007f9c262c1ba2 in _L_lock_16654 () from
        #2  0x00007f9c262be7e3 in malloc () from
        #3  0x00007f9c262c5b8a in strdup () from
        #4  0x00007f9c262ef1d1 in tzset_internal () from
        #5  0x00007f9c262efb93 in __tz_convert () from
        #6  0x00007f9c262edae9 in ctime () from /usr/lib64/
        #7  0x00007f9c27f3feff in cccFormatStatus () from
        #8  0x00007f9c27f429a3 in cccFFSTWorkDump () from
        #9  0x00007f9c271050f8 in ?? () from
        #10 0x00007f9c2710105e in xcsFFSTFn () from
        #11 0x00007f9c270f2db9 in xehExceptionHandler ()from
        #12 <signal handler called>
        #13 0x00007f9c262ba584 in _int_free () from
        #14 0x00007f9c27181015 in xcsFreeMemFn () from

Local fix

Problem summary

  • ****************************************************************
    Users of IBM MQ code (running in client or server installations)
    in the unlikely event that a memory exception is generated
    within heap management routines (a possible cause of this is
    corruption of the heap memory).
    Platforms affected:
    To format a date the IBM MQ signal handler called C library
    function ctime marked as non-async-signal-safe. This caused a
    hang in malloc when acquiring a lock used
    in memory management as the lock had already been acquired by
    the same thread when freeing memory but then received a memory

Problem conclusion

  • The IBM MQ code has been modified to use the thread-safe ctime_r
    instead of ctime to resolve the problem.
    The fix is targeted for delivery in the following PTFs:
    Version    Maintenance Level
    v9.1 LTS
    v9.2 LTS
    v9.x CD    9.2.4
    The latest available maintenance can be obtained from
    'WebSphere MQ Recommended Fixes'
    If the maintenance level is not yet available information on
    its planned availability can be found in 'WebSphere MQ
    Planned Maintenance Release Dates'

Temporary fix


APAR Information

  • APAR number


  • Reported component name

    MQ BASE V9.2

  • Reported component ID


  • Reported release


  • Status


  • PE




  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date


  • Closed date


  • Last modified date


  • 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

    MQ BASE V9.2

  • Fixed component ID


Applicable component levels

  • R920 PSY


[{"Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"920"}]

Document Information

Modified date:
16 July 2021