Hi,

Could you please run
ls -l var/log/maria.maria-no-logging/mysqld.1/data/
from your mysql-test directory after you get the failure?
Thanks.

Hi Elena,

15:41:17$ ls -l var/log/maria.maria-no-logging/mysqld.1/data/
total 36
rw-rw--- 1 root root 16384 Oct 10 12:49 aria_log.00000001
rw-rw--- 1 root root 52 Oct 10 12:49 aria_log_control
drwxr-xr-x 2 root root 4096 Oct 10 12:49 mtr
drwxr-xr-x 2 root root 4096 Oct 10 12:49 mysql
drwxr-xr-x 2 root root 4096 Oct 10 12:49 performance_schema
drwxr-xr-x 2 root root 4096 Oct 10 12:49 test
15:41:40$

Cheers ... Duncan.

Hi again Elena,

I also added ls -lR as an attachment,

Cheers ... Duncan.

Hi Elena,

I built and installed mariadb as it will build and install in the next Slackware release (as far as I can tell). I've uploaded a tar.gz of a directory with build instructions and all necessary files except the source archive. This is the README:

To build mariadb for Slackware installation, first make a symbolic link to the source archive, e.g.

"ln -s /usr/gz/mariadb-10.0.4.tar.gz " It doesn't matter if archive is gz, xz or bz2.

You now have to run mariadb.SlackBuild as root - but this is your Slackware system, right? mariadb.SlackBuild is minimally altered from the script on the Slackware site (which only build xz archives) - you can inspect with rcsdiff.

You need to tell the build to install the test suite, and you probably want to give it a special build ID (the patches to fix 2 tests are new). I used:

KEEPTESTS=1 BUILD=1TSTEVT ./mariadb.SlackBuild

EVT is in the ID because I have installed libevent. This is not standard in Slackware 14.0 but appears to be slated for the next Slackware release (you can find the build directory at ftp.osuosl.org/pub/slackware/slackware-current/source/l/libevent).

The last item the build script displays should be "Slackware package /tmp/mariadb-10.0.4-i486-1TSTEVT.txz created"

To install:

installpkg /tmp/mariadb-10.0.4-i486-1TSTEVT.txz

On a standard system, this will probably create /etc/rc.mysqld.new, which replaces the existing script that starts mysqld. I have found that tests don't run if the server is started, so so don't start it yet. The test should now give you the same result as I get.

N.B. This is for 32-bit x86.

Tried again at 10.0.7 but still fails for me

Still fails at 10.0.8

We got a report that the test started failing the same way on 32-bit Debian Sid, apparently after recent upgrades to Sid. 64-bit Sid doesn't seem to be affected.

It's reproducible with the current 10.0 tree.

I'm raising the priority because it is not just tests, it really affects the server, show engine aria logs produces the corrupted output. While it isn't clear whether it's a code bug or a system bug, I'm assigning to Monty since he volunteered to investigate.

The failure looks very much alike what I've seen on Debian Sid after about Sept 20th in my i386 builds (not amd64): http://labs.seravo.fi/~otto/mariadb-repo/logs/maria.maria-no-logging/mariadb-10.0_10.0.14-1_sid-i386.build

maria.maria-no-logging                   [ fail ]

        Test ended at 2014-09-28 13:12:33

CURRENT_TEST: maria.maria-no-logging

--- /tmp/buildd/mariadb-10.0-10.0.14/mysql-test/suite/maria/maria-no-logging.result	2014-09-24 22:29:46.000000000 +0000

+++ /tmp/buildd/mariadb-10.0-10.0.14/mysql-test/suite/maria/maria-no-logging.reject	2014-09-28 13:12:32.980386165 +0000

@@ -20,18 +20,18 @@

 ) ENGINE=Aria DEFAULT CHARSET=latin1 PAGE_CHECKSUM=1 TRANSACTIONAL=1

 show engine aria logs;

 Type	Name	Status

-Aria	Size        16384 aria_log.00000001	unknown

+Aria	Size        16384 ; ???�	unknown

 insert into t1 values('a');

 insert into t1 select * from t2;

 show engine aria logs;

 Type	Name	Status

-Aria	Size        24576 aria_log.00000001	unknown

+Aria	Size        24576 ; ???�	unknown

 * shut down mysqld, removed logs, restarted it

 truncate table t1;

 insert into t1 select * from t2;

 show engine aria logs;

 Type	Name	Status

-Aria	Size        16384 aria_log.00000001	unknown

+Aria	Size        16384 ; W??�	unknown

 drop table t1;

 * shut down mysqld, removed logs, restarted it

 create table t1 (a varchar(100)) engine=aria transactional=1;

@@ -41,11 +41,11 @@

 Note	1050	Table 't1' already exists

 show engine aria logs;

 Type	Name	Status

-Aria	Size        16384 aria_log.00000001	unknown

+Aria	Size        16384 ; h??�	unknown

 * shut down mysqld, removed logs, restarted it

 drop table t1;

 create table t1 engine=aria transactional=1 select * from t2;

 show engine aria logs;

 Type	Name	Status

-Aria	Size        16384 aria_log.00000001	unknown

+Aria	Size        16384 ; ???�	unknown

 drop database mysqltest;

mysqltest: Result length mismatch

The problem is a in the stat structure at /usr/include/i386-linux-gnu/bits/stat.h

Depending on how you compile your program (with or without __USE_FILE_OFFSET64) the structure gets different sizes.

Here is an example:

#if defined __x86_64__ || !defined __USE_FILE_OFFSET64

    __off_t st_size;                    /* Size of file, in bytes.  */

#else

    __off64_t st_size;                  /* Size of file, in bytes.  */

#endif

The variable is either 4 or 8 bytes, depending on the value of __USE_FILE_OFFSET64,

In storage/maria/ha_maria.cc, we included files in a non standard order and struct stat got to be defined too small, which caused memory overruns.

I have now fixed so that we always include <my_global.h> first, which fixes this issue. I will push this into 10.0 tree shortly

However someone should fix so that 'struct stat' has always the same size, independent of how you compile it on x86.
On 64 bits it's always the same size.

A full fix of this is now pushed to 10.0 tree, revision 4422
Sergei will push a small patch to 5.5 to fix this issue in 5.5

I backported from commit https://bazaar.launchpad.net/~maria-captains/maria/10.0/revision/4422 the patch http://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/tree/debian/patches/fix-maria-no-logging.patch and the test passes now. Thanks!

Not sure this is the right place to report this, but installing third party libraries like mysql-python now fail with:

/usr/include/mysql/my_config.h:654:2: error: #error <my_config.h> MUST be included first!

Reporting it here, since it seems related to this issue. Please advise.

Yes, related.

But as it's a different issue I've reported it separately. MDEV-6862.

I cannot think of a simple workaround, besides removing this #error line from my_config.h