If mysqld is crashing, creating a trace file is a good way to find the issue.

A mysqld binary that has been compiled with debugging support can create trace files using the DBUG package created by Fred Fish. To find out if your mysqld binary has debugging support, run mysqld -V on the command line. If the version number ends in -debug then your mysqld binary was compiled with debugging support.

See Compiling MariaDB for debugging for instructions on how to create your own mysqld binary with debugging enabled.

To create the trace log, start mysqld like so:

Without options for --debug, the trace file will be named /tmp/mysqld.trace in MySQL and older versions of MariaDB before 10.5 and /tmp/mariadbd.trace starting from .

On Windows, the debug mysqld is called mysqld-debug and you should also use the --standalone option. So the command on Windows will look like:

Once the server is started, use the regular mysql command-line client (or another client) to connect and work with the server.

After you are finished debugging, stop the server with:

DBUG Options

Trace files can grow to a significant size. You can reduce their size by telling the server to only log certain items.

The --debug flag can take extra options in the form of a colon (:) delimited string of options. Individual options can have comma-separated sub-options.

For example:

The 'd' option limits the output to the named DBUG_ macros. In the above example, the /tmp/mariadbd.trace tracefile will contain output from the info, error, and query DBUG macros. A 'd' by itself (with no sub-options) will select all DBUG_ macros.

The 'o' option redirects the output to a file (/tmp/mariadbd.trace in the example above) and overwrites the file if it exists.

See Also

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

Even if you don't have a server that is , there are still ways to get more information out from it if things go wrong.

When things go wrong, it's always better to have a version of mysqld daemon that is not stripped.

If this doesn't say 'stripped' then you are fine. If not, you should either or .

Debugging Memory Consumption With tcmalloc

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

If you have a problem with a mysqld process that keeps on growing, you can use tcmalloc to find out what is allocating memory:

Compiling MariaDB for Debugging Using the CMAKE_BUILD_TYPE Option

This option enables multiple debug instrumentation aspects within the MariaDB server that provided more detailed information around complex parts of the server and can be used to implement and run tests where the concurrent execution of multiple threads must be controlled to achieve a specific state. If you are not doing this, the following option is sufficient.

Compiling MariaDB with full debug information includes all code symbols and also new code to do internal testing of structures and allow one to trace MariaDB execution. A full debug binary will be notably slower than a normal binary (30%). Most of this overhead can be removed by disabling -DWITH_DBUG_TRACE=OFF

You can configure build a debug build by executing cmake and by setting the CMAKE_BUILD_TYPE option to Debug. For example:

To compile:

You can find a list of the needed packages/libraries for building on Linux .

Building Optimized Build With Debug Symbols

To build MariaDB with debug symbols, to get better stack traces and to be able to debug the binary with gdb, you need to supply the and options to the gcc compiler for an debuggable, with limited optimization tradeoffs..

Pass these are options to cmake like:

To compile:

Doing a Debug Build on Debian/Ubuntu

To build a "mariadbd" binary with debugging enabled that uses the same parameters as the ones used in Debian/Ubuntu binary packages, you must do as follows (you must have a deb-src line of one of the MariaDB repositories on your /etc/apt/sources.list in order to do that):

The packages created will have these flags set.

Temporarily Installing your Debug Build

The commands shown below replace the release mariadbd binary with the debug mariadbd binary that you compiled. Most importantly, they replace the binary in a way which makes it trivial to revert back to the original release mariadbd binary.

First, .

Then, use the mv utility to rename the release mariadbd binary:

Note: Do not use the cp utility because that will change the file modification timestamp.

Then, install the debug mariadbd binary from your source tree:

Then, .

Be sure to replace /usr/sbin/mariadbd with the path to your mariadbdd binary and to also replace ~/mariadb-*/sql/mariadbd with the path to your debug #mariadbdbinary.

Reinstalling your Release Build

If you want to restore your original mariadbd binary, you can do it with the following process::

First, .

Then, execute the following command to delete the symbolic link:

Then, execute the following command to move the original mariadbd release binary back into place:

Then, .

Be sure to replace /usr/sbin/mariadbd with the path to your mariadbd binary

The debug mariadb-debug binary is still present if it is needed again in the future.

Different Compilation Options

Changing DBUG_ASSERT to Print to Error Log

A debug binary has lots of code checks and asserts, that are not checked in production. This is done to get more performance when running in production. In some cases, when one is trying to find a hard-to-repeat bug, it could be beneficial to have these checks in production builds too.

