MySQL 5.7 Error

After upgrading to MySQL 5.7, I cannot view the MySQL module from within webmin. MySQL restarts just fine, but the miniserv.error generates the following line when trying to access MySQL Database Server from within webmin.

e/webmin/mysql/index.cgi: malloc.c:3700: _int_malloc: Assertion `victim->fd_nextsize->bk_nextsize == victim' failed.

Status: 
Active

Comments

tgillespie's picture
Submitted by tgillespie on Mon, 03/14/2016 - 14:45

Assigned: » Unassigned

Wow, that's an odd error! It looks like it is coming from inside Perl, rather than any Webmin/Virtualmin code.

How many databases and tables do you have there?

tgillespie's picture
Submitted by tgillespie on Mon, 03/14/2016 - 23:31

I probably have 8 databases on the server... most of them WordPress with one install of Xenforo. Nothing crazy.

I also noticed this in miniserv.error. My virtmin configuration check fails.

*** Error in `/usr/share/webmin/virtual-server/collectinfo.pl': double free or corruption (!prev): 0x00000000073b4d30 ***
*** Error in `/usr/share/webmin/virtual-server/collectinfo.pl': double free or corruption (!prev): 0x00000000073ffbf0 ***
tgillespie's picture
Submitted by tgillespie on Mon, 03/14/2016 - 23:43

my.cnf is that helps.

[client]
port            = 3306
socket          = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket          = /var/run/mysqld/mysqld.sock
nice            = 0

[mysqld]
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir         = /usr
datadir = /var/lib/mysql
tmpdir          = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
key_buffer_size              = 16M
max_allowed_packet      = 64M
thread_stack            = 192K
thread_cache_size       = 8
query_cache_type        = 1
query_cache_limit       = 1M
query_cache_size        = 32M
log_error                = /var/log/mysql/error.log
expire_logs_days        = 10
max_binlog_size         = 100M
big-tables
bind-address = 127.0.0.1
log_error = /var/log/mysql/error.log
expire_logs_days        = 10
max_binlog_size         = 100M

[mysqldump]
quick
quote-names
max_allowed_packet      = 16M

[mysql]

[isamchk]
key_buffer              = 16M

!includedir /etc/mysql/conf.d/
Joe's picture
Submitted by Joe on Tue, 03/15/2016 - 00:09 Pro Licensee

Is this running on a VPS running under OpenVZ/Virtuozzo , perchance? This looks like memory allocation problems, so if it is a VPS running Virtuozzo/OpenVZ (or other virtualization type that allows overselling memory) then you're hitting memory problems. Memory that the OS reports as available isn't actually. If it is a dedicated box, then I think you should run memtest on it.

Webmin/Virtualmin really doesn't do anything that could tickle this kind of error. It's at a quite low level. I guess if you were using a custom Perl build, that could also be a culprit.

tgillespie's picture
Submitted by tgillespie on Tue, 03/15/2016 - 10:54

Its a dedicated box using ECC mem running Ubuntu Server 14.04. I might try downgrading to MySQL 5.6 to see if the errors disappear.... never had an issue until the upgrade.

Doing some research on that problem, it sounds like it could possibly be due to a Perl bug in certain Perl versions.

One suggestion was to try upgrading the "threads" and "threads::shared" modules from CPAN, which seems to resolve that issue for some people.

tgillespie's picture
Submitted by tgillespie on Tue, 03/15/2016 - 15:18

Just did an entire cpan update and still getting the error. I checked threads and threads::shared and they are respectively the most current version. I cannot access the following through Webmin: MySQL Database Server, Virtualmin > Edit Users, Virtualmin > Edit Databases, Virtualmin > Recheck Configuration.

cpan[1]> install threads
Reading '/home/tgillespie/.cpan/Metadata'
  Database was generated on Tue, 15 Mar 2016 11:29:02 GMT
threads is up to date (2.02).

cpan[2]> install threads::shared
threads::shared is up to date (1.48).
tgillespie's picture
Submitted by tgillespie on Wed, 03/16/2016 - 22:12

So, no clue what the problem was, but a complete removal of MySQL and a fresh install seems to have fixed it. Now onto fixing Postfix.