Crash in INSERT...SELECT..RETURNING with subquery
Underlying causes of all bugs mentioned below are same. This patch fixes all of them: 1) MDEV-25028: ASAN use-after-poison in base_list_iterator::next or Assertion `sl->join == 0' upon INSERT .. RETURNING via PS 2) MDEV-25187: Assertion `inited == NONE || table->open_by_handler' failed or Direct leak in init_dynamic_array2 upon INSERT .. RETURNING and memory leak in init_dynamic_array2 3) MDEV-28740: crash in INSERT RETURNING subquery in prepared statements 4) MDEV-27165: crash in base_list_iterator::next 5) MDEV-29686: Assertion `slave == 0' failed in st_select_lex_node::attach_single Analysis: consider this statement: INSERT(1)...SELECT(2)...(SELECT(3)...) RETURNING (SELECT(4)...) When RETURNING is encountered, add_slave() changes how selects are linked. It makes the builtin_select(1) slave of SELECT(2). This causes losing of already existing slave(3) (which is nested select of SELECT of INSERT...SELECT). When really, builtin_select (1) shouldn't be slave to SELECT(2) because it is not nested within it. Also, push_select() to use correct context also changed how select are linked. During reinit_stmt_before_use(), we expect the selects to be cleaned-up and have join=0. Since these selects are not linked correctly, clean-up doesn't happen correctly so join is not NULL. Hence the crash. Fix: IF we are parsing RETURNING, make is_parsing_returning= true for current select. get rid of add_slave(). In place of push_select(), used push_context() to have correct context (the context of builtin_select) to resolve items in item_list. And add these items to item_list of builtin_select.
Showing
Please register or sign in to comment