Compiling with -DDBUG_ASSERT_AS_PRINTF will change DBUG_ASSERT() to print any failed check to the .

Enabling the above option should not have any notable impact on performance (probably < 1% slowdown). This is achieved by grouping asserts in MariaDB server code into two groups:

• Fast checks, using DBUG_ASSERT(): These are converted to printing to error log.

• Slow checks, using DBUG_SLOW_ASSERT(). These will always be removed in production builds.

See Also

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

Debugging memory usage on CentOS 7.

This page describes how to debug MariaDB's memory usage. It uses CentOS 7 but can be applied to other systems as well.

The idea is to employ Google PerfTools:

On CentOS :

This will open an editor.

Add this content and close the file:

Then run

Then, run the workload. When memory consumption becomes large enough, ruh

This should show several files.

Copy away the last one of them:

Then, run

(Note: this produces a lot of statements like /bin/addr2line: Dwarf Error: ...

This article provides a walkthrough on using the Process Monitor on Windows, tracing file system access by mysqld.exe during the "install plugin" call.

Download

Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, registry and process/thread activity. It is a part of sysinternals suite developed by Mark Russinovich and Bryce Cogswell. Process Monitor can be directly downloaded from ProcessMonitor.zip . More description can be found at https://learn.microsoft.com/en-us/sysinternals/downloads/procmon

Installation

There is no installation necessary; the single executable can be used after unpacking. I suggest putting procmon into some directory in the PATH .

Example of taking a mysqld.exe trace

The purpose of the following exercise is to learn how to use procmon to trace mysqld.exe calls to the filesystem.

We assume that mysqld.exe is already started.

1. Start procmon.exe . Dialog will pop up that offers to set filter. Use this dialog to set filter to "Process name" "is" "mysqld.exe", as shown in the screenshot below.

Click on "Add" button to mysqld.exe to include it in the filter, "Apply" and "OK".

1. Capture events (Menu File=>Capture Events (Ctrl+E)

2. Start mysql command line client and connect to the server. Execute

1. Saving the trace

Back to Process Monitor Windows, you should see the filesystem events initiated by the "INSTALL PLUGIN" operation

To save it, choose File/Save.

(Advanced) Seeing stack traces corresponding to events

It is also possible to see stacktraces corresponding to the events. For this to work , symbols support needs to be configured. This needs to be only done once.

1. Install Debugging Tools for Windows (google on how to do that).

2. Switch to Process Monitor's menu Options => Configure symbols.

3. Add dbghelp.dll from your installation of Debugging Tools into "dbghelp.dll path" input field . On my system it is C:\Program Files\Debugging Tools for Windows (x64)\dbghelp.dll

4. In "symbol path" input field, add srvC:\symbols> (substitute last path element with real path to your installation)

This is how it looks on my machine:

Once symbols are configured, you'll get a stack trace corresponding to a filesystem event by simply doubleclicking on the line corresponding to the event. This is what I see after clicking on the first event of my tracing session (corresponds to opening my.ini file)

It is also possible to save the whole trace with callstacks as text (File/Save, choose XML, include callstack + resolve callstack).

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

If you have MariaDB compiled for debugging you can both use it in a debugger, like ddd or gdb, and get comprehensive trace files of the execution of MariaDB. The trace files allow you to both see the flow of the code and to see the differences in execution by comparing two trace files.

Core dumps are also much easier to investigate if they come from a debug binary.

Note that a binary compiled for debugging and tracing is about 10-20% slower than a normal binary. If you just compile a binary for debugging (option -g with gcc) the speed difference compared to a normal binary is negligible.

Checking That MariaDB is Compiled For Debugging

Execute:

If you are using MariaDB before 10.5, then you should use mysqld instead of mariadbd!

If you get an error unknown option '--debug, then MariaDB is not compiled for debugging and tracing.

Building MariaDB for Debugging Starting from 5.5

On Unix you need to pass -DCMAKE_BUILD_TYPE=Debug to cmake to compile with debug information.

Building and Older

Here is how you compile with debug on older versions:

Use the scripts in the BUILD directory that will compile MariaDB with most common debug options and plugins, for example:

For the most common configurations there exists a fine-tuned script in the BUILD directory.

If you want to use , a very good memory instrumentation tool and memory overrun checker, you should use

Some recommended debugging scripts for Intel/AMD are:

This is an example of how to compile MariaDB for debugging in your home directory with as an example:

The last command will produce a debug version of sql/mysqld.

Debugging MariaDB From the Source Directory

Creating the MariaDB Database Directory

The following example creates the MariaDB databases in /data.

Running MariaDB in a Debugger

The following example is using ddd, an excellent graphical debugger in Linux. If you don't have ddd installed, you can use gdb instead.

In ddd or gdb

You can so as not to have to repeat them on the run line.

If you run mysqld with --debug, you will get a in /tmp/mysqld.trace that shows what is happening.

Note that you can have different options in the configuration file for each MariaDB version (like having a specific language directory).

Debugging MariaDB Server with mariadb-test-run

If you get a crash while running mariadb-test-run you can debug this in a debugger by using one of the following options:

or if you prefer the ddd debugger:

Sample .my.cnf file to Make Debugging Easier

The above .my.cnf file:

• Uses an explicit socket for both client and server.

• Assumes the server source is in /my/maria-xxx. You should change this to point to where your sources are located.

• Has a unique patch for each MariaDB version so that one doesn't have to specify or even if one switches between debugging different MariaDB versions.

See Also

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

A MariaDB server configured with --with-debug=full has the following differences from a normal MariaDB server:

• You can have maximum of 1000 tables locked at the same time in one statement. (Define MAX_LOCKS in mysys/thrlock.c). This is to detect loops in the used lists.

• You can have maximum of 1000 threads locking the same table. (Define MAX_THREADS in mysys/thrlock.c). This is to detect loops in the used lists.

• Deadlock detection of mutex will be done at runtime. If wrong mutex handling is found an error will be printed to the error log. (Define SAFE_MUTEX)

• Memory overrun/underrun and not freed memory will be reported to the error log (Define SAFEMALLOC)

• You can get a trace of what mysqld (and most other binaries) is doing by starting it with the --debug option. The trace is usually put in /tmp or C:\

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

Enabling in an Option File

Core dumps are enabled by default on Windows, so this step can be skipped on Windows in those versions. See MDEV-18439 for more information.

In order to enable core dumps, you need to set the system variable either on the command-line or in a relevant server in an . For example:

You can check your current value by executing:

is a system variable. Its value can be checked at runtime by executing the following:

Core Files on Linux

There are some additional details related to using core files on Linux.

Disabling Core File Size Restrictions on Linux

On some systems there is a limit on the sizes of core files that can be dumped. You can check the system's current system-wide limit by executing the following:

You can check the current limit of the mariadbd process specifically by executing the following:

If you need to change the core size limit, the method you use depends on how you start mariadbd. See the sections below for more details.

The resource limits for the mariadbd process are printed to the when the mariadbd process crashes. That way, users can confirm whether the process may have been allowed to dump a core file. See for more information.

Running mariadbd Using mysqld_safe

If you are starting MariaDB by running , then configuring the following in the [mysqld_safe] option group in an option file should allow for unlimited sized core files:

You can check your current values by executing:

See for more details.

Note: If you are using and running mariadbd as the root user, then no core file is created on some systems. The solution is to run mariadbd as another user.

Running mariadbd Manually

If you are starting mariadbd manually or in a custom script, then you can allow for unlimited sized core files by executing the following in the same shell or script in which mariadbd is executed:

Running mariadbd Using systemd

If you are starting mariadbd using , then you may need to customize the MariaDB service to allow for unlimited size core files. For example, you could execute the following:

Using sudo systemctl edit mariadb.service add the contents:

See for more details.

Running MariaDB Containers

To get a core dump in a mariadb container requires to not include a sysctl kernel.core_pattern beginning with a pipe to an executable that doesn't exist in the container. Setting to a straight core is recommended.

Also see .

Changing the System-Wide Limit

If you want to change the system-wide limit to allow for unlimited size core files for the mysql user account, then you can do so by adding the following lines to a file in . For example:

The system would have to be restarted for this change to take effect.

See for more details.

Setting the Path on Linux

If you are using Linux, then it can be helpful to change a few settings to alter where the core files is written and what file name is used. This is done by setting the kernel.core_pattern and kernel.core_uses_pid attributes. You can check the current values by executing the following:

If you are using mysql-test-run and want to have the core as part of the test result, the optimal setting is probably the following (store cores in the current directory as core.number-of-process-id):

If you are using a production system, you probably want to have the core files in a specific directory, not in the data directory. They place to store cores can be temporarily altered using the utility, but it is often more common to alter them via the file system. See the following example:

The above commands will tell the system to put core files in /tmp/corefiles, and it also tells the system to put the process ID in the file name.

If you want to make these changes permanent, then you can add the following to a file in . For example:

Note: if you are using containers, the pid is always going to be 1, so this may not be a useful setting. Appending an identifier like %t to the will generate more unique files.

The value of kernel.core_pattern is printed to the when the mariadbd process crashes. That way, users can determine where the process may have dumped a core file. See for more information.

Note: Ensure that you have enough free disk space in the path pointed to by kernel.core_pattern.

Extracting Linux core dumps with systemd-coredump

Core dump management can be automated using , which then centrally manages all core dump files and provides information about detected core dumps and access to collected core files using the utility.

This is enabled per default on Red Hat Enterprise Linux 8 and CentOS 8, and maybe other contemporary Linux distribution releases by now, too. It can be easily checked for by looking at the kernel.core_pattern setting. If it looks like this systemd-coredump is enabled:

On other distributions like Ubuntu (at least up to 21.10) it is not enabled by default, but can be set up manually.

To see all recent core dumps on the system you can then simply run

Or you can check for MariaDB Server core dumps specifically with:

If an actual core file got stored you'll see present in the COREFILE column of the output, you can then extract the core file with:

using the process id number from the PID column, or when you just want to retrieve the latest MariaDB Server related entry:

Starting with systemd 248 it is also possible to invoke the gdb debugger directly using the new --debugger-arguments=... option, e.g. making the extraction of all thread backtraces from the most recent MariaDB server crash a one liner without even having to extract the core dump file first (requires gdb to be installed):

So far none of the long term support Linux distribution releases have a new enough systemd version for this, the (as of this writing) still upcoming Ubuntu 22.04 "Jammy Jellyfish" will probably the first to support this.

Core Dumps and setuid on Linux

Since mariadbd executes , you may have to set fs.suid_dumpable=2 to allow core dumps on Linux. You can check the current fs.suid_dumpable value by using the utility. For example:

You can temporarily set it to 2 by using the utility. For example:

Or you can temporarily set it to 2 by writing to the file system. For example:

If you want to permanently set it to 2 then you can add the following to a file in :

Note: If you don't want to change fs.suid_dumpable, then another solution is to start mariadbd directly as the mysql user, so that the call is not needed.

Forcing a Core File on Linux

You can get a core dump from a running server with:

This will store a core dump in filename.pid where pid is the process ID of mariadbd.mariadbd will continue to be running and will not be affected by gcore.

Another method is to force a core file for mariadbd by sending the process the sigabrt signal, which has the signal code 6. This is very useful to get the state of the unresponsive mariadbd process. However, this will cause mariadbd to crash, and crash recovery will be run on restart.

You can send the signal with the command. For example:

As an alternative to $(pidof mariadbd), you can find the process ID either by using the utility or by checking the file defined by the system variable.

Core Files on Windows

Core dumps are enabled by default on Windows. See for more information.

There are some additional details related to using core files on Windows.

Minidump Files on Windows

On Windows, the core file is created as a .

For details on how to configure and read the , see .

Core Files on Kubernetes

See the IBM project.

Core Files and Address Sanitizer (ASAN)

If your mariadbd binary is built with then it will not be able to generate a core file.

What's Included in Core Files

Core files usually contain a dump of all memory in the process's full address space. This means that if a server has some large buffers configured (such as a large ), then the server's core files can get very large.

Some large buffers have been excluded from core files on some systems as a way to reduce the size.

The following buffers are excluded:

• InnoDB Redo log buffer (fixed 2M)

The buffers are only excluded on Linux when using kernel version 3.4 and above and when using a non-debug build of mariadbd. Some Linux kernel versions have a which would cause the following warning to be printed to the log:

In those cases, the core dump may exclude some additional data. If that is not a concern, then the warning can be ignored. The problem can be fixed by upgrading to a Linux kernel version in which the bug is fixed.

See Also

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

Partial Stack Traces in the Error Log

When mariadbd crashes, it will write a stack trace in the by default. This is because the option defaults to ON. With a normal release build, this stack trace in the may look something like this:

If you plan to report a bug about the problem, then this information can be very useful for MariaDB's developers to track down the root cause. However, notice that some of the function names in the call stack are missing. In some cases, this partial stack trace may not be enough to find out exactly where the problem is.

A full stack trace can only be produced if you have debugging symbols for your mariadbd binary.

Obtaining Debugging Symbols for Your mariadbd executable

Debug information is used by debugging tools to produce a meaningful stack trace. Importantly these packages do not replace any executables or any existing production executables or in any way interfere with the way the production server ran before these packages where installed.

If you are obtaining a backtrace for a coredump, you can move the core dump to a difference server that has the identical mariadb-server and debug info packages, and perform the backtrace there with no loss of information.

Installing Debug Info Packages on Linux

On some Linux distributions, you may be able to install debuginfo packages that contain debugging symbols.

Currently, debuginfo packages may not allow the server to print a nice stack trace in the error log. They also allow users to extract full stack traces from core dumps. See for more information.

Installing Debug Info Packages with yum/dnf

The MariaDB yum repository contains packages.

On RHEL, CentOS, Fedora, and other similar Linux distributions, it is highly recommended to install the relevant from MariaDB's repository using or . Starting with RHEL 8 and Fedora 22, yum has been replaced by dnf, which is the next major version of yum. However, yum commands still work on many systems that use dnf. For example:

See for more information.

Installing Debug Info Packages with zypper

The MariaDB zypper repository contains packages.

On SLES, OpenSUSE, and other similar Linux distributions, it is highly recommended to install the relevant from MariaDB's repository using . For example:

See for more information.

Installing Debug Info Packages from MariaDB's Debian or Ubuntu repository

These are for when you already installed MariaDB from a MariaDB mirror.

For Ubuntu an additional repository step is needed:

Adjust 10.5 to the major version you are debugging and focal to the required distribution.

From the version isn't included in the package name and mariadb-server-core-dbgsym can be used as the package name.

Installing Debug Info Packages packaged by Ubuntu or Debian

If you used the MariaDB versions provided by Debian or Ubuntu see the following links.

For Debian see

For Ubuntu see

Installing Debugging Symbols on Windows

Debugging symbols are available to install on Windows.

Installing Debugging Symbols with the MSI Installer on Windows

Debugging symbols can be installed with the installer. Debugging symbols are not installed by default. You must perform a custom installation and explicitly choose to install debugging symbols.

The installer can be downloaded from the .

Installing Debugging Symbols with the ZIP Package on Windows

MariaDB also provides a package that contains debugging symbols on Windows.

The package that contains debugging symbol can be downloaded from the .

Containers with Debug Symbols

Prebuilt Debug Containers

These are currently only per major release version and are generated out of CI. They are always the latest version in the main branch on .

There are available on at .

Use the container name quay.io/mariadb-foundation/mariadb-debug:VERSION.

Where VERSION corresponds to the major version you wish to test with.

Creating a Container with Debugging Symbols

Build using a Containerfile/Dockerfile:

Build with:

Then you will have a mariadb_debug container.

Example use:

Enabling Core Dumps

To enable core dumps, see for details.

Where is the Core File on Linux?

At the bottom of the error log there will be some text about the core location including:

If the was a core limit in the resource limits there may be limited or no core file information.

If the core pattern begins with a |, then the following is the executable that handled the core file during the crash. The following show a few techniques to access the core depending on the pattern. If another program is used, look at its manual page to see how to get access to the core file.

If a plain core filename is in the "Core pattern" there's a good chance it will be in the Working directory location. It might have a .{process number} suffix on the filename.

Extracting a core file from a container

If you are running MariaDB in a container, the locations where the core dump can be generated are limited. Looking at the container log, this will likely be where the error log information is. The "Core pattern" of a Linux system is currently a global fixed value. The consequence is if this core pattern refers to a program, that program isn't likely to be in the container and won't be executed on the crash.

The system wide crash handler can be changed with sysctl kernel.core_pattern=core to set this back to a file based crash. With this, the crash should occur in the working directory, normally the /var/lib/mysql data directory of the container volume.

Extracting a core file from systemd-coredump

For systemd-coredump, there is a program coredumpctl to manage access.

To access the program using gdb, coredumpctl debug (defaults to last crash), will load the core dump in gdb. The instructions in the for extracting information.

See also: .

Extract a core file from abrt

A core pattern of |/usr/libexec/abrt-hook-ccpp indicates abrt system is used.

is a command line user interface for access the core file.

Extract a core file from apport

A core pattern of [|/usr/share/apport/apport indicates apport.

For more information see .

allows you to "Examine Locally" and run a gdb session. One you have gdb started instructions in the can be used for extracting information.

Analyzing a Core File with gdb on Linux

To analyze the core file on Linux, you can use .

For example, to open a core file with , you could execute the following:

Be sure to replace /usr/sbin/mariadbd with the path to your mariadbd binary (might be mysqld on and earlier) and to also replace /var/lib/mysql/core.932 with the path to your core file.

Once has opened the core file, if you want to , then you could execute the following commands:

If you do not execute set logging file, then the set logging on command creates a gdb.txt in your current working directory. Redirecting the output to a file is useful, because it can make it easier to analyze. It also makes it easier to send the information to a MariaDB developer, if that becomes necessary.

Do any commands that you would like to do. For example, you could .

Once you are done, you can exit by executing the command.

Getting Backtraces with gdb on Linux

On Linux, once you have debugging symbols for your mariadbd binary, you can use the utility to get , which are what gdb calls stack traces. Backtraces can be obtained from a core file or from a running mariadbd process.

Full are preferred and will contain function arguments, which can contain useful information such as query strings, so it can make the information easier to analyze.

To get a full of the main thread, then you could execute the following:

If you want to get a full of all threads, then you could execute the following:

If you want to get a full backtrace to a file to report a bug, the recommended way is to use gdb:

This will write the full backtrace into the file gdb.txt.

Getting Full Backtraces For All Threads From a Core File

Sometimes it can be helpful to get full for all threads. The full will contain function arguments, which can contain useful information such as query strings, so it can make the information easier to analyze.

To get full for all threads from a mariadbd core file, execute a command like the following:

Be sure to replace /usr/sbin/mariadbd with the path to your mariadbd binary and to also replace /var/lib/mysql/core.932 with the path to your core dump.

The will be output to the file mariadbd_full_bt_all_threads.txt.

Getting Full Backtraces For All Threads From a Running mariadbd Process

Sometimes it can be helpful to get full for all threads. The full backtraces will contain function arguments, which can contain useful information such as query strings, so it can make the information easier to analyze.

To get full for all threads from a running mariadbd process, execute a command like the following:

Be sure to replace /usr/sbin/mariadbd with the path to your mariadbd binary.

The will be output to the file mariadbd_full_bt_all_threads.txt.

Sometimes very busy systems are too busy to batch obtain the backtrace. If this is the case, gcore $(pidof mariadbd) can save the core and then obtain the backtrace out of the dumped core.

Getting a Full Backtrace out of a Container

If the crash or assertion is repeatable it could be easiest to run mariadbd under #gdb.

The container image name here can be a prebuilt one from quay.io/mariadb-foundation/mariadb-debug or an explicit version built yourself as above.

In docker-compose.yml form this looks like:

Note, the initialization of data is assumed. Omit command and user if it isn't.

If you wish to attach to and existing process in a container, the container needs to be started with the SYS_PTRACE capability. The sysctl kernel.yama.ptrace_scope that allows this should also be set to 0.

Note: podman has the same arguments and behaviour as docker if you'd rather use that.

or in compose:

The container process is always pid one, and here we use c then thread apply all bt -frame-arguments all full as the pre-loaded gdb commands. When a particular signal like assert or SEGV is triggered, the backtrace will be displayed.

Letting a Container coredump

First, the sysctl kernel.core_pattern needs to be core. If it starts with a pipe character it try to execute this within the container. This is a kernel wide setting and cannot be applied to a specific container. The bottom of a crash will show you want it is set to.

With this set, just running a container with debug info is sufficient. The core should be dumped on the datadir volume. With the core dump here, analysis can occur like:

Running a Copy of the Database Directory

If you are concerned with debuggers running on your production database you can also copy the database to another location.

This is useful when you know which statement crashed the server.

Just start mariadbd with the options--datadir=/copy-of-original-data-directory --core-file --stack-trace --socket=/tmp/mariadbd-alone.sock --skip-networking

Disabling Stack Traces in the Error Log

In order to disable stack traces in the , you can configure the option either on the command-line or in a relevant server in an . For example:

Reporting the Problem

If you encounter some problem in MariaDB, then MariaDB's developers would appreciate if you would at the . Please include the following information:

• Your full stack trace.

• Your .

• Your .

• How to reproduce the problem.

A is available for large and/or sensitive information. Please upload in .tar.gz or .zip archive.

For very difficult or critical errors, you should consider uploading the following information to the the following:

• Your build of mariadbd (if you compiled it), otherwise version information on the mariadb-server package.

• Your core file.

• Your contact information.

• The associated for the bug, if you .

This information will allow MariaDB developers to analyze it and try to create a fix.

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