MariaDB is in Gentoo, so the steps to build it are:

1. Synchronize your tree with\

   Copy

   emerge --sync

2. Build MariaDB using\

   Copy

   emerge mariadb

_{This page is licensed: CC BY-SA / Gnu FDL}

Prelude

Building MariaDB on macOS relies on the Apple-provided toolchain and Homebrew for dependencies.

You can install the toolchain without XCode (suggested, unless you have XCode installed already) with:

Homebrew is a package manager for macOS which you can install from https://brew.sh

Install Dependencies

First, install the upstream dependencies, then clone MariaDB.

Second, clone MariaDB from the GitHub repository: see the page for options.

Setup the Environment

CMake should find the dependencies automatically, but we may need to set several environment variables to explicitly point at locations of dependencies installed by Homebrew to avoid conflicts with system-native versions that aren't suitable for building MariaDB. In the worst case scenario, use the following (but you can try building MariaDB first by skipping to the "Run CMake" section below to see if these are necessary in your setup):

The installation location of Homebrew depends on the processor type. Apple Silicon macs will have Homebrew in /opt/homebrew while Intel macs will have Homebrew in /usr/local.

Run CMake

By default, macOS uses a case-insensitive filesystem. When building, we can't create a build subdirectory because BUILD already exists, and all the CMake output will end up mixed in with BUILD. Instead, create a mariadb-build directory as that is unique. cd into mariadb-build and, from there, run CMake with the following flags:

(You can vary the values of these flags depending on what you need to do.)

If CMake runs succesfully, you can then run the build itself:

This produces a mariadbd binary at mariadb-build/sql.

_{This page is licensed: CC BY-SA / Gnu FDL}

All CMake configuration options for MariaDB can be displayed with:

cmake . -LH

See Also

• Get the Code, Build it, Test it (mariadb.org)

_{This page is licensed: CC BY-SA / Gnu FDL}

Instructions on compiling MariaDB on musl-based operating systems (Alpine)

The instructions on this page will help you compile from source. Links to more complete instructions for specific platforms can be found on the page.

• First, .

To generate RPM packages from the build, supply the -DRPM=xxx flag to CMake, where the value xxx is the name of the distribution you're building for. For example, centos7 or rocky8 or fedora39 or sles15.

What these do are controlled in the following CMake files:

• cmake/cpack_rpm.cmake

In the event that you are using the Linux-based operating system Ubuntu or any of its derivatives and would like to compile MariaDB from source code, you can do so using the MariaDB source repository for the release that interests you.

Before you begin, install the software-properties-common, devscripts and equivs packages.

Installing Build Dependencies

How to create a source tar.gz file.

First .

Then use automake/configure/make to generate the tar file:

This creates a source file with a name like mysql-5.3.2-MariaDB-beta.tar.gz

See also .

_{This page is licensed: CC BY-SA / Gnu FDL}

It is relatively straightforward to build MariaDB from source on FreeBSD. When working with an individual host, you can use Ports to compile particular or multiple versions of MariaDB. When working with multiple hosts, you can use Poudriere to build MariaDB once, then serve it as a package to multiple FreeBSD hosts.

Using Ports

The FreeBSD Ports Collection provides a series of Makefiles that you can use to retrieve source code, configure builds, install dependencies and compile software. This allows you to use more advanced releases than what is normally available through the package managers as well as enable any additional features that interest you.

In the event that you have not used Ports before on your system, you need to first fetch and extract the Ports tree. This downloads the Ports tree from FreeBSD and extracts it onto your system, placing the various Makefiles, patches and so on in the /usr/ports/ directory.

In the event that you have used Ports before on this system, run Portsnap again to download and install any updates to the Ports tree.

This ensures that you are using the most up to date release of the Ports tree that is available on your system.

Building MariaDB from Ports

Once Portsnap has installed or updated your Ports tree, you can change into the relevant directory and install MariaDB. Ports for MariaDB are located in the /usr/ports/databases/ directory.

