Fedora build system - Fedora 28, 29, Rawhide (developement branch)
ARMv7HL only

The just released 10.4.3 RC version is affected as well !!

Here lies the build log for examination:
https://koji.fedoraproject.org/koji/getfile?taskID=33061689&volume=DEFAULT&name=build.log

Noting that this bug is preventing 10.3.13 (and will also do so for the imminent 10.3.14) from being packaged into Fedora, so increasing priority.

mschorm
I could not reproduce this issue on arm environment. Would it possible to log in and check it directly on the armv7hl environment? or Would it possible to change the source code of Spider and test it?

I will try to get you an affected environment.
–
UPDATE 1:

• I got access to the ARMv7hl machine
• I was able to reproduce the error there, by mock rebuild of the source package used in KOJI (Fedora build system)
• Now I'm negotiating with the machine admin about the access for you

UPDATE 2:

• For the access to the machine, you will need FAS (Fedora account system) account.
  You will upload there your public ssh key, with which you will be authentized to the machine.
  After the account will be ready, I'll ask the admin to add the account to the 'upstream-test' group, which will grant you access to the machines.
  https://admin.fedoraproject.org/accounts/user/new
  .
  I suggest you make a single account for whole MariaDB upstream.

Let me know once you have it ready, or if there's any problem.
... or if you feel like this way won't work for you at all.

mschorm
I just added an account and uploaded my public ssh key. My account name is "kentoku".
Please let me know if I need to do something more.

Kentoku
Yes, there's one more thing required. The signing of the Contributor agreement.
You can find also there.

mschorm
I'm sorry. I can not imagine which kind of contribute will I do to know detail of this issue, and I think it is not required. Is there any other way without signing? Do you know what options are used for cmake or build?

mschorm
What specific device do you use?

Kentoku
I have a good news!
After discussions between the Sysadmins and Fedora legal a decisions was made you (or your case in general) doesn't need the FPCA signed for this purpose.

So you should now have granted access to the machine.
Test Machine Fedora Resources

I set it up on arm03-packager00.cloud.fedoraproject.org machine.

Steps to reproduce:

sudo su -s /usr/bin/bash mysql

cd /usr/share/mysql-test/

./mysql-test-run --do-test=spider3_fixes --big-test --mem

That will result into a message like:

mysqltest: At line 162: query 'SELECT MAX(id) FROM t1' failed: 128: Out of memory (Needed 3062130920 bytes)

mschorm
Thank you for the news!
I just tried to log into arm03-packager00.cloud.fedoraproject.org machine, but I got the following error from ssh command. Would you please check permission of my public key file?

$ ssh kentoku@arm03-packager00.cloud.fedoraproject.org

Enter passphrase for key :

Permission denied (publickey).

I contacted the admins.
An update of keys on the server was forced and your account is listed as enabled and with a public key.

In case it wouldn't work now, we can check that you use the key the server is expecting (either you or us will send it to other - question is through which channel. It is only a public key, but you may not like to paste it here).

mschorm
I could log in and reproduce the issue. Thanks.
When I tried to use gdb for debugging, it did not work with the following error. Would you please check it? In the other hand, would it possible "Debug" build?

bash-4.4$ gdb /usr/libexec/mysqld

GNU gdb (GDB) Fedora 8.2-7.fc29

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "armv7hl-redhat-linux-gnueabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from /usr/libexec/mysqld...Reading symbols from /usr/lib/debug/usr/libexec/mysqld-10.3.13-1.fc29.arm.debug...done.

done.

(gdb) run

Starting program: /usr/libexec/mysqld

warning: the debug information found in "/usr/lib/debug//lib/ld-2.28.so.debug" does not match "/lib/ld-linux-armhf.so.3" (CRC mismatch).

warning: the debug information found in "/usr/lib/debug//usr/lib/ld-2.28.so.debug" does not match "/lib/ld-linux-armhf.so.3" (CRC mismatch).

Missing separate debuginfos, use: dnf debuginfo-install glibc-2.28-30.fc29.armv7hl

[3]+  Stopped                 gdb /usr/libexec/mysqld

bash-4.4$

I created a debug build of 3.0.15 and installed it there. (there was 3.0.13 previously).
It took longer than expected, due to MDEV-19740 I hit.
I updated the glibc debuginfo, so you can run the mysqld in gdb.
I verified the test still fails.
It doesn't say "Out of memory" anymore, but rather "2013: Lost connection to MySQL server during query", which sound's a bit more debug friendly.

You - same as me - should be able to use "sudo" on your account, so you can install / upgrade / downgrade any tool or package you may need.

mschorm
I finally fixed and pushed it. Would you please try to use the following branch?
bb-10.4-MDEV-18737

This issue looks memory alignment issue of variable argument when calling my_multi_malloc(). This method assume variable argument as a pair of pointer and uint, but caller put it as a pair of pointer and some integer. On armv7hl, this causes an issue. For fixed this, I added a cast to uint for every length values. Thank you for your cooperation.

The very first test looks promising.

So far, I did one run of released 10.3.15 tarball patched with the commit you made.

In the following days, I aim to prepare updates in Fedora to 10.3.15 and 10.4.5.
Respectively 10.3.16 which just came out and 10.4.6 which should soon follow.

Even though, I'd think it would be nice to have it fixed in the first 10.4 GA release, with this patch in hand, I don't really rush to have it there.

I'll post an update here, once I'll successfully create those updates and verify the issue is no more.

.

Thanks a lot.

The 10.3.16 and 10.4.6 looks fine with the patch.

The ticket may be closed.

Merged into 10.4 tree. Thanks.