[MDEV-22761] InnoDB: Assertion failure row0sel.cc line 3966 exception 0x80000003 Created: 2020-05-31 Updated: 2020-12-17 Resolved: 2020-10-13 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Server, Storage Engine - InnoDB |
| Affects Version/s: | 10.4.13, 10.5.3, 10.5.5 |
| Fix Version/s: | 10.4.16, 10.5.7 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Rigoberto Munguia | Assignee: | Daniel Black |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | crash, innodb, not-10.1, not-10.2, not-10.3, regression, regression-10.4 | ||
| Environment: |
Windows Server 2016 VM, 16 core 40GB RAM. |
||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Description |
|
MariaDB Server crashes during select
----------
|
| Comments |
| Comment by Silver Asu [ 2020-07-06 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
We had same buffer overflow on linux.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mykhaylo Poboynyy [ 2020-07-20 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
We have this Problem too. In our CI, will be every 2 Hours one database new created and over 1 hour is intensive in use. After 6 or 7 days we have the same crash. 2020-07-17 14:48:05 0xf10 InnoDB: Assertion failure in file D:\winx64-packages\build\src\storage\innobase\row\row0sel.cc line 3966 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 Server version: 10.4.13-MariaDB Thread pointer: 0x1e925bae748 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Silver Asu [ 2020-09-25 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Can we have more priority for this?
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Black [ 2020-09-30 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
marko I've pushed the bb-10.4-danielblack- It seems CHECK_ABORTED_BY_USER wasn't handled correctly. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Black [ 2020-09-30 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Work around for the mean time - don't kill threads with 'optimizer_switch=index_condition_pushdown=on'. index condition pushdown overview is per our knowledge base. This might cause some performance degradation of queries (better than a crash however). show variables like 'Handler_icp%' for an estimate of its current use. Alternately 10.4.12 is unaffected. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2020-09-30 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
danblack, is this really optimizer_switch=index_condition_pushdown=on, or rowid_filter=ON ? I see that the patch makes the change here:
which imples that rowid filter check was done while ICP check wasn't? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2020-09-30 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
danblack One thing that's obviously missing in the patch is test coverage. AFAIU it should be easy to add using debug_sync ? (EDIT: sorry, missed the exchange about it. Could it be that the difficulty in constructing a testcase is due to the query needing to use rowid filter, not ICP?) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Black [ 2020-09-30 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Quite right psergey its obviously rowid_filter and for @users disabling this will avoid the bug for now. After taking some existing rowid_filter test I've come up with Its currently not entering the '!h->pushed_idx_cond' section of handler_rowid_filter_check. Can you advice as how to trigger this condition in the test? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Black [ 2020-10-03 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
psergey bb-10.4-danielblack- | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2020-10-08 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Ok looking | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2020-10-09 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This shows that the killed query does not return any errors. This is not good. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2020-10-09 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I've tried to construct a bigger example, and there, it does return "Query execution was interrupted" error... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2020-10-09 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Ok this happened, because the bigger example was a join of two tables
The KILL arrives into rowid filter check on table t3. It causes the read on t3 to return HA_ERR_KEY_NOT_FOUND. So it continues the full table scan on table t2, and execution arrives here in row_search_mvcc():
where the thread-killed condition is detected. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2020-10-09 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Pushed another commit into https://github.com/MariaDB/server/commits/bb-10.4-danielblack-MDEV-22761 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Black [ 2020-10-09 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
pushed dbba393023344d0943e76da87372f12f9274054e to the end of the branch as there where two more calls to row_search_idx_cond_check that needed to handle the CHECK_ABORTED_BY_USER => DB_INTERRUPTED in the same way. Isn't
Going to leave the storage engine in aria for non-debug tests with default_storage_engine=aria? Nice use of `evalp kill query $target_id` | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Black [ 2020-10-10 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The handling of killing the query also applies to 10.1 under ICP_ABORTED_BY_USER conditions. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Black [ 2020-10-12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Ported ICP patches fixes and tests (excluding rowid_filter) to 10.1 - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2020-10-13 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
but it sets the storage engine back: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2020-10-13 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The rest of the `dbba393023344d0943e76da87372f12f9274054e` looks good to me. This one looks odd https://buildbot.askmonty.org/buildbot/builders/kvm-fulltest2/builds/25001/steps/mtr_ps_emb/logs/stdio ... but should be counted as un-related? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Sergei Petrunia [ 2020-10-13 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re-based the tree on the latest 10.4 and pushed. |