Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-22271

Excessive stack memory usage due to WSREP_LOG

    XMLWordPrintable

    Details

      Description

      Several tests fail on 10.4 kvm-asan due to stack overrun:

      10.4 af912664989e0c3ee9cdb6caf8ec439029e7405c

      Failing test(s): sys_vars.max_sp_recursion_depth_func main.signal_demo3 compat/oracle.sp-package rpl.rpl_row_sp011 main.sp
      

      The main contributor to this stack overrun is mysql_execute_command().

      Rebuilding with cmake -DWITH_WSREP=OFF shrunk the size of the mysql_execute_command() stack frame in the ASAN debug build from 29312 to 17568 bytes. A quick and dirty workaround made the tests pass:

      diff --git a/sql/wsrep_mysqld.h b/sql/wsrep_mysqld.h
      --- a/sql/wsrep_mysqld.h
      +++ b/sql/wsrep_mysqld.h
      @@ -245,7 +245,7 @@ extern wsrep_seqno_t wsrep_locked_seqno;
       // prefix all messages with "WSREP"
       #define WSREP_LOG(fun, ...)                                       \
           do {                                                          \
      -        char msg[1024]= {'\0'};                                  \
      +        char msg[1]= {'\0'};                                  \
               snprintf(msg, sizeof(msg) - 1, ## __VA_ARGS__);           \
               fun("WSREP: %s", msg);                                    \
           } while(0)
      

      It turns out that this bug had been fixed in MariaDB 10.3.1 but the fix was destroyed in the Galera 4 merge (MDEV-16405).

      This bug should affect all builds, especially affecting the execution of complex stored procedures, which involves recursive calls to mysql_execute_command(). The WSREP_DEBUG macro invocations will expand to WSREP_LOG also in non-debug builds, and obviously, the stack memory will be allocated even with the default settings (WSREP or Galera are disabled).

        Attachments

          Activity

            People

            Assignee:
            marko Marko Mäkelä
            Reporter:
            marko Marko Mäkelä
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: