Matomo crashes my mariadb database

Hi, we use Matomo since a long time (archives date back til 2006 :slight_smile: ), but today our mariadb database was crashed by Matomo :frowning_face:.

From the DB dump (see below) there is a very long/cryptic SQL query, which seems to have been generated by core/RankingQuery / generateRankingQuery(…).
I’m not sure, if I need to adjust some Mariadb config parameters, or if this is really a bug. Can anybody help?

Here is the relevant mysqld.log part:

190218 12:11:58 [ERROR] mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.0.35-MariaDB
key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=152
max_threads=153
thread_count=27
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 371914 K bytes of memory
Hope that’s ok; if not, decrease some variables in the equation.

Thread pointer: 0x5618a621e218
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong…
stack_bottom = 0x7f52fb802ed8 thread_stack 0x48000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0x5618a46d7af9]
/usr/sbin/mysqld(handle_fatal_signal+0x465)[0x5618a42ec395]
/lib64/libpthread.so.0(+0x10c10)[0x7f538f5ddc10]
/usr/sbin/mysqld(+0x6a6c9d)[0x5618a4461c9d]
/usr/sbin/mysqld(_Z15end_read_recordP11READ_RECORD+0x7a)[0x5618a43da49a]
/usr/sbin/mysqld(_ZN4JOIN7cleanupEb+0x3e8)[0x5618a41e6c88]
/usr/sbin/mysqld(_ZN4JOIN7destroyEv+0x14c)[0x5618a41e6ebc]
/usr/sbin/mysqld(_ZN13st_select_lex7cleanupEv+0x28)[0x5618a4232748]
/usr/sbin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_uni
tP13st_select_lex+0x200)[0x5618a41f5150]
/usr/sbin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x264)[0x5618a41f5ad4]
/usr/sbin/mysqld(+0x3e9193)[0x5618a41a4193]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x54a0)[0x5618a41afe20]
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x1e8)[0x5618a41b2108]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19f0)[0x5618a41b4140]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x1c4)[0x5618a4266664]
/usr/sbin/mysqld(handle_one_connection+0x37)[0x5618a42666f7]
/lib64/libpthread.so.0(+0x8724)[0x7f538f5d5724]
/lib64/libc.so.6(clone+0x6d)[0x7f538e3c5e8d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x5618a622acc0): SELECT

                            CASE
                                    WHEN counter = 50001 THEN '-1'
                                    ELSE `idaction`
                            END AS `idaction`
                    ,
                            CASE
                                    WHEN counter = 50001 THEN '-1'
                                    ELSE `name`
                            END AS `name`

                            , `url_prefix`, min(`28`) AS `28`, sum(`29`) AS `29`, sum(`2`) AS `2`, `1`, sum(`12`) AS `12`, sum(`30`) AS `30`, sum(`31`) AS `31`, min(`32`) AS `32`, max(`33`) AS `33`, `type`
                    FROM (
                    SELECT
                            `idaction`, `name`,

                    CASE
                            WHEN `type` = 1 AND @counter1 = 50001 THEN 50001
                            WHEN `type` = 1 THEN @counter1:=@counter1+1
                            WHEN `type` = 2 AND @counter2 = 50001 THEN 50001
                            WHEN `type` = 2 THEN @counter2:=@counter2+1
                            WHEN `type` = 3 AND @counter3 = 50001 THEN 50001
                            WHEN `type` = 3 THEN @counter3:=@counter3+1
                            WHEN `type` = 4 AND @counter4 = 50001 THEN 50001
                            WHEN `type` = 4 THEN @counter4:=@counter4+1
                            WHEN `type` = 8 AND @counter8 = 50001 THEN 50001
                            WHEN `type` = 8 THEN @counter8:=@counter8+1
                            ELSE 0
                    END
             AS counter
                            , `url_prefix`, `28`, `29`, `2`, `1`, `12`, `30`, `31`, `32`, `33`, `type`
                    FROM
                            ( SELECT @counter1:=0 ) initCounter1, ( SELECT @counter2:=0 ) initCounter2, ( SELECT @counter3:=0 ) initCounter3, ( SELECT @counter4:=0 ) initCounter4, ( SELECT @counter8:=0 ) initCounter8,
                            ( SELECT /* Actions */
                            log_action.name,
            log_action.type,
            log_action.idaction,
            log_action.url_prefix, count(distinct log_link_visit_action.idvisit) as `2`, count(distinct log_link_visit_action.idvisitor) as `1`, count(*) as `12`, sum(
                    case when custom_float is null
                        then 0
                        else custom_float
                    end
            ) / 1000 as `30`, sum(
                case when custom_float is null
                    then 0
                    else 1
                end
            ) as `31`, min(custom_float) / 1000 as `32`, max(custom_float) / 1000 as `33`,
            CASE WHEN (MAX(log_link_visit_action.custom_var_v5) = 0
                AND log_link_visit_action.custom_var_k5 = '_pk_scount')
            THEN 1 ELSE 0 END
                AS `28`,
            SUM( CASE WHEN log_action_name_ref.type = 8
                  THEN 1 ELSE 0 END)
                AS `29`
                    FROM
                            p_log_link_visit_action AS log_link_visit_action LEFT JOIN p_log_action AS log_action ON log_link_visit_action.idaction_name = log_action.idaction LEFT JOIN p_log_action AS log_action_name_ref ON log_link_visit_action.idaction_name_ref = log_action_name_ref.idaction
                    WHERE
                            log_link_visit_action.server_time >= '2019-02-17 23:00:00'
                            AND log_link_visit_action.server_time <= '2019-02-18 22:59:59'
                            AND log_link_visit_action.idsite IN ('29') AND log_link_visit_action.idaction_name IS NOT NULL AND log_link_visit_action.idaction_event_category IS NULL
                    GROUP BY
                            log_link_visit_action.idaction_name
                    ORDER BY
                            `12` DESC, name ASC ) actualQuery
             ) AS withCounter
                    GROUP BY counter, `type`

Connection ID (thread ID): 215723
Status: NOT_KILLED

Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=off

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Hi,

Honsetly I have not really an idea why this happens, so this is just a random guess, but Matomo should never be able to crash MariaDB no matter what happens.

I see that you are using 10.0.35, is there any reason for this? Is it still supported by your distribution?
Even debian jessie the oldstable version ships 10.0.38 which is newer.