# PXC8.4.3 nodes crashing intermittently with signal 11

**URL:** <https://forums.percona.com/t/pxc8-4-3-nodes-crashing-intermittently-with-signal-11/37697>\
**Category:** Percona XtraDB Cluster\
**Created:** [April 22, 2025, 4:00pm UTC](https://forums.percona.com/t/pxc8-4-3-nodes-crashing-intermittently-with-signal-11/37697 "2025-04-22T16:00:19Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Neil\_Billett](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/neil_billett/32/11626_2.png) [@Neil\_Billett](https://forums.percona.com/u/Neil_Billett)\
**Post date:** [April 22, 2025, 4:00pm UTC](https://forums.percona.com/t/pxc8-4-3-nodes-crashing-intermittently-with-signal-11/37697/1 "2025-04-22T16:00:19Z")

</div>

Hi,

We’re working with a client who has recently upgraded their environment (on our instruction) from PXC8.0.35 to PXC8.4.3. Servers are dedicated 8 core, 128GB RAM running RHEL8.10 and buffer pool on each node is set to 89G. Since the upgrade the 3 nodes have been prone to crashing (in some cases only minutes after startup) with the following error:

> 2025-04-22T04:39:28.933845-04:00 3527 [Note] [MY-000000] [WSREP] Initiating SST cancellation  
> 2025-04-22T08:39:28Z UTC - mysqld got signal 11 ;  
> Signal SIGSEGV (Address not mapped to object) at address 0x53400000010  
> Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.  
> BuildID[sha1]=a0116595f0b4e51107ec68982d9a53281129781e  
> Server Version: 8.4.3-3.1 Percona XtraDB Cluster (GPL), Release rel3, Revision cf742b4, WSREP version 26.1.4.3, wsrep\_26.1.4.3
> 
> Thread pointer: 0x7ef63802a980  
> Attempting backtrace. You can use the following information to find out  
> where mysqld died. If you see no messages after this, something went  
> terribly wrong…  
> stack\_bottom = 7f0acc111a90 thread\_stack 0x80000  
> #0 0x231e0cc \<unknown\>  
> #1 0x1307096 \<unknown\>  
> #2 0x1307492 \<unknown\>  
> #3 0x7f111aa2898f \<unknown\>  
> #4 0x1f76da6 \<unknown\>  
> #5 0x1f76e4d \<unknown\>  
> #6 0x1f840b9 \<unknown\>  
> #7 0x1f85b9a \<unknown\>  
> #8 0x1f13f75 \<unknown\>  
> #9 0x1f27bcd \<unknown\>  
> #10 0x1f31ea0 \<unknown\>  
> #11 0x1f345bb \<unknown\>  
> #12 0xe07170 \<unknown\>  
> #13 0x12a91d2 \<unknown\>  
> #14 0x1168ba6 \<unknown\>  
> #15 0x116bd2d \<unknown\>  
> #16 0x116c364 \<unknown\>  
> #17 0x1170a6e \<unknown\>  
> #18 0x117123e \<unknown\>  
> #19 0x12f59b7 \<unknown\>  
> #20 0x28013c8 \<unknown\>  
> #21 0x7f111aa1e1c9 \<unknown\>  
> #22 0x7f1118a9b8d2 \<unknown\>  
> #23 0xffffffffffffffff \<unknown\>
> 
> Trying to get some variables.  
> Some pointers may be invalid and cause the dump to abort.  
> Query (7ef6383dcda0): COMMIT  
> Connection ID (thread ID): 3527  
> Status: NOT\_KILLED
> 
> You may download the Percona XtraDB Cluster operations manual by visiting  
> [Percona XtraDB Cluster: Top MySQL Clustering Alternative](http://www.percona.com/software/percona-xtradb-cluster/). You may find information  
> in the manual which will help you identify the cause of the crash.  
> Log of wsrep recovery (–wsrep-recover):  
> INFO: WSREP: Running position recovery with --log\_error=‘/var/lib/mysql//wsrep\_recovery\_verbose.P8CEIC’ --pid-file=‘/var/lib/mysql//REDACTED-recover.pid’

Here’s a few bits I can share from the my.cnf at this stage:

> innodb-flush-method = O\_DIRECT  
> innodb-log-files-in-group = 2  
> innodb-log-file-size = 2058M  
> innodb-flush-log-at-trx-commit = 2  
> innodb-file-per-table = 1  
> innodb-buffer-pool-size = 89G  
> innodb\_buffer\_pool\_instances = 9  
> innodb\_autoinc\_lock\_mode = 2  
> innodb\_numa\_interleave = OFF
> 
> wsrep\_provider = /usr/lib64/galera4/libgalera\_smm.so  
> wsrep\_cluster\_address=gcomm://REDACTED  
> wsrep\_log\_conflicts  
> wsrep\_cluster\_name = pxc-cluster  
> wsrep\_node\_name = pxc-node-REDACTED  
> pxc\_strict\_mode = ENFORCING  
> wsrep\_sst\_method = xtrabackup-v2  
> wsrep\_applier\_threads = 8  
> wsrep\_sync\_wait = 0  
> wsrep\_provider\_options = “gcache.size=4G”  
> wsrep\_retry\_autocommit = 10

I believe also one of the 3 nodes is acting as the Master to an async DR site elsewhere which may well be a factor.

Just wanted to see initially if anyone had encountered anything similar with PXC8.4.3?

thanks,

Neil

---

<div class="post-metadata">

**Author:** ![Neil\_Billett](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/neil_billett/32/11626_2.png) [@Neil\_Billett](https://forums.percona.com/u/Neil_Billett)\
**Post date:** [April 24, 2025, 11:41am UTC](https://forums.percona.com/t/pxc8-4-3-nodes-crashing-intermittently-with-signal-11/37697/2 "2025-04-24T11:41:42Z")

</div>

Just to follow up on this - I did raise a bug:

> **[Jira](https://perconadev.atlassian.net/browse/PXC-4658)**

…which is believed to be a duplicate of a recent known issue in PXC8.4.3 and 8.4.4:

> **[Jira](https://perconadev.atlassian.net/browse/PXC-4652)**

So looks like nodes are prone to crash in 8.4.3/4 if they also have binary logging enabled although the finder of the original bug suggests that the issue only occurs if:

wsrep\_applier\_threads \> 1

…so seems related to concurrency.

**Update:** setting wsrep\_applier\_threads = 1 on all 3 db nodes in my setup made no difference - crash still occurred.