[MDEV-31257] Crash/signal 11 when running specific SQL query after update to 10.6.13 Created: 2023-05-12  Updated: 2023-05-16  Resolved: 2023-05-16

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.6.13
Fix Version/s: 11.0.2, 10.4.30, 10.5.21, 10.6.14, 10.9.7, 10.11.4

Type: Bug Priority: Major
Reporter: Brad Assignee: Sergei Petrunia
Resolution: Duplicate Votes: 0
Labels: None
Environment:

Centos 7


Attachments: Text File vmcstone-mariadb-crash.txt    

 Description   

Our client noticed a problem with a cron job in their site after the 10.6.13 update. Looking into the issue, I found that a specific SQL query is causing the problem.

For now, I've downgraded this server to 10.6.12 and it's working fine again.

I've attached the log messages that happen during the event. I can reproduce the problem easily so if I need to get more information, let me know.

Here is the SQL command that triggers the crash.

SELECT ItemView.Name AS ItemName,ItemView.Country AS Country,ItemView.Color AS Color,ItemView.SlabType AS SlabType,ItemView.PattName AS PattName,ItemView.ItemImagePath AS ItemImagePath,ItemView.Seq AS Seq,ItemView.ItemID AS SKU,ItemView.SecondaryColor AS SecondaryColor,ItemView.ColorTone AS ColorTone,ItemView.Pattern AS Pattern,ItemView.Collection AS Collection,ItemView.Classification AS Classification,ListPrices.Price1 AS LP,ListPrices.Price2 AS FP,ListPrices.Price3 AS BP,ListPrices.Price4 AS DP,SlabView.Thickness AS Thickness,Item.SubCategoryValue AS SubCategoryValue,Item.IsNewArival AS IsNewArival,SalePrice.SlabLength AS SlabLength,SalePrice.SlabWidth AS SlabWidth,SalePrice.IDTwo AS IDTwo,SalePrice.LocationName AS LocationName,min(SalePrice.InventoryStatus) AS InventoryStatus,SalePrice.Slabs AS Slabs, SUM(CASE WHEN SalePrice.InventoryStatus = 'INSTOCK' THEN 1 ELSE 0 END) as AvailableSlabs, SalePrice.SeqNo AS SeqNo,SalePrice.SaleLP AS SaleLP,SalePrice.SaleFP AS SaleFP,SalePrice.SaleBP AS SaleBP,SalePrice.SaleDP AS SaleDP,SalePrice.ImagePath AS ImagePath,SalePrice.Bin AS BIN, CASE WHEN SalePrice.SaleFP > 0 THEN MIN(SalePrice.SaleFP) ELSE MAX(ListPrices.Price2) END AS FinalPrice, (select tr.SlabCount from Custom_TrendingStones tr where ItemView.ItemID = tr.SKU) AS SlabCount, Item.SubItemType, Item.ItemGroupValue, (SELECT Available FROM Hold_Custom_AvailableSlabs as a WHERE a.SKU = Item.SKU) as Available from ((((Custom_ItemView AS ItemView left join Custom_SalePrice AS SalePrice on(ItemView.ItemID = SalePrice.SKU)) left join Item AS Item on(ItemView.ItemID = Item.SKU)) left join Custom_SlabView AS SlabView on(ItemView.ItemID = SlabView.ItemID)) left join R_ListPrices AS ListPrices on(ItemView.ItemID = ListPrices.SKU)) where (ItemView.ItemID like 'SMQ%' or ItemView.ItemID like 'SMM%' or ItemView.ItemID like 'NM%' or ItemView.ItemID like 'NG%' or ItemView.ItemID like 'NQ%' or ItemView.ItemID like 'VDQ%' or ItemView.ItemID like 'NTG%' or ItemView.ItemID like 'NTQ%' or ItemView.ItemID like 'NTM%' or ItemView.ItemID like 'LSS%') and ItemView.ItemID in (select tr.SKU from Custom_TrendingStones tr where ItemView.ItemID = tr.SKU) group by ItemView.ItemID,SalePrice.SlabLength,SalePrice.SlabWidth,SalePrice.IDTwo, Item.SubCategoryValue order by (select tr.SlabCount from Custom_TrendingStones tr where ItemView.ItemID = tr.SKU) desc;

Any ideas what could be causing this?

Thanks!



 Comments   
Comment by Elena Stepanova [ 2023-05-12 ]

This looks like MDEV-31240 / MDEV-31241. I'll leave it to psergei to confirm.

Comment by Won Kyu Jeong [ 2023-05-12 ]

I have a similar issue after upgrading to 10.10.4 from 10.10.3.
will the fix also apply to the 10.10 as well?
Also, how did you downgrade the version? was it through backing up all the data and reinstalling the older version? I need to downgrade MariaDB back to 10.10.3 without losing any data.

Comment by Brad [ 2023-05-12 ]

I can't comment on the fix but I think it should be based on what I'm reading in the other tickets.

Downgrading isn't that hard but could be different on your system. For me, I ran the following to downgrade to the previous release and lock the version for now (don't forget to undo this later).

yum downgrade MariaDB-server-10.6.12-1.el7.centos MariaDB-client-10.6.12-1.el7.centos MariaDB-compat-10.6.12-1.el7.centos MariaDB-common-10.6.12-1.el7.centos
yum versionlock add MariaDB-server MariaDB-client MariaDB-compat MariaDB-common

You can unlock and update later like this:

yum versionlock delete MariaDB-server MariaDB-client MariaDB-compat MariaDB-common

Comment by Sergei Petrunia [ 2023-05-16 ]

Yes, the stack trace points at MDEV-31240 / MDEV-31241. In the attached file vmcstone-mariadb-crash.txt :

 /usr/sbin/mariadbd(_ZN13st_join_table21choose_best_splittingEjyPy+0x9b1)[0x558eba35eec1]
/usr/sbin/mariadbd(_Z16best_access_pathP4JOINP13st_join_tableyPK8POSITIONjbdPS3_S6_+0x132)[0x558eba218612]
/usr/sbin/mariadbd(+0x81bd68)[0x558eba21bd68]
/usr/sbin/mariadbd(_Z11choose_planP4JOINy+0x257)[0x558eba21c997]
/usr/sbin/mariadbd(_ZN4JOIN14optimize_innerEv+0x3119)[0x558eba225849]
/usr/sbin/mariadbd(_ZN4JOIN8optimizeEv+0xb2)[0x558eba225f92]
/usr/sbin/mariadbd(_ZN13st_select_lex31optimize_unflattened_subqueriesEb+0xc8)[0x558eba1b0c38]

(One can't see the crashing subquery in query text because it's inside a view)

But the stack trace in this case is unique enough to point at MDEV-31240 / MDEV-31241.

Comment by Sergei Petrunia [ 2023-05-16 ]

Closing as duplicate of MDEV-31240

Generated at Thu Feb 08 10:22:28 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.