MDEV-36676 Add debug function to print MEM_ROOT name by longjinvan · Pull Request #4703 · MariaDB/server

longjinvan · 2026-02-27T01:03:46Z

Description

MEM_ROOTs used to have names stored inside the structure. Now these names are stored in Performance Schema, making it difficult to retrieve them during debugging.

Add dbug_print_memroot_name() function that retrieves and prints the name of a MEM_ROOT from Performance Schema. The function uses DBUG_PRINT to output the MEM_ROOT name, address, and PSI key. The function is debug-only (wrapped in #ifndef DBUG_OFF) with zero production overhead.

How can this PR be tested?

A TAP unit test pfs_memroot_name-t.cc has been added under storage/perfschema/unittest/. It verifies that dbug_print_memroot_name() correctly handles NULL pointers, registered PSI keys, PSI_NOT_INSTRUMENTED, and invalid keys.

Unit test:

cd build
cmake ../mariadb-server -G Ninja -DCMAKE_BUILD_TYPE=Debug
ninja pfs_memroot_name-t
./storage/perfschema/unittest/pfs_memroot_name-t

Expected output:

1..9
ok 1 - init_memory_class
ok 2 - test_memroot registered (key=1)
ok 3 - test_memroot_second registered (key=2)
ok 4 - NULL MEM_ROOT returns '<NULL>'
ok 5 - registered key returns 'test_memroot' (got 'test_memroot')
ok 6 - PSI_NOT_INSTRUMENTED returns empty string
ok 7 - invalid key 9999 returns empty string
ok 8 - second key returns 'test_memroot_second' (got 'test_memroot_second')
ok 9 - Allocation on MEM_ROOT with second key succeeds

End-to-end test from GDB on a running debug server:

(gdb) p dbug_print_memroot_name(thd->mem_root)
$1 = "memory/sql/thd::main_mem_root"

Basing the PR against the correct MariaDB version

✅ This is a new feature and the PR is based against the latest MariaDB development branch

PR quality check

✅ I have checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
✅ For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

Copyright

All new code of the whole pull request, including one or several files that are either new files or modified ones, are contributed under the BSD-new license. I am contributing on behalf of my employer Amazon Web Services, Inc.

CLAassistant · 2026-02-27T01:03:52Z

All committers have signed the CLA.

gkodinov

Thank you for your contribution. This is a preliminary review.

Several things to fix in addition to the actual comments below:

remove the license reference from the commit message
make the commit message compliant with CODING_STANDARDS.md
click on the CLA bot button on the PR github page, pick your license and say "accept". This should clear the CLA bot.

gkodinov · 2026-02-27T09:35:37Z

include/my_sys.h

+#ifndef DBUG_OFF
+extern void dbug_print_memroot_name(MEM_ROOT *root);
+#else
+#define dbug_print_memroot_name(A) do {} while(0)


Why can't it just be an empty define, similar to e.g. DBUG_ENTER?

Several things to fix in addition to the actual comments below:

remove the license reference from the commit message

make the commit message compliant with CODING_STANDARDS.md

click on the CLA bot button on the PR github page, pick your license and say "accept". This should clear the > CLA bot.

The commit message has been updated to comply with CODING_STANDARDS.md. Regarding the license reference removal and the CLA bot, we are still working through those with our open-source legal team. Georgi is aware of the situation. I'll update once that's resolved.

Why can't it just be an empty define, similar to e.g. DBUG_ENTER?

The declaration has been removed from my_sys.h entirely. The function now lives in PFS (pfs_instr_class.h/.cc) and is intended to be called from a debugger, so no no-op macro is needed.

gkodinov · 2026-02-27T09:38:05Z

mysys/my_alloc.c

+
+  if (!root)
+  {
+    DBUG_PRINT("info", ("MEM_ROOT: NULL"));


I would print to the standard output. The primary use of this is when you're on a debugger console and trying to get the name of the memroot quickly without tweaking the P_S functions. So I'd expect this to print to standard output and not via (the possibly turned off) DBUG_PRINT functions.

Ditto for all the rest of the DBUG_PRINTs in this function.

Fixed. Replaced DBUG_PRINT with fprintf(stderr, ...) .

gkodinov · 2026-02-27T09:42:11Z

mysys/test_memroot_name.c

@@ -0,0 +1,142 @@
+/* Copyright (c) 2025, MariaDB Corporation.


Please convert that to a proper unit test and move it into unittest/. If you go with my advice to move it into PFS, you might need to create a subdirectory of unittest/ for pfs.

Done. Moved the test to pfs_memroot_name-t.cc as a proper TAP unit test, since the function now lives in PFS.

gkodinov · 2026-02-27T09:45:15Z

mysys/my_alloc.c

@@ -715,3 +715,42 @@ LEX_STRING lex_string_casedn_root(MEM_ROOT *root, CHARSET_INFO *cs,
  res.str[res.length]= '\0';
  return res;
 }
+


By defining the function here you're making mysys depend on pfs and thus creating a circular dependency since pfs already depends on mysys.

I'd move the whole function out of mysys to pfs.

Fixed. Moved dbug_print_memroot_name() to pfs_instr_class.cc. It now calls find_memory_class()directly instead of using a weak symbol, and the declaration is only in pfs_instr_class.h.

Sorry for mixed signaly but we really have already such function like dbug_print_item, dbug_print_select thay use static buffer (if output more than the bugger it just cut).

it return char* reference on the buffer so it can be used in DEBUG_PRINT and in debugger without spoilinh strout which no one know where to point.

But according to our experience most of the time such functions used in the debugger like

p dbug_print_memroot_name(meme_root)

Ah and again we call it and knwow we got name back so no need "MEM_ROOT:" prefixes just the name or just something like "<NULL>".

Thank you for the work and yet another sorry for mixed input but I want all such functions have the same interface.

Thanks for the guidance. Updated the function to return const char* matching the interface used by dbug_print_item() and dbug_print_select(). It now returns just the name, "" for null input, or an empty string if the key has no registered name. No more prefixes or fprintf.

gkodinov

LGTM. Thanks for addressing my comments.

Please stand by for the final review.

longjinvan · 2026-03-23T20:49:23Z

Thank you for the update and for taking the time to review. I'll stand by for the final review.

sanja-byelkin · 2026-03-27T08:26:47Z

Thank you for the fix but I have 2 more questions:

Where pfs_get_memory_class_name used?

What the test tests?

Add dbug_print_memroot_name() to return the Performance Schema memory class name associated with a MEM_ROOT, for use from a debugger or in DBUG_PRINT. All new code of the whole pull request, including one or several files that are either new files or modified ones, are contributed under the BSD-new license. I am contributing on behalf of my employer Amazon Web Services, Inc.

longjinvan · 2026-03-27T22:47:21Z

Thank you for the review. To answer your question:

pfs_get_memory_class_name was leftover from the earlier approach and wasn't used anywhere. Removed it in the latest revision.
I've simplified the test by removing duplicate checks (second registered key, unrelated allocation test). The test (pfs_memroot_name-t) now has 6 focused checks:

Test 1: PFS memory class subsystem initializes successfully (setup prerequisite)
Test 2: A test memory key can be registered with PFS (setup prerequisite)
Test 3: Passing NULL returns ""
Test 4: A MEM_ROOT with a registered PSI key returns the correct class name
Test 5: A MEM_ROOT with PSI_NOT_INSTRUMENTED (key=0) returns an empty string
Test 6: A MEM_ROOT with an invalid/unregistered key (9999) returns an empty string
Test output:

1..6
ok 1 - init_memory_class
ok 2 - test_memroot registered (key=1)
ok 3 - NULL returns '<NULL>'
ok 4 - registered key returns 'test_memroot' (got 'test_memroot')
ok 5 - PSI_NOT_INSTRUMENTED returns ''
ok 6 - invalid key 9999 returns ''

gkodinov added the External Contribution All PRs from entities outside of MariaDB Foundation, Corporation, Codership agreements. label Feb 27, 2026

gkodinov requested changes Feb 27, 2026

View reviewed changes

longjinvan force-pushed the MDEV-36676 branch from 69e7303 to b887746 Compare February 27, 2026 23:08

gkodinov approved these changes Mar 20, 2026

View reviewed changes

gkodinov requested a review from sanja-byelkin March 23, 2026 08:55

gkodinov assigned sanja-byelkin Mar 23, 2026

longjinvan force-pushed the MDEV-36676 branch from b887746 to 1e53e4e Compare March 24, 2026 23:38

longjinvan force-pushed the MDEV-36676 branch from 1e53e4e to 9be5823 Compare March 27, 2026 22:19

longjinvan force-pushed the MDEV-36676 branch from 9be5823 to 5917690 Compare March 27, 2026 22:30

		@@ -0,0 +1,142 @@
		/* Copyright (c) 2025, MariaDB Corporation.

Uh oh!

Conversation

longjinvan commented Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

How can this PR be tested?

Basing the PR against the correct MariaDB version

PR quality check

Copyright

Uh oh!

CLAassistant commented Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gkodinov left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

longjinvan Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

longjinvan Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sanja-byelkin Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gkodinov left a comment

Choose a reason for hiding this comment

Uh oh!

longjinvan commented Mar 23, 2026

Uh oh!

sanja-byelkin commented Mar 27, 2026

Uh oh!

longjinvan commented Mar 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

4 participants

longjinvan commented Feb 27, 2026 •

edited

Loading

CLAassistant commented Feb 27, 2026 •

edited

Loading

longjinvan Feb 27, 2026 •

edited

Loading

longjinvan Feb 27, 2026 •

edited

Loading

sanja-byelkin Mar 24, 2026 •

edited

Loading