Note that FreeBSD treats the Server and Client as separate packages. The Client is a dependency of the Server, so you only need to build the Server to get both. It also provides a number of different versions. You can search the available ports from . Decide what version of MariaDB you want to install, the change into the relevant directory. Once in the directory, run Make to build MariaDB.

In addition to downloading and building MariaDB, Ports also downloads and build any libraries on which MariaDB depends. Each port it builds will take you to a GUI window where you can select various build options. In the case of MariaDB, this includes various storage engines and specific features you need in your build.

Once you finish building the ports, install MariaDB on your system and clean the directory to free up disk space.

This installs FreeBSD on your server. You can now enable, configure and start the service as you normally would after installing MariaDB from a package.

Using Poudriere

Poudriere is a utility for building FreeBSD packages. It allows you to build MariaDB from a FreeBSD Jail, then serve it as a binary package to other FreeBSD hosts. You may find this is particularly useful when building to deploy multiple MariaDB servers on FreeBSD, such as with Galera Cluster or similar deployments.

Building MariaDB

Once you've configured your host to use Jails and Poudriere, initialize a jail to use in building packages and a jail for managing ports.

This creates two jails, package-builder and local-ports, which you can then use to build MariaDB. Create a text file to define the packages you want to build. Poudriere will build these packages as well as their dependencies. MariaDB is located at databases/mariadb103-server. Adjust the path to match the version you want to install.

Use the options command to initialize the build options for the packages you want Poudriere to compile.

Lastly, use the bulk command to compile the packages.

Using Poudriere Repositories

In order to use Poudriere, you need to set up and configure a web server, such as Nginx or Apache to serve the directory that Poudriere built. For instance, in the case of the above example, you would map to the package-builder jail: /usr/local/poudriere/data/packages/package-builder/.

You may find it useful to map this directory to a sub-domain, for instance httpspkg.example.com or something similar.

Lastly, you need to configure the FreeBSD hosts to use the Poudriere repository you just created. On each host, disable the FreeBSD official repositories and enable your Poudriere repository as an alternative.

Then add the URL for your Poudriere repository to configuration file:

You can then install MariaDB from Poudriere using the package manager.

_{This page is licensed: CC BY-SA / Gnu FDL}

In the event that you are using the Linux-based operating system Debian or any of its direct derivatives and would like to compile MariaDB from source code, you can do so using the MariaDB source repository for the release that interests you. For Ubuntu and its derivatives, see Building on Ubuntu.

Before you begin, install the software-properties-common and devscripts packages:

$ sudo apt-get install -y software-properties-common \
      devscripts

Installing Build Dependencies

MariaDB requires a number of packages to compile from source. Fortunately, you can use the MariaDB repositories to retrieve the necessary code for the version you want. Use the tool to determine how to set up the MariaDB repository for your release of Debian, the version of MariaDB that you want to install, and the mirror that you want to use.

First add the authentication key for the repository, then add the repository.

The second command added text to the /etc/apt/sources.list file. One of these lines is the repository containing binary packages for MariaDB, the other contains the source packages. The line for the source packages is commented out by default. This can be scripted:

Alternately, open the file using your preferred text editor and uncomment the source repository.

Once the repository is set up, you can use apt-get to retrieve the build dependencies. MariaDB packages supplied by Ubuntu and packages supplied by the MariaDB repository have the same base name of mariadb-server. You need to specify the specific version you want to retrieve.

Building MariaDB

Once you have the base dependencies installed, you can retrieve the source code and start building MariaDB. The source code is available on GitHub. Use the --branch option to specify the particular version of MariaDB you want to build.

The source code includes scripts to install the remaining build dependencies. For Ubuntu, they're located in the debian/ directory. Navigate into the repository and run the autobake-deb.sh script. Then use

After Building

After building the packages, it is a good idea to put them in a repository. See the page for instructions.

_{This page is licensed: CC BY-SA / Gnu FDL}

By default all plugins are enabled and built as dynamic .so (or .dll) modules. If a plugin does not support dynamic builds, it is not built at all.

