[MDEV-12082] MariaDB 10.2 crashes at startup with TokuDB enabled Created: 2017-02-19  Updated: 2020-12-01

Status: Confirmed
Project: MariaDB Server
Component/s: Storage Engine - TokuDB
Affects Version/s: 10.2.4
Fix Version/s: 10.2

Type: Bug Priority: Minor
Reporter: jocelyn fournier Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: upstream


 Description   

Hi,

I've just tried to upgrade mariadb 10.0 to mariadb 10.2 on a debian Jessie. Without TokuDB, all is working ok.
However after
apt-get install mariadb-plugin-tokudb

and reenabling TokuDB, it crashes at startup when checking huge_pages :

/home/buildbot/buildbot/build/mariadb-10.2.4/storage/tokudb/PerconaFT/portability/huge_page_detection.cc:110 check_huge_pages_in_practice: Assertion `!vec[i]' failed (errno=13)
 
: Permission denied
 
Backtrace: (Note: toku_do_assert=0x0x6bf5ed922330)
 
/usr/lib/mysql/plugin/ha_tokudb.so(_Z19db_env_do_backtraceP8_IO_FILE+0x1b)[0x6bf5ed92218b]
 
/usr/lib/mysql/plugin/ha_tokudb.so(+0x1212b3)[0x6bf5ed9222b3]
 
/usr/lib/mysql/plugin/ha_tokudb.so(+0x12132e)[0x6bf5ed92232e]
 
/usr/lib/mysql/plugin/ha_tokudb.so(+0x13d2d5)[0x6bf5ed93e2d5]
 
/usr/lib/mysql/plugin/ha_tokudb.so(_Z26toku_os_huge_pages_enabledv+0x4a)[0x6bf5ed93e3ea]
 
/usr/lib/mysql/plugin/ha_tokudb.so(+0x86de5)[0x6bf5ed887de5]
 
/usr/lib/mysql/plugin/ha_tokudb.so(+0x64cd0)[0x6bf5ed865cd0]
 
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x64)[0x90cdb926264]
 
/usr/sbin/mysqld(+0x4e1e7b)[0x90cdb794e7b]
 
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x8da)[0x90cdb7965ba]
 
/usr/sbin/mysqld(+0x43722e)[0x90cdb6ea22e]
 
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0xa35)[0x90cdb6ee5f5]
 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x6bf5f24cbb45]
 
/usr/sbin/mysqld(+0x42ee4d)[0x90cdb6e1e4d]



 Comments   
Comment by Elena Stepanova [ 2017-02-24 ]

Did it work with 10.0? At the first glance I don't see any difference between the versions around this area.

Comment by jocelyn fournier [ 2017-02-24 ]

Hi Elena!

Yes it was working perfectly in 10.0 with my TokuDB tables

Comment by jocelyn fournier [ 2017-02-27 ]

Note I'm using a linux kernel (3.14.32 grsec) without HugePage support. It's the default kernel used in debian for server installed with http://ovh.com
List of Kernel flags used :
ftp://ftp.ovh.net/made-in-ovh/bzImage/3.14.32/config-3.14.32-xxxx-grs-ipv6-64

=>

  1. CONFIG_HUGETLBFS is not set
  2. CONFIG_HUGETLB_PAGE is not set
Comment by jocelyn fournier [ 2017-02-27 ]

I also confirm than compiling & executing alone the check_huge_pages_in_practice() function assert on my debian system without huge page. I've just tested it in another stock debian lenny with huge page enable, and it doesn't assert.

Comment by jocelyn fournier [ 2017-02-27 ]

Workaround to fix the crash :
add in the my.cnf
tokudb_check_jemalloc=OFF

If get_check_thp() is not enabled, tokudb doesn't make the huge page check
It seems at some point, this check has been enabled by default (perhaps related to https://github.com/percona/percona-server/pull/528/files ) and it doesn't work properly with system without huge pages enabled.

Comment by Elena Stepanova [ 2017-03-20 ]

How old was the 10.1 version where it worked all right? From what I see, this change was merged along with TokuDB 5.6.31-77.0 into 10.0 and 10.1 some time in August 2016.

I don't have a kernel without hugepage support to check, but I assume since the change was merged from upstream as is, Percona Server should will be affected, right? In this case we should file a bug report for them. Do you want to do it, or should I?

Comment by jocelyn fournier [ 2017-03-20 ]

It was the latest 10.0 available in debian (so quite recent). I agree upstream should be affected. I will fill a bug report against Percona Server.

Comment by jocelyn fournier [ 2017-03-20 ]

https://bugs.launchpad.net/percona-server/+bug/1674301

Comment by Elena Stepanova [ 2017-03-20 ]

Thank you

Comment by Elena Stepanova [ 2017-09-19 ]

Setting to Confirmed based on the fact that upstream hasn't rejected the report, but re-filed it in their other tracker.
However, there hasn't been any progress on it since then, and in the old tracker it's marked as "Opinion" (whatever it means), so I don't know if a fix will ever happen.
Since it's an upstpream bug with a viable workaround, I'm also reducing the priority.

Generated at Thu Feb 08 07:54:58 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.