[MDEV-27165] crash in base_list_iterator::next Created: 2021-12-03  Updated: 2023-03-28  Resolved: 2022-10-03

Status: Closed
Project: MariaDB Server
Component/s: Server
Affects Version/s: 10.5.13, 10.5, 10.6, 10.7
Fix Version/s: 10.5.18, 10.6.11, 10.7.7, 10.8.6, 10.9.4, 10.10.2

Type: Bug Priority: Critical
Reporter: Rick Pizzi Assignee: Oleksandr Byelkin
Resolution: Duplicate Votes: 1
Labels: None

Attachments: File MDEV-27165.zipaa     File MDEV-27165.zipab     File MDEV-27165.zipac    
Issue Links:
Duplicate
duplicates MDEV-28740 crash in INSERT RETURNING subquery in... Closed
Relates
relates to MDEV-25028 ASAN use-after-poison in base_list_it... Closed
relates to MDEV-25187 Assertion `inited == NONE || table->o... Closed
relates to MDEV-28740 crash in INSERT RETURNING subquery in... Closed

 Description   

A customer is experiencing a crash when running this query:

INSERT INTO
 
        `adWordsKeywordsStats`
 
(
 
        `keywordId`,
 
        `date`,
 
        `clicks`,
 
        `cost`,
 
        `conversions`
 
)
 
VALUES
 
(
 
        (
 
                SELECT
 
                        `internalKeywordId`
 
                FROM
 
                        `webleads_merchantAccounts_adwords`.`adWordsKeywords`
 
                WHERE
 
                        `googleKeywordId` = ? AND
 
                        `accountId` = ? AND
 
                        `campaignId` =
 
                        (
 
                                SELECT
 
                                        `internalCampaignId`
 
                                FROM
 
                                        `webleads_merchantAccounts_adwords`.`adWordsCampaigns`
 
                                WHERE
 
                                        `googleCampaignId` = ?
 
                        ) AND
 
                        `adGroupId` =
 
                        (
 
                                SELECT
 
                                        `internalAdGroupId`
 
                                FROM
 
                                        `webleads_merchantAccounts_adwords`.`adWordsAdGroups`
 
                                WHERE
 
                                        `googleAdGroupId` = ? AND
 
                                        `campaignId` =
 
                                        (
 
                                                SELECT
 
                                                        `internalCampaignId`
 
                                                FROM
 
                                                        `webleads_merchantAccounts_adwords`.`adWordsCampaigns`
 
                                                WHERE
 
                                                        `googleCampaignId` = ?
 
                                        )
 
                        )
 
        ),
 
        CURRENT_DATE,
 
        ?,
 
        ?,
 
        ?
 
)
 
ON DUPLICATE KEY UPDATE
 
        `clicks` = VALUES(`clicks`),
 
        `cost` = VALUES(`cost`),
 
        `conversions` = VALUES(`conversions`)
 
RETURNING
 
        `keywordId`

In 10.5.13 CE this crashes, in 10.5.9 EE it just hangs in state "Executing" (although does not happen every time).

We have core file if you need some structs pasted to this ticket.

Program terminated with signal SIGSEGV, Segmentation fault.
 
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=11) at ../sysdeps/unix/sysv/linux/pthread_kill.c:56
 
56      ../sysdeps/unix/sysv/linux/pthread_kill.c: No such file or directory.
 
[Current thread is 1 (Thread 0x7f08b4338700 (LWP 24318))]
 
(gdb) bt
 
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=11) at ../sysdeps/unix/sysv/linux/pthread_kill.c:56
 
#1  0x000055beb6f00c1f in my_write_core (sig=sig@entry=11) at ./mysys/stacktrace.c:424
 
#2  0x000055beb69509c0 in handle_fatal_signal (sig=11) at ./sql/signal_handler.cc:344
 
#3  <signal handler called>
 
#4  base_list_iterator::next (this=<synthetic pointer>) at ./sql/sql_list.h:431
 
#5  List_iterator<TABLE_LIST>::operator++ (this=<synthetic pointer>) at ./sql/sql_list.h:596
 
#6  st_select_lex::cleanup (this=0x7f088013d2a8) at ./sql/sql_union.cc:2776
 
#7  0x000055beb6a1b48a in subselect_single_select_engine::prepare (this=0x7f088015b9b8, thd=0x7f08800015f8) at ./sql/item_subselect.cc:3852
 
#8  0x000055beb6a1ae76 in Item_subselect::fix_fields (this=0x7f088015b810, thd_param=<optimized out>, ref=0x7f088015ba00) at ./sql/item_subselect.cc:291
 
#9  0x000055beb66d6149 in Item::fix_fields_if_needed (ref=0x7f088015ba00, thd=0x7f08800015f8, this=0x7f088015b810) at ./sql/item.h:986
 
#10 Item::fix_fields_if_needed (ref=0x7f088015ba00, thd=0x7f08800015f8, this=0x7f088015b810) at ./sql/item.h:986
 
#11 Item::fix_fields_if_needed_for_scalar (ref=0x7f088015ba00, thd=0x7f08800015f8, this=0x7f088015b810) at ./sql/item.h:992
 
#12 setup_fields (thd=thd@entry=0x7f08800015f8, ref_pointer_array=..., fields=..., column_usage=column_usage@entry=MARK_COLUMNS_READ, sum_func_list=sum_func_list@entry=0x0, pre_fix=0x0, allow_sum_func=false) at ./sql/sql_base.cc:7650
 
#13 0x000055beb66ff38d in mysql_prepare_insert (thd=thd@entry=0x7f08800015f8, table_list=table_list@entry=0x7f088013c008, fields=..., values=values@entry=0x7f088013d290, update_fields=..., update_values=..., duplic=DUP_UPDATE,
 
    where=0x7f08b43368f8, select_insert=false) at ./sql/sql_array.h:38
 
#14 0x000055beb67059cf in mysql_insert (thd=thd@entry=0x7f08800015f8, table_list=0x7f088013c008, fields=..., values_list=..., update_fields=..., update_values=..., duplic=<optimized out>, ignore=<optimized out>, result=<optimized out>)
 
    at ./sql/sql_insert.cc:769
 
#15 0x000055beb674130d in mysql_execute_command (thd=0x7f08800015f8) at ./sql/sql_parse.cc:4624
 
#16 0x000055beb6755a05 in Prepared_statement::execute (this=0x7f0880162a48, expanded_query=<optimized out>, open_cursor=false) at ./sql/sql_prepare.cc:5065
 
#17 0x000055beb6755bd9 in Prepared_statement::execute_loop (packet=<optimized out>, packet_end=<optimized out>, open_cursor=<optimized out>, expanded_query=0x7f08b4337220, this=0x7f0880162a48) at ./sql/sql_prepare.cc:4509
 
#18 Prepared_statement::execute_loop (this=0x7f0880162a48, expanded_query=0x7f08b4337220, open_cursor=<optimized out>, packet=<optimized out>, packet_end=<optimized out>) at ./sql/sql_prepare.cc:4464
 
#19 0x000055beb6756a95 in mysql_stmt_execute_common (thd=0x7f08800015f8, stmt_id=<optimized out>, packet=0x7f0880008a12 "", packet_end=0x7f0880008a63 "", cursor_flags=0, bulk_op=<optimized out>, read_types=false)
 
    at ./sql/sql_prepare.cc:3470
 
#20 0x000055beb6756cd0 in mysqld_stmt_execute (thd=thd@entry=0x7f08800015f8, packet_arg=packet_arg@entry=0x7f0880008a09 "\a", packet_length=packet_length@entry=90) at ./sql/sql_prepare.cc:3244
 
#21 0x000055beb673d827 in dispatch_command (command=COM_STMT_EXECUTE, thd=0x7f08800015f8, packet=<optimized out>, packet_length=<optimized out>, is_com_multi=<optimized out>, is_next_command=<optimized out>) at ./sql/sql_parse.cc:1815
 
#22 0x000055beb673f28c in do_command (thd=0x7f08800015f8) at ./sql/sql_parse.cc:1370
 
#23 0x000055beb6846671 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55beb952aea8, put_in_cache=put_in_cache@entry=true) at ./sql/sql_connect.cc:1418
 
#24 0x000055beb6846aed in handle_one_connection (arg=arg@entry=0x55beb952aea8) at ./sql/sql_connect.cc:1312
 
#25 0x000055beb6baa876 in pfs_spawn_thread (arg=0x55beb9558ff8) at ./storage/perfschema/pfs.cc:2201
 
#26 0x00007f08bef85609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 
#27 0x00007f08beb73293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95



 Comments   
Comment by Elena Stepanova [ 2021-12-03 ]

This is a generic crash/stack trace, we probably have a couple dozen open bugs each of which can be related.
Can you narrow it down a bit, or provide a complete test case (CREATE, INSERT if necessary, PREPARE, EXECUTE with bounds)?
Say, does it still crash without RETURNING? Does it still crash without ON DUPLICATE KEY UPDATE? Does it crash on the 1st or the 2nd execution of the prepared statement? Does it require such a complicated VALUES list? Etc.

Comment by Alice Sherepa [ 2021-12-10 ]

Thank you!
I repeated on 10.5-10.7, 10.5 is a version where INSERT ..RETURNING was introduced

CREATE TABLE t1 ( id int, a int);
 
CREATE TABLE t2 ( id int);
 
EXECUTE immediate "INSERT INTO t1 VALUES (( SELECT 1 from t2),999999999999) RETURNING id ";

10.5 a9b5f5998927b423b39f8ff

 
mariadbd: /10.5/src/sql/sql_prepare.cc:3080: void reinit_stmt_before_use(THD*, LEX*): Assertion `sl->join == 0' failed.
 