Use PLUGIN_xxx cmake variables. They can be set on the command line with -DPLUGIN_xxx=value or in the cmake gui. Supported values are

Note that unlike autotools, cmake tries to configure and build incrementally. You can modify one configuration option and cmake will only rebuild the part of the tree affected by it. For example, when you do cmake -DWITH_EMBEDDED_SERVER=1 in the already-built tree, it will make libmysqld to be built, but no other configuration options will be changed or reset to their default values.

In particular this means that if you have run, for examplecmake -DPLUGIN_OQGRAPH=NO and later you want to restore the default behavior (with OQGraph being built) in the same build tree, you would need to runcmake -DPLUGIN_OQGRAPH=DYNAMIC

Alternatively, you might simply delete the CMakeCache.txt file — this is the file where cmake stores current build configuration — and rebuild everything from scratch.

_{This page is licensed: CC BY-SA / Gnu FDL}

Buildroot

Buildroot is a way to cross compile MariaDB and other packages into a root filesystem. In the menuconfig you need to enable "Enable C++ Support" first under "Toolchain". After C++ is enabled MariaDB is an option under "Target Packages" ->"Libraries" -> "Databases" -> "mysql support" -> "mysql variant" -> "mariadb". Also enable the "mariadb server" below the "mysql support" option.

Details

To cross-compile with cmake you will need a toolchain file. See, for example, . Besides cmake specific variables it should have, at least

with appropriate values for your target architecture. Normally these MariaDB configuration settings are detected by running a small test program, and it cannot be done when cross-compiling.

Note that during the build few helper tools are compiled and then immediately used to generate more source files for this very build. When cross-compiling these tools naturally should be built for the host architecture, not for the target architecture. Do it like this (assuming you're in the mariadb source tree):

Now the helpers are built and you can cross-compile:

Here you invoke cmake, specifying the path to your toolchain file and the path to the import_executables.cmake that you have just built on the previous step. Of course, you can also specify any other cmake parameters that could be necessary for this build, for example, enable or disable specific storage engines.

See also

_{This page is licensed: CC BY-SA / Gnu FDL}

The following two articles should help you get your Solaris machine prepared to build MariaDB (just ignore the parts about installing buildbot):

Notes

• The BUILD dir contains various scripts for compiling MariaDB on Solaris. The BUILD/compile-solaris-amd64 and BUILD/compile-solaris-amd64-debug are probably the most useful.

• The scripts do not play nice with non-bash shells such as the Korn Shell (ksh). So if your /bin/sh is pointing at ksh or ksh93, you'll want to change it so that it points at bash.

_{This page is licensed: CC BY-SA / Gnu FDL}

Below are instructions for creating your own Debian repository. The instructions are based on repository-howto.en.html

REPO_DIR={pick some location}
mkdir $REPO_DIR
mkdir $REPO_DIR/binary
mkdir $REPO_DIR/source
cp *.deb *.ddeb $REPO_DIR/binary
cd $REPO_DIR
dpkg-scanpackages binary  /dev/null | gzip -9c > binary/Packages.gz
dpkg-scansources  source  /dev/null | gzip -9c > source/Sources.gz

Using the Debian repository you just created

One needs to add a new file to the /etc/apt/sources.list.d/ directory. For instance a new file called mariadb.list

after which one can run

and collect bugs :-).

apt-get install will spray output of scripts and servers all over /var/log. It is also possible to set DEBIAN_SCRIPT_DEBUG=1 to get some (not all) of it to stdout.

Cleaning up after failed installation

Run

to see what is installed, and then

until the former produces empty output. Note: after some failures, /etc/mysql and /var/lib/mysql are not cleaned and still need to be removed manually.

_{This page is licensed: CC BY-SA / Gnu FDL}

How to generate binary tar.gz files.

• Setup your build environment.

• Build binaries with your preferred options/plugins.

If the binaries are already built, you can generate a binary tarball with

make package

Prior to , the following steps were required:

• Use make_binary_distribution to generate a binary tar file:

