You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bug#36655831: Segfault ALTER EVENT query executed using MLE sql-callout regular statement
Problem: Executing EVENT statement without an event body inside MLE SP
caused segv.
Root cause: Recursive stored programs are not allowed. This is enforced by the
parser when it checks if thd->lex->sphead is already set before parsing
another SP. Events are a type of SP which also uses thd->lex->sphead so
this restriction also means that a stored procedure cannot contain event
statements.
The Regular_statement_handle interface adds an extra twist to this because
each normal statement is executed internally using a prepared statement.
Normally, this would break the check for recursive SPs, since the
prepared statement has its own lex, and its sphead is not set (is nullptr).
But since these internal prepared statements have their m_lex->sphead set to refrence
the sp_head of the enclosing SP it still works and we get the expected error.
WL#16298 allowes event statements to be prepared, and when the parser is
invoked it assigns the sp_head for the event body to PS->m_lex->sphead,
and as mentioned above, this means that the prepared event statement can
appear inside an SP, without triggering the recursion error. The code
for wl#16298 also made the assumption that it was ok to unconditionally
assign thd->lex->sphead (actually PS->m_lex->sphead) to
Event_parse_data::event_body, since either
A) the event statement does not have a body and then thd->lex->sphead (PS->m_lex->sphead) is nullptr
or,
B) the event statement has an event body and then thd->lex->sphead
(PS->m_lex->sphead) will have been assigned by the parser.
However, for the internal prepared statement of an MLE SP A) does not
hold and the result was that an incorrect reference to the MLE SP's
sp_head was placed inside Event_parse_data::even_body, which would then
be destroyed when the prepared statement was deallocated, leaving
dangling pointers to it, which in turn caused this bug.
Solution: Check Event_parse_data::body_changed, which is set by the parser after
parsing an event body, before assuming that LEX::sphead is referencing an event
body. This ensures that the destruction of Event_parse_data does not
deallocate sp_head for the MLE procedure itself.
Change-Id: I5948eab8499de6d1cfd2d88b08728c2733bcd3c0
0 commit comments