211210 18:36:59 [ERROR] mysqld got signal 6 ;
 
 
 
 
 
Server version: 10.5.14-MariaDB-debug-log
 
 
 
??:0(__assert_fail)[0x7fa930a6ef36]
 
sql/sql_prepare.cc:3083(reinit_stmt_before_use(THD*, LEX*))[0x56274b8194b7]
 
sql/sql_prepare.cc:5047(Prepared_statement::execute(String*, bool))[0x56274b826dae]
 
sql/sql_prepare.cc:4509(Prepared_statement::execute_loop(String*, bool, unsigned char*, unsigned char*))[0x56274b82225f]
 
sql/sql_prepare.cc:5194(Prepared_statement::execute_immediate(char const*, unsigned int))[0x56274b8281ee]
 
sql/sql_prepare.cc:2995(mysql_sql_stmt_execute_immediate(THD*))[0x56274b818987]
 
sql/sql_parse.cc:4012(mysql_execute_command(THD*))[0x56274b7b59be]
 
sql/sql_parse.cc:8100(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x56274b7d1d5a]
 
sql/sql_parse.cc:1894(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x56274b7a7c15]
 
sql/sql_parse.cc:1370(do_command(THD*))[0x56274b7a4554]
 
sql/sql_connect.cc:1418(do_handle_one_connection(CONNECT*, bool))[0x56274bbef6c7]
 
sql/sql_connect.cc:1314(handle_one_connection)[0x56274bbeeee0]
 
perfschema/pfs.cc:2203(pfs_spawn_thread)[0x56274c90dfb3]
 
nptl/pthread_create.c:478(start_thread)[0x7fa930f87609]
 
??:0(clone)[0x7fa930b5a293]
 
 
 
Query (0x62b000038c28): INSERT INTO t1 VALUES (( SELECT 1 from t2),999999999999) RETURNING id

Comment by Rick Pizzi [ 2021-12-10 ]

alice so is the bug about the "insert.. returning" feature?

Comment by Elena Stepanova [ 2021-12-10 ]

MDEV-25028 is likely to be related

Comment by Rucha Deodhar [ 2022-09-29 ]

Patch: https://github.com/MariaDB/server/commit/220aa7f30e0a677940f0c14ea56203ad72189e54

Generated at Thu Feb 08 09:50:50 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.