Using AI, Such as CoPilot to Analyze an ACE Abend Stack Dump
A case was opened where it was noted that ACE 13.0.x would not start when integrating with a Remote Queue manager 9.4.
An abend was generated indicating a segmentation fault at the Integration Server level with the following Stack Dump for the failing thread:
abend record for pid 52 tid 52 time in seconds since 01/01/1970: 1751450933
File: /build/jenkins_swg/slot0/product-build/WMB/src/CommonServices/Unix/ImbAbend.cpp
Line: 1214
Function: signal received
---- Inserts ----
Segmentation fault
%Z% %I% %W% %E% %U% [%H% %T%]
1411990976
-----------------
----------------------------- Stack dump for current thread ( 52)
#0 0x75b10b6ddcbe in ?? from /opt/ibm/ace-13/server/lib/libCommonServices.so
#1 0x75b10b6a9d08 in ImbAbend::dumpCurrentStacksToFile(void const*, int) from /opt/ibm/ace-13/server/lib/libCommonServices.so
#2 0x75b10b6aa48d in ImbAbend::dumpToFile(char*, char const*, int, char const*, ImbAbend::Insert const&, ImbAbend::Insert const&, ImbAbend::Insert const&, ImbAbend::Insert const&, ImbAbend::Insert const&, ImbAbend::Insert const&, void const*) from /opt/ibm/ace-13/server/lib/libCommonServices.so
#3 0x75b10b6aaa1d in ImbAbend::logSystemErrorInternal(char const*, int, char const*, ImbAbend::Insert const&, ImbAbend::Insert const&, ImbAbend::Insert const&, ImbAbend::Insert const&, ImbAbend::Insert const&, ImbAbend::Insert const&, void const*, bool) from /opt/ibm/ace-13/server/lib/libCommonServices.so
#4 0x75b10b6aae4a in ImbAbend::logSystemErrorAndTerminateProcessInternal(char const*, int, char const*, ImbAbend::Insert const&, ImbAbend::Insert const&, ImbAbend::Insert const&, ImbAbend::Insert const&, ImbAbend::Insert const&, ImbAbend::Insert const&, void const*, bool) from /opt/ibm/ace-13/server/lib/libCommonServices.so
#5 0x75b10b6ab13d in ImbAbend::signalHandlerInternal(int, siginfo_t*, void*) from /opt/ibm/ace-13/server/lib/libCommonServices.so
#6 0x75b0d158b35b in ?? from /opt/mqm/lib64/../lib64/libmqe_r.so
#7 0x75b0d158bda3 in ?? from /opt/mqm/lib64/../lib64/libmqe_r.so
#8 0x75b109ea1bf0 in ?? from /lib64/libc.so.6
#9 0x75b10954fd19 in ?? from /opt/ibm/ace-13/server/lib/libcurl.so.4
#10 0x75b10954fdbd in ?? from /opt/ibm/ace-13/server/lib/libcurl.so.4
#11 0x75b10953f80b in ?? from /opt/ibm/ace-13/server/lib/libcurl.so.4
#12 0x75b10953f97a in curl_multi_add_handle from /opt/ibm/ace-13/server/lib/libcurl.so.4
#13 0x75af90bb08f6 in curl_easy_perform from /opt/mqm/lib64/libcurl.so
#14 0x75b0d17ab0e3 in ?? from /opt/mqm/lib64/../lib64/libmqe_r.so
#15 0x75b0d14923d2 in ?? from /opt/mqm/lib64/../lib64/libmqe_r.so
#16 0x75b0d145b60a in ?? from /opt/mqm/lib64/../lib64/libmqe_r.so
#17 0x75b0d144c40e in ?? from /opt/mqm/lib64/../lib64/libmqe_r.so
#18 0x75b0d144fb30 in ?? from /opt/mqm/lib64/../lib64/libmqe_r.so
#19 0x75b0d1526a97 in ?? from /opt/mqm/lib64/../lib64/libmqe_r.so
#20 0x75b0d17e144e in ?? from /opt/mqm/lib64/../lib64/libmqe_r.so
#21 0x75b0d1884e63 in ?? from /opt/mqm/lib64/../lib64/libmqe_r.so
#22 0x75b10b85ffe6 in MQCONNX from /opt/ibm/ace-13/server/lib/libLibraryLoader.so
#23 0x75b06eb0cd44 in MQConnection::open() from /opt/ibm/ace-13/server/lib/libmqconnector.so
#24 0x75b06eb06b23 in MQSharedConnector::listAdminObjectProperties(ImbWstring const&, ImbWstring const&) from /opt/ibm/ace-13/server/lib/libmqconnector.so
#25 0x75b109d79d67 in ImbCPPConnectorFactory::CPPSharedConnector::listAdminObjectProperties(ImbWstring const&, ImbWstring const&) from /opt/ibm/ace-13/server/lib/libconnectors.so
#26 0x75b111b809ad in ImbMain::start(ImbStartParameters&, std::string&, bool, std::string&, bool, ImbCredentialsProviderBase*) from /opt/ibm/ace-13/server/lib/libbipmain.so
#27 0x410caf in ?? from IntegrationServer
#28 0x75b109e8c5d0 in ?? from /lib64/libc.so.6
#29 0x75b109e8c680 in __libc_start_main from /lib64/libc.so.6
#30 0x417862 in ?? from IntegrationServer
This stack was placed in CoPilot asking “why was this abend generated”. The response received was the following:
The abend (abnormal end) you're seeing is due to a **segmentation fault**, which typically indicates that the program tried to access memory it shouldn't have. Here's a breakdown of what the stack trace and error message suggest:
---
### 🔍 **Root Cause Summary**
- **Signal received**: Segmentation fault (`SIGSEGV`)
- **Thread**: 52
- **Library involved**: `libcurl.so.4`, `libmqe_r.so`, and `libmqconnector.so`
- **Function where it crashed**: `curl_multi_add_handle` → `curl_easy_perform` → MQ-related libraries
---
### 🧠 **Likely Cause**
The crash occurred during a call to `curl_easy_perform`, which is part of the **libcurl** library used for HTTP communication. This was invoked from within **IBM MQ libraries** (`libmqe_r.so`) and **IBM App Connect Enterprise (ACE)** components (`libmqconnector.so`).
This suggests:
- A **network call** (possibly to a REST API or MQ endpoint) was made using `libcurl`.
- During this operation, **invalid memory access** occurred—possibly due to:
- A **null or invalid pointer** passed to `curl_easy_perform`
- A **misconfigured or corrupted MQ connection**
- A **threading issue** or race condition
- A **library version mismatch** (e.g., incompatible libcurl or MQ libraries)
---
### 🛠️ **What You Can Do**
1. **Check for core dumps**: If core dumps are enabled, analyze the core file with `gdb`:
```bash
gdb /path/to/IntegrationServer core
```
Then use `bt` (backtrace) to inspect the call stack.
2. **Verify libcurl and MQ versions**:
- Ensure the versions of `libcurl` and `libmqe_r.so` are compatible with ACE 13.
- Check for any known issues or patches from IBM.
3. **Review MQ connection setup**:
- Look at the MQ connection parameters (e.g., channel, queue manager, credentials).
- Ensure the endpoint is reachable and not returning malformed responses.
4. **Enable ACE debug logs**:
- Increase the logging level to capture more context around the crash.
- Look for errors or warnings just before the crash.
5. **Check for threading issues**:
- If you're using shared connectors or multi-threaded flows, ensure thread safety.
---
Would you like help analyzing a core dump, checking for known issues in IBM support, or reviewing your MQ connection configuration?
CoPilot was then asked to check for known issues in IBM Support and noted:
I couldn't find any specific IBM support articles directly addressing segmentation faults in IBM App Connect Enterprise (ACE) 13 involving `libcurl` and `libmqe_r.so`. However, here are a few steps you can take to investigate further:
### 🔎 Where to Look Next
1. **IBM Support Portal**:
- Visit IBM Support and search for:
```
ACE 13 segmentation fault libcurl libmqe_r.so
```
- You can filter by product (IBM App Connect Enterprise) and version (13.x).
2. **IBM Fix Central**:
- Check for any **fix packs or interim fixes** for ACE 13 that mention segmentation faults or MQ/libcurl issues:
IBM Fix Central
3. **IBM Community Forums**:
- The IBM Middleware Community often has discussions and solutions for similar issues.
4. **Open a PMR (Problem Management Record)**:
- If this is a production-impacting issue and you have a support contract, opening a case with IBM is the fastest way to get tailored help.
---
Would you like help drafting a support case description or narrowing down the issue further based on your environment or flow configuration?
The first advise was taken and IBM Support was searched for:
ACE 13 segmentation fault libcurl libmqe_r.so
This referenced an existing case in which MQ has identified a known issue in this area and are actively working on a fix. A case was opening with the MQ Team referencing the known issue, the existing case and linking these together.
Summary:
AI can be beneficial for both support and customers for analyzing ACE abend stack dumps for known issues and to help narrow down the support investigation, or to help the customer with a better case description.
While in this particular example a resolution was not determined from AI, it helped support direct the case to the correct team and will speed up the time to resolution.