This creates a source file with a name like mariadb-5.3.2-MariaDB-beta-linux-x86_64.tar.gz in your current directory.

The other option is to use the bakery scripts. In this case you don't have to compile MariaDB source first.

_{This page is licensed: CC BY-SA / Gnu FDL}

For some distributions you can build MariaDB from a source RPM. (See also Why Source RPMs (SRPMs) Aren't Packaged For Some Platforms).

You can build it as follows:

using dnf

On RHEL8 you might need to start with:

sudo dnf config-manager --set-enabled codeready-builder-beta-for-rhel-8-x86_64-rpms

Then, on all dnf distributions:

sudo dnf install rpm-build perl-generators
    dnf download --source MariaDB
    sudo dnf builddep MariaDB-*.src.rpm
    rpmbuild --rebuild MariaDB-*.src.rpm

using yum

using zypper

Or (to avoid building as root):

_{This page is licensed: CC BY-SA / Gnu FDL}

Sometimes, one needs to have MariaDB compiled with Vanilla XtraDB. This page describes the process to do this. The process is rather crude, as my goal was just a once-off compile for testing (that is, not packaging or shipping) purposes.

The process is applicable to and XtraDB from Percona Server 5.1.61.

wget http://s.petrunia.net/scratch/make-vanilla-xtradb-work-with-mariadb.diff

bzr branch /path/to/mariadb-5.3 5.3-vanilla-xtradb-r3

cd 5.3-vanilla-xtradb-r3/storage/
tar czf innodb_plugin.tgz innodb_plugin/
rm -rf innodb_plugin
tar czf xtradb.tgz xtradb/
rm -rf xtradb
cd ../../

tar zxvf ~/Percona-Server-5.1.61.tar.gz
cp -r Percona-Server-5.1.61/storage/innodb_plugin 5.3-vanilla-xtradb-r3/storage/
patch -p1 -d 5.3-vanilla-xtradb-r3/storage/innodb_plugin/ < make-vanilla-xtradb-work-with-mariadb.diff

cd 5.3-vanilla-xtradb-r3/

BUILD/autorun.sh
./configure --with-plugin-innodb_plugin
make

_{This page is licensed: CC BY-SA / Gnu FDL}

MariaDB uses InnoDB as the default storage engine.

If you want to use Oracle's InnoDB plugin, then you need to compile MariaDB andnot specify --without-plugin-innodb_plugin when configuring. For example, a simple ./configure without any options will do.

When the InnoDB plugin is compiled, the innodb_plugin test suite will test the InnoDB plugin in addition to xtradb:

./mysql-test-run --suite=innodb_plugin

To use the innodb_plugin instead of xtradb you can do (for ):

mysqld --ignore-builtin-innodb --plugin-load=innodb=ha_innodb.so \
--plugin_dir=/usr/local/mysql/lib/mysql/plugin

See Also

_{This page is licensed: CC BY-SA / Gnu FDL}

In the event that you are using the Linux-based operating system Fedora or any of its derivatives and would like to compile MariaDB from source code, you can do so using the MariaDB build in the official repositories.

Installing Build Dependencies

MariaDB requires a number of packages to compile from source. Fortunately, you can use the package in the Fedora repository to retrieve most of the relevant build dependencies through DNF.

Running DNF in this way pulls the build dependencies for the release of MariaDB compiled by your version of Fedora. These may not be all the dependencies you need to build the particular version of MariaDB you want to use, but it will retrieve most of them.

You'll also need to install Git to retrieve the source repository:

The intention of this documentation is show all the steps of getting, building and testing the latest MariaDB server (10.5 at time of writing) from GitHub. Each stage links to the full documentation for that step if you need to find out more.

Required Tools

The following is a list of tools that are required for building MariaDB on Linux and Mac OS X. Most, if not all, of these will exist as packages in your distribution's package repositories, so check there first. See , , and pages for specific requirements for those platforms.

Read the page for more information on how to debug high memory consumption.

Using tcmalloc or jemalloc

is a malloc replacement library optimized for multi-threaded usage. It also features a built-in heap debugger and profiler.

Another malloc replacement that may speed up MariaDB is .

The procedures to use one of these libraries with MariaDB are the same. Many other malloc replacement libraries (as well as heap debuggers and profilers) can be used with MariaDB in a similar fashion.

In the event that you are using the Linux-based operating system CentOS or any of its derivatives, you can optionally compile MariaDB from source code. This is useful in cases where you want use a more advanced release than the one that's available in the official repositories, or when you want to enable certain feature that are not otherwise accessible.

Installing Build Dependencies for

Before you start building MariaDB, you first need to install the build dependencies required to run the compile. CentOS provides a tool for installing build dependencies. The yum-builddep utility reads a package and generates a list of the packages required to build from source, then calls YUM to install them for you. In the event that this utility is not available on your system, you can install it through the yum-utils package. Once you have it, install the MariaDB build dependencies.

Running the above command installs many of the build dependencies, but it doesn't install all of them. It will only install dependencies for , which is not enough if you want to compile a newer MariaDB version!

Installing Build Dependencies for newer MariaDB versions

The following commands installs all packages needed to get and compile :

You can replace openssl with gnutls above, depending on the TLS implementation you want to use.

If you plan to use the BUILD scripts to make it easier to build different configurations of MariaDB, then you should also install ccache to speed up your compilations:

If you want to test the MariaDB installation, with the include mysql-test-run (mtr) system, you also need to install and configure cpan:

For more information on dependencies, see .

Building MariaDB

Once you have the base dependencies installed, you can retrieve the source code and start building MariaDB. The source code is available on GitHub. Use the --branch option to specify the particular version of MariaDB you want to build.

With the source repository cloned onto your system, you can start building MariaDB. Run CMake to ready MariaDB for the build,

Once CMake readies the relevant Makefile for your system, use Make to build MariaDB.

This generates an RPM file, which you can then install on your system or copy over to install on other CentOS hosts. The umask is needed because of a bug in cmake / cmake scripts.

Alternative, use one of the build scripts in the BUILD directory that allows you to compile different versions of MariaDB (debug, optimized, profiling etc).

A good option for developers is:

Creating MariaDB-compat package

MariaDB-compat package contains libraries from older MariaDB releases. They cannot be built from the current source tree, so cpack creates them by repackaging old MariaDB-shared packages. If you want to have -compat package created, you need to download MariaDB-shared-5.3 and MariaDB-shared-10.1 rpm packages for your architecture (any minor version will do) and put them one level above the source tree you're building. CMake will pick them up and create a MariaDB-compat package. CMake reports it as

Additional Dependencies

In the event that you miss a package while installing build dependencies, CMake may continue to fail after you install the necessary packages. If this happens to you, delete the CMake cache then run the above the command again:

When CMake runs through the tests again, it should now find the packages it needs, instead of the cache telling it they're unavailable.

More about CMake and CPackRPM

See also

_{This page is licensed: CC BY-SA / Gnu FDL}

Build Requirements

To build MariaDB you need the following:

• Visual C++: We currently support Visual Studio 2019 and 2022. Generally we try to support the two most recent VS versions, but build ourselves using the last one. Community editions will work fine; we only use them in our builds. While installing Visual Studio, make sure to add "Desktop Development with C++". Also, make sure to use recent enough Windows SDK - latest Windows 11 SDK is recommended.

• : We recommend the latest release. Older releases might not support your version of Visual Studio. Visual Studio 2019 requires cmake 3.14 at least.

• : Required to build newer versions from the source tree.

  • NOTE: run

after the installation, otherwise some mtr tests will fail

In the "Adjusting your PATH" dialog, choose "Use Git from Windows command prompt", otherwise wrong (mingw64) git and perl will be in your PATH

• : Bison creates parts of the SQL parser. Choose "Complete package except sources" when downloading.

  • NOTE: Do not install this into your default path with spaces (e.g. under C:\Program Files\GnuWin32); the build will break due to . Instead, install into C:\GnuWin32.

  • Add C:\GnuWin32\bin to your system PATH

Verify that bison.exe, or git.exe, cmake.exe and perl.exe can be found in the PATH environment variable with "where bison", "where git", "where perl" etc. from the command line prompt.

Building Windows Binaries

The above instructions assume or higher.

Branch the MariaDB repository, or unpack the source archive. On the command prompt, switch to your source directory, then execute:

The above example builds a release configured for 64 bit systems in a subdirectory named bld. "cmake ..." is the configuration step, "cmake --build . --config Relwithdebinfo" is the build step.

Build Variations

Debug Builds

Building Debug version is done with:

32bit and 64 bit Builds

Build 64 bit binary

Visual Studio 2019-2022 cmake generator will use host architecture by default, that is, with the steps above, cmake will build x64 binaries on x64 machine.

Build 32 bit binary

pass -A Win32 parameter for cMake, like this

Historical note: With Visual Studio 2017 and earlier, one had to pass the name of 32bit generator ,e.g cmake .. -G "Visual Studio 15 2017

For a complete list of available generators, call cmake without any parameters.

IDE Builds

Instead of calling "cmake --build" as above, open solution file MariaDB.sln (in older versions, prior to 11.0, MySQL.sln ). When Visual Studio starts, choose Build/Compile.

Building the ZIP Package

This is how it is "done by the book", standard cmake target.

MariaDB however uses non-standard target win_package for the packaging for its releases, it generates 2 ZIPs, a slim one with executables, and another one with debuginfo (.PDB files). The debuginfo is important to be able to debug released binaries, and to analyze crashes.

Building the MSI Package

Including HeidiSQL in the MSI Installer

Starting with , it is possible to build an installer which includes 3rd party products, as described in . Currently only support is implemented; it is also included in the official builds. Use the CMake parameter-DWITH_THIRD_PARTY=HeidiSQL to include it in the installer.

Code Signing

MariaDB builds optionally support authenticode code signing with an optional parameter SIGNCODE. Use cmake -DSIGNCODE=1 during the configuration step to sign the binaries in the ZIP and MSI packages.

Important: for SIGNCODE=1 to work, the user that runs the build needs to install a valid authenticode digital certificate into their certificate store, otherwise the packaging step will fail.

Building Packages for MariaDB Releases

The full script to create the release in an out-of-source build with Visual Studio with signed binaries might look like:

This command sequence will produce a ZIP package (e.g mariadb-5.2.6-win32.zip) and MSI package (e.g mariadb-5.2.6-win32.msi) in the bld directory.

Running Tests

• Important: Do not use Cygwin bash, MinGW bash, Git bash, WSL bash, or any other bash when running the test suite. You will then very likely use the wrong version of Perl too (a "Unix-flavoured" one on Windows), and spend a lot of time trying to figure out why this version of Perl does not work for the test suite. Use native perl, in cmd.exe , or powershell instead,

• Switch mysql-test subdirectory of the build directory

• Run the test suite

Running a Test Under Debugger

Assuming VS is installed on the machine

If vsjitdebugger does not start, you can edit AeDebug registry key as mentioned in

Alternatively:

(devenv.exe needs to be in PATH)

or, if you prefer WinDBG

_{This page is licensed: CC BY-SA / Gnu FDL}

The instructions on this page will help you compile from source. Links to more complete instructions for specific platforms can be found on the page.

First, .

Next, .

If you don't want to run MariaDB as yourself, then you should create a mysql user. The example below uses this user.

Using cmake

What are Sanitizers?

Sanitizers are open source runtime error detectors developed by Google that are enabled during the compile step. These sanitizers add extra code during compilation that will throw exceptions when certain errors are detected.

Sanitizers find server bugs bug instrumenting the runtime MariaDB during compile time, and performing runtime checks on the executed test. Sanitizers detect a variety of implementation defects:

The sanitizers for clang are:

How to Compile MariaDB with Sanitizers

Before using ASAN locally, please ensure that it is installed on the system:

You can use one of the two following build commands:

Additionally, UBSAN, TSAN, and MSAN can be enabled in a similar way:

UBSAN:

TSAN:

MSAN:

Important to note MSAN requires instrumented c++ and system libraries to have a functioning build per container guide below.

Buildbot's MSAN container

The time consuming aspect of building with MSAN is having . To help with this MariaDB Foundation has built the MSAN container for buildbot, but this is reusable locally.

The MariaDB Buildbot MSAN container, quay.io/mariadb-foundation/bb-worker:debian12-msan-clang-20 is a container with:

• the instrumented libraries required for MSAN

• a very modern clang version

• a stable Debian as a base image

• a compiled for debugging

The build of this container isn't hard coded to MSAN so it can be used for:

• A general Debian build container

• Using the gcc/g++ of Debian (by removing the CC and CXX environment variables

• Compiling with a latest clang

• Compiling with the ASAN/UBSAN feature available in the latest

Running the MSAN container

First, run the container where your current directory is the source directory.

For Podman:

The /build options for Docker Engine are slightly different as they default to noexec and a root ownership by default.

The purposes of these, and other options include:

Notes:

• /dev/shm is mounted no-exec so it rr recording here cannot be replayed while in that location

• optionally can make /build a filesystem mount to preserve the build.

There are environment variables that affect the cmake configure options and mtr are:

Note: Galera WSREP_PROVIDER isn't instrumented with any sanitizer

Check the latest version of these running env.

Running an MSAN Build

Once you have started the MSAN container this is how you perform a MSAN build.

The time consuming aspect of building with MSAN is having .

All the following instructions are executed within the container - there is a document in /etc/motd that contains the latest information. Start by running the configure stage of cmake:

MSAN is a clang only compile options and other compilers will not work.

Run the build stage:

As the MSAN has rpath defined in its compile option there is no need for LD_LIBRARY_PATH manipulation.

To run tests:

As newer versions occur and improvements happen these instructions may change. Look at the execution on the to see if any changes have been made.

Bug Reporting

Use the MSAN in the label when reporting bugs.

Current outstanding MSAN bugs can be found on .

Running an combined ASAN and UBSAN Build

The clang implemented instrumentation of the MemorySanitizer (MSAN) conflicts with the AddressSanitizer (ASAN) and UndefinedBehaviour (UBSAN) mechanisms, however ASAN and UBSAN can be combined into the same build.

After starting the MSAN container the following will configure a combined ASAN and UBSAN build:

Build and test run are standard.

Note: list of unfixed .

Bug Reporting

UBSAN bugs are labelled with UBSAN and also the short form of the undefined behaviour.

For example in the following output, the insufficient-object-size would be used as the additional short form of the label.

Likewise for ASAN, should use ASAN as the label with the short form of the ASAN type from the output.

Using RR

In the MSAN container, there is a build version of the latest rr at the time of the container build.

A recording of the execution can be make with the . Or alternately you can execute:

To replay a recording adjust per the test worker and instance used in the test:

Using curl in the container its possible to save up this directory for another user or developer to use with the same container. This can also be shared with our public ftp server for assistance diagnosing validating a bug report.

ASAN Options

To run mariadbd with instrumentation you have to set the ASAN_OPTIONS environment variable before starting mariadbd including starting mariadbd when running mtr.

The above command will abort any instrumented executable if any errors are found, which is good for debugging. If you set abort_on_error=0 all server errors are logged to your error log file (mysqld.err).

To catch errors for other processes than the server, you can set more options, like this:

If you are seeing an incomplete stack trace for a memory allocation, you may rerun the failing test with

To get core dumps of failures:

To see all the options (or to check if an executable is instrumented), you may try the following:

Using Valgrind

The can use for finding memory leaks and wrong memory accesses. Valgrind is an instrumentation framework for building dynamic analysis tools. If Valgrind is installed on your system, you can simply use to run the test under Valgrind.

See Also

_{This page is licensed: CC BY-SA / Gnu FDL}